Insane amount of time spent in free/malloc, external memory hooks?

Question

This is partly programming/debugging related, partly external operating system related (SuperUser candidate?), but I posted it here anyway, because if anyone should know the answer, it's here.

I was developing a program when suddenly, a new build (with no major changes) caused everything to grind to a halt. I profiled it to see what took time, but % distribution was normal - everything just took a lot longer.

Grinding through callstacks with Very Sleepy, I noticed free/malloc/delete/realloc accounted for 95%+ of the runtime. Suspecting heap corruption, I rolled back all changes, but nothing changed.

Using MSVC's profiler, I dug down the call stack, beyond malloc/realloc and ended - surprisingly - at an external dll called Acxtrnal.dll. Here's a clip of the stack: http://i.imgur.com/0xXv5MV.png

So apparently, some external dll is hooking into heap validation procedures of my program. This makes me mildly anxious. Googling the dll only reveals only one official source on it (something about compability mode; not relevant): https://support.microsoft.com/en-us/kb/2272691

After spending half a day debugging in disbelief, the problem disappeared. It seems this guy had the same problem, although the 'answer' is probably unrelated: When profiling my fortran program, Acxtrnal.dll is the part using most of the CPU time! What is that dll.?

Now, of course, I'm both curious and worried about the issue; whether it will return - and why it happened in the first case? I would be grateful if anyone has experienced something similar, so we can shed light upon the issue. Even though this issue seems rare, maybe it will help someone out there.

Answer 1

Thanks for the collective help. For future reference (and Googlers):

The problem is caused by the Windows Fault Tolerant Heap: https://msdn.microsoft.com/en-us/library/windows/desktop/dd744764(v=vs.85).aspx

It is a process-specific service instantiated when you manage to corrupt the heap to some unknown extent. It is unknown how to exactly disable the service again; some say rename the api dll (found in \windows\apppatch\acxtrnal.dll), or disable it through the registry.

In my case, my program was a plugin-dll, and apparantly I solved the issue hosting the dll in another program.

More info can be found in the comments, and here: http://billroper.livejournal.com/960122.html

How do I turn off the fault tolerant heap?