Compiler (Internal Error) and tip

[DocuWil]

When I build my WebHelp it regarly happens that the process aborts. The error pops up and this is what happens:
------
Removing previously generated content...
Checking if auto-sync of any import file is needed...
Loading skin info...
Compiler (Internal Error): The process cannot access the file 'C:\Users\wveenstra\AppData\Local\Temp\tmpE1A1.gif' because it is being used by another process.
Aborted.
------

The only way I can avoid this is to use the 'Save all' button and restart the build.

Maybe this has to do with Vista?

[NorthEast]

Yep, I see this in Vista a lot, and it's a right pain - about 2 out of 3 builds abort.

I'd just guessed it was something to do with temporary files (so I clear those out the temp folder), but saying that it only ever happens in Vista and I've never seen it in XP.

(That's another thing actually, why can't Flare tidy up after itself? You can end up with tens of thousands of files in the temp folder.)

[SteveS]

Make sure you lodge a bug report.

I'm using Vista and it hasn't happened to me on any of the 3 machines I use. The only thing I can think of is I normally (always) "Clean Project" before I build.

[DocuWil]

Thanks Steve,

I did send the bug report

Wil

[NorthEast]

We have experienced a couple of customers complaining about this issue. So far, we've found that the problem lies within Vista. Before compiling your output, click Save All. Delete the temp files (Microsoft explorer)
Also, if you are using Microsoft IIS and Windows Vista, please use the following (From Microsoft)
http://support.microsoft.com/kb/890015

That's the answer, but no clue to the reason. Let's hope v4 works in Vista.

[Richard Ferrell]

You may want to build, Clean Project, I have not seen this issue in Vista and I am opening a lot of differerent projects each day.

[NorthEast]

It's a bit of a strange problem, as it seems to have some sort of time dependency. For example, if you repeatedly keep clicking the build button again after each failed build, then it won't work til maybe your 3rd, 4th or 5th attempt. However, if you just leave it alone and do nothing for a minute or two and then try again, it'll usually work.

Cleaning the temp folder does usually fix the problem - although doing so in Vista is easier said than done, as by default you don't have access to the folder.

I didn't find running a Clean project made any difference, presumably as this clears files in the output folder and not the temp folder (in c:\users\...).

[KevinDAmery]

Cleaning the temp folder does usually fix the problem - although doing so in Vista is easier said than done, as by default you don't have access to the folder.

Well of course not--Microsoft is duty bound to keep all of your files safe from you, the user.

</sarcasm>

[DocuWil]

Well, thanks to all of you guys.
I have deleted temporarily files on my Vista machine and since then I have no problems anymore.

[NorthEast]

Cleaning the temp folder does usually fix the problem - although doing so in Vista is easier said than done, as by default you don't have access to the folder.

Well of course not--Microsoft is duty bound to keep all of your files safe from you, the user.

</sarcasm> :roll:

Actually, I still haven't worked out how to get access to my temp folder (in c:\users\...). I just installed CCleaner and use that to clear it.

[RamonS]

You need to turn off all the garbage that Microsoft added to Vista. I have a test system here that in its original configuration doesn't run 90% of the applications I need to test. After turning UAC off the rate of stuff that didn't work goes down to 0%. It also prevents the annoying, but useless messages (Mouse movement detected - Allow or Deny). The graphics card cannot do Aero anyway and I changed the theme to Windows Classic, which brought another performance boost and increased screen real estate. I yet have to see if I can turn off the graphics subsystem in a controlled fashion, which supposedly is only of benefit for Aero and otherwise is an excessive performance hit. That might just get the performance to somewhat near to XP, which is installed on the same machine and across the board performs by 1/3 better, especially in regards to file access both locally and over the network. I did install SP1 for Vista that supposedly addresses these issues and my tests showed that there was absolutely no change. In one test case performance got even worse.
It is really amazing that for 300$ one gets an OS that uses twice the resources, limits the user extensively, has noticeably worse performance, and sports security features that can be circumvented by easy means. Yet under standard configuration a bulk load of perfectly fine software does not run. So, why again do people use Vista? Maybe because people like to throw money at a company that seems to have only the agenda to make everyone's life miserable.

[DocuWil]

Yes Ramon, you are completely right, but .....
Our company delivers tools to customers and some of them use Vista (bwaahh) and as I can see, there will be more and more (just like in the past with the other OS).
My company decided that it's a good idea that I run everything on a Vista OS as I am writing the documentation and the protocols to test the tools. That means at the same time that I also use the tools under Vista.
And maybe next year ..... the whole Vista is rewritten?

On the other hand we have to go on and not stick with old things. I think it will be become better and better.

Anyway, I am glad Flare runs well under Vista except for some minor things like I described in the beginning of this post.

[NorthEast]

So, why again do people use Vista?

People like getting pretty and shiny new things, like clothes, cars, and other people.

[RamonS]

I know that Vista will come since Microsoft rams it down the throat of many gullible people, but why does this crapware have to be so expensive? Contrary, I bought XP 64bit for around 50$, which is on par with what one would pay for a boxed Linux distro (although one usually gets support added, not for Windows). I found that a fair price for a cleverly disguised release of Server 2003.
One a positive note, I took a look at the RC of Server 2008 some time ago and found that the annoyance level compared to Vista was dialed down quite a bit. Microsoft just needs to ditch the new File Explorer and add in the old one (at least the GUI). The new one is unusable. I just don't get why a bare bones server OS needs 30GB or more just for a standard install. Compared to Linux, this is excessive. Many Linux distros install in half that space with tons of server and desktop apps installed. Maybe it is Ballmer's ego that got compiled into Server 2008.

