0

Creating a ATL COM DLL in Vs2015 for a VB6 consumer is going badly because the "fault tolerant heap shim" is being applied to VB6, which I am running from the vs2015 debug command.

I have found many posts about disabling FTH in Windows 7, and indeed I have applied them all, including deleting the DLL in \Windows\AppPatch, as well as disabing FTH in the registry AND running the rundll script that is cited.

Still, this damn thing is making it impossible for me to debug the dll, because the FTH makes it run like a dog under VB6 in debug mode.

I even added "vb6.exe" and "full_path_to_vb6.exe" in the exclusions list in the registry -- to no avail.

I desperation, and needing to get some work done today, I have renamed vb6.exe to myvb7.exe (!) and this gets rid of the FTH alert in the VS debugger. But why can't I disable FTH for vb6.exe?

In fact, why does it even get enabled at all when a debugger is attached? It's driven me mad today.

Anyone?

  • 1
    https://stackoverflow.com/questions/5020418/how-do-i-turn-off-the-fault-tolerant-heap – Jonathan Potter Feb 12 '16 at 01:35
  • It might have something to do with vb6.exe having an entry in the built-in compatibility database. On Windows 7, this entry doesn't appear to force the fault-tolerant heap, but it might be different on Windows 10 - or one of the other shims being applied might indirectly affect the decision to use the FTH. (You can examine the compatibility database using the Microsoft Application Compatibility Toolkit.) – Harry Johnston Feb 12 '16 at 07:36
  • @Jonathan: none of the linked to post makes any difference on windows 10 with vb6, as I described in my question – user5916352 Feb 12 '16 at 19:45
  • Thank you Harry, you may be on to something there. I think its probably easier for now to just use the renamed vb6 exe file. It's a shame the shims cannot be disabled in vs2015, since I think they mostly get in developers' way of debugging in most scenarios. – user5916352 Feb 12 '16 at 19:47

1 Answers1

1

There wasn't too much help forthcoming on this. For future reference, if the application (in this case VB6) is set to run in compatibility mode (either from a right click on the shortcut you use to launch it, or from a property set on the target exe itself) then nothing you do will release the shim!

Solution: don't run vb6 in compatibility mode under Windows 10!

  • That doesn't sound like much of a solution. Use a VM that boots XP instead. Somebody ought to make that customer an offer he can't refuse :) – Hans Passant Mar 04 '16 at 22:03