1

I am getting the CRT Heap corruption detected message box in an C# Windows service application. I cannot find the source of the heap corruption, and the message box keeps on appearing even if I compile in release mode. The heap corruption is probably in one of the unmanaged DLL files used by my service (but I don't know where).

  1. How can I find the source of the problem?
  2. How can I disable the message box?
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
jacob
  • 1,397
  • 1
  • 26
  • 53
  • See [How to debug heap corruption errors?](http://stackoverflow.com/questions/1010106/how-to-debug-heap-corruption-errors) for some related useful information – Justin Aug 31 '11 at 09:14

2 Answers2

1

Run your program with Gflags.exe and Pageheap.exe. This will help you trap where the corruption is happening.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
selbie
  • 100,020
  • 15
  • 103
  • 173
0

The error is from a native DLL, which is either flawed or misused. To find out which one, you can use Process Explorer to examine the stack traces of your app's threads when the message is popped. The DLL will be around the top of the stack (the messagebox stuff will be above it). You won't see the root of the corruption, though - the error is detected when memory is freed.

You might be able to disable the message using one of these options, but you'll only be hiding the problem. If your heap gets corrupted, your data might get corrupted as well.

BTW, AFAIK, these messages only appear on debug builds, which means the native DLL is in debug build. If it's some third party's, it would be weird. If it's yours, you can just attach a debugger to the process, and it will break when the message is popped. You still don't get the root of the error, but you'll have a better picture of the context.

Community
  • 1
  • 1
Eran
  • 21,632
  • 6
  • 56
  • 89
  • “If your heap gets corrupted, your data might get corrupted as well.” In my experience, heap corruption almost always leads very rapidly to the program keeling over in a puff of (il-)logic. The only thing worse than heap corruption is stack corruption (or corrupted code, but that's much rarer). – Donal Fellows Aug 31 '11 at 08:27
  • @Donal, in general you can consider yourself doomed when this happens, sure. In practice, since the debug heap uses extra bytes before and after the block to detect these issues, you might get away with it if the overrun is minor (and then in release builds you will in fact loose your data, without an error, at the client's site). I wonder if that's why the DLL is in debug build... – Eran Aug 31 '11 at 08:49