Internal Error

[bmcclintock]

Hi all,

I am now receiving the attached error message when trying to compile my project after the first initial build. For example, if I made a change to a topic and go to rebuild, this is the error I get. The only way I have been able to get around it is completely closing the project and shutting down my computer and restarting. Apparently something is not closing correctly. Any ideas?

[KevinDAmery]

First thing I would try is the Clean Project function under the Build menu: this deletes the contents of the output folder, so that the next build won't have any phantom files in it.

[Techno]

Forgive me jumping in here, but I'm getting what appears to be a similar problem. When I try to build HTML Help, it immediately comes up with "Intrenal error: Failed to create output folder. The device is not ready. Compiler Internal Error" - And yes, I did "Clean Project".

Anyone any thoughts before I call La Jolla on Monday?

[RamonS]

My experiences with these errors typically revolve around the following causes
- on access / real-time virus scan has its fingers on the file
- applications still claim a file lock on a file, most notorious offender is MS Outlook when attaching a file, but also bug tracking tools are known for that (being lazy the screen shots for broken software go to the same place as the production images, I know, bad practice, don't do it)
- drive / controller is swamped with read/write requests, usually not a big deal, but Windows is too stupid to handle this
- abandoned processes still claim the files, such as a crashed instance of Flare

Here is what I find to help remedy the situation besides manually cleaning the output folder
- reboot three times, no kidding, doing it once or twice often doesn't cut it, keep in mind, we work with Windows systems (and that advice comes from IT pros)
- exclude the source and output folders from on access / real-time virus scan, which also improves build times
- use JKDefrag / MyDefrag to really defrag the drive, do a cleanup of temporary files before (manually, don't use the dysfunctional Windows tools)
- sift through the entries for system and application messages in the system's event viewer
- make sure paths never even come close to being 255 characters long, Windows ain't *nix meaning that Windows is too stupid to handle this thanks to it being still plagued by DOS restrictions to this day

Aside from that, I think it makes more and more sense to use source control to secure project files and run Flare and all other tools in a virtual machine. With features like Unity from VMware you can sandbox the apps without much annoyance. If for whatever reason things stop working throw the VM away and restore a snapshot or copy over the backup of the image. The disadvantage here is a performance hit, you most likely need another Windows license (and those aren't cheap) unless you virtualize everything and run Windows in a VM using XEN or KVM.

What would really help is better error messaging, which in this case is a problem of the system code used, not Flare code. So the file is in use by another process, so why not provide some useful information and tell us what that process is? Error messages like that are as useful as a BSOD.

Ideally, Flare would run on better platforms than the notoriously miscoded Windows...OK, now I really get loony.

[NorthEast]

I like a good Windows rant first thing on a Monday.

Can't really add that much, but I've had similar things too with HTML Help targets (not any other outputs).
Running a 'clean project' will usually also fail at the same time, which to me indicates that it's due to something else accessing a file/folder Flare is trying to remove - for the reasons RamonS explains. It'd be good to hear what MadCap say anyway.

[i-tietz]

Maybe you want to try something faster:
1. Copy the project CFM HTML HELP from ... my documents\my projects to c:\ or d:\
2. try to build again