Putting the Fault Tolerant Heap In Its Place

[billroper]

If you've been following my little battle against Microsoft's Fault Tolerant Heap which happily enabled itself on a development system in such a way to make actual development use impossible, you may be amused to find out that I now have a solution to the problem and am able to go back to normal debugging with Visual Studio. More or less. :)

It turns out that you can disable the Fault Tolerant Heap by renaming the DLL that it uses: Windows\AppPatch\AcXtrnal.dll. I had tried this before without success, because on Windows Server 2008 R2, the file belongs to "Trusted Installer", which prevents anyone except an installation program from deleting or renaming the file.

If you go to the advanced options in the file properties, you can take ownership of the file away from Trusted Installer and give it to yourself. Then you can add yourself (or just Administrators) to the list of people with Full Control of the DLL.

And then you can rename it.

This will prevent the Fault Tolerant Heap from running on the system at all, at least until you get an OS update that reinstalls it, at which point you'll have to do all this again.

But -- for the time being, at least! -- the Fault Tolerant Heap has been moved to the correct location.

The trash heap.

"Hi! We're from Microsoft and we're here to help you!"

Comments

[hrrunka]

Heh! ;)

[thelongshot.livejournal.com]

I don't know if the trash heap is the correct location, since it does seem to have its use in a production OS. But it does sound like a PITA for a developer. I guess I never ran into it because I haven't done much development work on Windows 7 as of yet. (Last time I did .NET work was mostly on XP machines.)

[billroper]

As I was saying in another context a few moments ago, if I have an unstable program that I'm required to use for work -- it works most of the time, let's say, but has periodic crashes -- I will be really annoyed if it suddenly starts running at one-twentieth of its normal speed.

I'd rather reboot the system occasionally.

[thelongshot.livejournal.com]

Assuming a reboot actually solves the problem, which it doesn't for all faults.

As I said, this is a pain for the developer, for obvious reasons, but I can see the use for the end user who needs to run a piece of software but is stymied by a problem. The ultimate solution is for the developer of the software to fix the problem, but that isn't always possible.

[billroper]

True. However, it doesn't look like the user has any control over it. The hoop-jumping that I had to go through to completely disable the FTH is something no end-user should ever have to deal with.

If there was an interface where the user could disable the FTH shimming for a particular application, this would probably be a reasonable feature. As it is, it might solve the problem for one class of failing application, but it makes another class of failing application unusable.

Of course, we all know that no shipping application should have bugs. :)