re: .NET Crash: Managed Heap Corruption calling unmanaged code

rmbyers — Tue, 28 Feb 2006 23:09:32 GMT

For situations like this, it's still hard to tell where the corruption is occuring. In this case, the contents of the buffer provided a hint, but that's not always going to help. One thing that may help is to use !gcroot on the last good object (the byte[10] in this case) - if the object is still alive, it root path should give an indication of where in the source code this object is being held (and therefore where it is being used). Often by looking at how the specific object is being used in the source, you can quickly find some suspect PInvoke or other call which could be causing the corruption.

In the long run, my team (CLR debugging support) would like to enable "time-traveling debugging" where you could record an execution trace (if the repro scenario permits) , and then just say "go back to the spot where this memory was overwritten". In some cases like this, it could make tracking down these sorts of problems extremely easy!

re: .NET Crash: Managed Heap Corruption calling unmanaged code

Tess — Wed, 01 Mar 2006 11:05:47 GMT

Thanks for pointing out !gcroot, these isssues are definitely not among the easier ones to get to the bottom of.

I, for one, am really excited about the "time-traveling debugging". I really cant wait to see it.

Currently if we cant find the fault using the steps above or with gcroot like Rick mentions, we have to run something called GCStress which essentially triggers a gc on each allocation so we get the exception closer to the faulting call, but of course as you can imagine this is really bad performance wise so it cant generally be done in production. And this is why im doubly excited about the time travelling stuff... plus, anything involving the word time-travel just has to be exciting right:)