Flare 3.1 stays in memory after closing

[7man40]

When I close Flare 3.1, it often stays in memory and runs up the CPU to 90+%. I have waited to see if it stops, but it appears to just keep going (30 minutes plus verified). I usually end the Flare.exe process in Task Manager. Any idea what's causing this?

Thanks

[Andrew]

Wish I could be more helpful, but I've never experienced that with any version of Flare (from 1 to 4.1).

Does it happen if you close your project first?

[7man40]

Yes, it happens when I close the project first. I just tried it. Then I tried it leaving the project open, and it also happened. I close Flare from the FIle menu, and then the CPU utilization goes way up. In Task Manager, on the Processes tab, it shows Flare.exe at a high percentage, often over 90%. I don't think Flare was running at that rate before I closed it.

[Andrew]

What version of Flare are you using?

Some other standard troubleshooting stuff:

- Have you restarted Windows since this started to happen?
- Have you tried to reinstall Flare?
- Have you tried to uninstall/reinstall the .Net Framework?

[RamonS]

Can it be that the process you see is some stale process that is not the same as the one from the 'working' Flare instance that you just closed? You can open Flare several times and when one instance crashed at some point, but never closed you will have the process hanging around forever. Typically, a reboot fixes that....as it fixes quite a lot in Windows systems.

[7man40]

I'm using Flare 3.1. I have restarted Windows XP. I don't think it's a stale process because there is usually only one Flare.exe in the Task Manager processes tab.

I have not tried to reinstall Flare, can you please give me a link to download 3.1?

Would I uninstall .NET from Add or Remove Programs? I have the following installed: .NET Framework 1.1, 2.0 Service Pack 1, 3.0 Service Pack 1, and 3.5. Should I uninstall all of them? What would be an appropriate .NET version to install?

I document a .NET program for my client, and I am frequently installing and uninstalling their program and sometimes a new version of .NET gets installed. Flare has been installed on this PC for a while and I only recently started using it. Maybe the .NET got messed up?

[RamonS]

IIRC Flare 3.1 uses DotNet 2.0, so that would be the one to reinstall. I'd contact MadCap support directly to get a download link for 3.1. It is always good practice to keep a copy of the installation package of the application you use.
In regards to the application you document, there really is no reason to install the DotNet runtime each and every time. I am quite sure that any up to date XP install has 2.0 and Vista has out out of the box. Even when there is a need to support Windows 2000 (and there I'd assume most who still use it have 2.0 installed) I think it is better practice to have the customer install DotNet separately. I think it is OK to use the redistributable package for DotNet to put it on the CD, but it really shouldn't be a mandatory part of the install. I guess I'm barking up the wrong tree here. Shows again that the tech writer must be part of the QA team with the same rights as any other tester.

[7man40]

I found my installation email. First I uninstalled and reinstalled .NET Framework 3.5, which the Flare 3.1 download webpage had a link to. Then I uninstalled and reinstalled Flare 3.1. The stays-running problem still happens but I have more info now. It only happens when I have opened a project that is bound to source control in Flare. In my case it is bound to Perforce using the SCC API. My Perforce server is available and I can check out and check in files from the Flare GUI.

So I open Flare, then open a project that is bound to source control. CPU utilization at this point: 0% or so.

Then I close Flare. Within 5 seconds the CPU goes over 90% on the Flare.exe process and pretty much stays there. No error messages or anything. Tends to turn on the fan on my laptop. Does this info help?

[helen]

Are you binding your project to source control at all?

[7man40]

Are you binding your project to source control at all?

Yes. Please see my last post. It is projects that are bound to source control that seem to cause this problem.

[helen]

My apologies - that part of your previous post passed me by. I've seen similar behaviour when binding to source control and reported it as a bug - it's definitely not just you. I've not found a solution to this other than manually handle my source control process.

[wijnand]

It sounds like your Source control is synchronizing your flare project. What source control are you using?

[7man40]

It sounds like your Source control is synchronizing your flare project. What source control are you using?

I was using Perforce. I'm not sure what is meant by "synchronizing files." Perforce by itself never runs up the CPU to 90%+ on and on.

By the way, I un-bound the project from source control and Flare stopped doing this. We're just checking out the files in Perforce before working on them in Flare.

[helen]

It sounds like your Source control is synchronizing your flare project. What source control are you using?

It's appears to be a known bug - I've reported it as have others: http://forums.madcapsoftware.com/viewto ... =68&t=7932