5

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: https://i.stack.imgur.com/OgNNx.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.

Community
  • 1
  • 1
Shaggi
  • 1,121
  • 1
  • 9
  • 31
  • 3
    Who are you expecting to follow all of these links? Please provide a [MCVE] in your post itself. – πάντα ῥεῖ Jan 08 '16 at 00:21
  • 1
    Was the slowdown ever seen while running the program as a user would, i.e. outside of the debugger/IDE environment? – Jeremy Friesner Jan 08 '16 at 00:26
  • 3
    @πάντα ῥεῖ - you want a verifiable example of a problem that appeared unexpectedly with no major source changes, remained despite rolling back the changes that were there, then disappeared for no apparent reason? There's times when it's not possible to provide a minimal verifiable example without already knowing what caused the problem anyway. –  Jan 08 '16 at 00:27
  • 1
    To the first person: not sure how to quote you, but: that would not be possible. I'm not expecting anyone to follow it. I'm hoping though. This question is an follow-up on the linked SO question. Ill add a tl;dr though. – Shaggi Jan 08 '16 at 00:27
  • @JeremyFriesner Problem happened outside of any debugger/environment, I was merely testing a build normally, in-action (and happened instantly, unrelated to features etc.). – Shaggi Jan 08 '16 at 00:30
  • 2
    The OP has provided as done significant initial research and has posted a well-defined question. I agree that it's not reasonable to demand a complete repro case. – Eric J. Jan 08 '16 at 00:30
  • Hmm, mysterious. Any chance that some other process decided to allocate lots of memory during the fault period, causing the system to start swapping to disk? – Jeremy Friesner Jan 08 '16 at 00:32
  • I kept a close eye on memory usage (I first suspected a memory leak), but nothing out of the ordinary (process used 1% of ram) – Shaggi Jan 08 '16 at 00:33
  • 1
    Check out this answer and the related question. Might provide a little insight. http://stackoverflow.com/a/6673297/141172 – Eric J. Jan 08 '16 at 00:34
  • 1
    @EricJ. That actually seems very relevant. I did write to some memory out of bounds before, so it might be a protective measure from Windows: http://billroper.livejournal.com/960122.html – Shaggi Jan 08 '16 at 00:37
  • 2
    Yeah that link does seem to describe your exact situation. Hope that's it! – Eric J. Jan 08 '16 at 00:41
  • 1
    Indeed it was. Windows event logs revealed FTH had been enabled for my process. Thanks for the help (and goodwill)! – Shaggi Jan 08 '16 at 00:54

1 Answers1

7

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?

Community
  • 1
  • 1
Shaggi
  • 1,121
  • 1
  • 9
  • 31