[KevinDAmery]

Maybe it is Ballmer's ego that got compiled into Server 2008.

Oh, I doubt that: I don't think even EMC could address that much storage

[lauraj]

I'm reactivating this thread because we just started seeing this problem and it's killing our nightly build more often than not.

We are building on Vista and we are seeing this *mostly* on WebHelp targets, but occasionally on one of our HTMLHelp targets; here's an example error from our build output:

Task "Exec"
Command:
"C:\Program Files\MadCap Software\MadCap Flare V3\Flare.app\madbuild.exe" -project "CDF Users Guide.flprj" -target SmallHtmlHelp_AC_FF
Compiling target SmallHtmlHelp_AC_FF...
Removing previously generated content...
Checking if auto-sync of any import file is needed...
Loading skin info...
EXEC : error : The process cannot access the file 'C:\Users\mctcbld\AppData\Local\Temp\tmpD9BD.gif' because it is being used by another process.

We have had WebHelp targets in our build for over a year and never seen this problem; the HtmlHelp targets we're seeing it on are newly added.

We're still on Flare 3.1.0 -- as it happens, we're very close to product release and don't want to rock the boat by upgrading to 4.0. We didn't really need a new intermittent build failure at this point in the project, either.

So .... is there any new data on this failure?

[Andrew]

I'm curious: what is the date on the file specified as the problem? Was it from a previous build, or was it from the current build?

[lauraj]

It wouldn't have been from a previous build of that target, because we've taken to cleaning the directory in between builds. I'll see if we can get a fix on whether it's from the failed build, or a build of a previous target in the script.

[lauraj]

Here's some info from our build expert:
My last experiment was to delete all .gif files in the TEMP folder before each madbuild.exe, and so I know that it was not laying around from a previous build.. The other evidence is that many times it is the first madbuild.exe that actually creates temp .gif files that fails, and it was doing this when we started with a completely clean TEMP folder.

Also, I’d let them know that we ran the ‘handle.exe’ utility just before and just after madbuild.exe. It tells us what open file handles there are across the whole system, and the problem file was never in the handle.exe list. That’s just a snapshot in time, so it is possible that some other process fired up and opened it at just the wrong time. But, there’s certainly not a zombie madbuild.exe laying around with an open file handle.

Also, I’d let them know that we ran ProcMon that captures all file I/O activity across the system, and includes the error returned. Instead of being a snapshot in time like handle.exe, it logs all file activity. When madbuild.exe fails with this error, there was lots of activity in the TEMP folder related to .gif files, but there were no errors at the OS level. So, something else above the raw OS layer is causing the issue.

[kelly1210]

As of today, I had my first instance of this occurring (ever) on a project I've been working with in Flare 4 beta and current release (months). I did not have a failed build that I recall. Just started happening and I had to restart to get it to clear so I could re-build. I'm NOT on Vista (XP Pro), using Flare 4.0, and have had no issues like this at all previously. I'm reporting as a bug. For this to happen out of the blue is pretty odd. I'll check the temp folder to see if I can clear it up for the moment.

[lauraj]

We've removed all our WebHelp targets from our build (now we build them manually, so that's a step backward), removed all our .gif files in favor of .jpgs, and the problem went away .... for a week. Now it's back, failing on the build of an HTMLHelp target. I've opened a support incident on it.

[kelly1210]

My problem had magically disappeared when I came in to work the next day. I never did make any changes. I turned it in as a bug (on the day of the problem) and support suggested that I delete the output folder. I will if it rears its ugly head again. He also suggested that something like Virusscan might have been scanning the folder. However, it went on for several hours, so I'm skeptical of that one. It's a mysterious one, that's for sure.

[lauraj]

We're still seeing this rather infrequently, but like all intermittents, it happens when it's least convenient and most embarrassing. Last night we were going to FINALLY build a release candidate after a lot of pain with a defect unrelated to the help, and right at the end of the build, the Madbuild failure occurred.

I finally had the dev team believing that docs are a real part of the product and can be created with good processes and proper, professional tools. This bug is really eroding that impression.

[lauraj]

Just saw the failure again in last night's build: it doesn't seem to be correlated to anything in particular. We've not been making very many changes to the help this week, certainly nothing structural.

[kelly1210]

I just made a discovery on this error (work around at least) and thought I'd share it. First, the error happened this afternoon again out of the blue on one of my HTML Help targets - not the same one as before, but same project. I tried, as advised, to delete the designated output folder for the target and even though I'd closed Flare and nearly every other program I'd had open, and was doing this from File Manager, I got the message that the folder was being used by another process and could not delete it. So, I went back into Flare and changed the target output folder to another path and was able to produce the HTML Help file I needed w/o a problem. This is another clue, I think -- something outside of Flare is locking the output file during the deletion process used by Flare to clear the folder prior to building the target OR something is locking the file in Flare and not releasing it (my suspicion) even after Flare has closed down. The good news for me is that I know I can change my output folder on the fly and stil get the output I need in a hurry. This may help others, too. Anyway, for what it's worth... (PS: I verified that virus scan was NOT running either. Also, I took screen captures of my errors and Task Manager to show what was running at the time. I'll try to send that to Support later today or tomorrow.)