debugger enfeebled by "The activation context being deactivated is not the..."

[GeoRanger]

I'm trying to debug a native C++ application which uses MFC as a DLL. This in VS 2008 on a Windows 7 machine. The code I'm debugging has some bad pointers and out-of-bounds array indices.

My perception is that until about one or two months ago, bugs like this would make the program crash with a GP Fault and the debugger would nicely take you to the bad instruction or at least to a problem which was ultimately caused by the bad code. In contrast, when this happens now, I'm instead getting the red herring "0xC015000F: The activation context being deactivated is not the most recently activated one." The call stack that I get with this error never has even the slightest thing to do with the code where the problem is really located, nor do the call stacks of any of the other threads in the application.

The code I'm debugging is not using .NET and I don't give a rip about SxS assemblies or manifest files. I checked the related post here http://www.codeguru.com/forum/showthread.php?t=511101 but I can't tell that it's related.

Since it seems to have started happening a month or two ago, I also looked through my recent Windows updates and VS updates, but nothing jumped out at me. (That's not to mean that didn't overlook something.)

Does anybody know what might be causing this? I just want the debugger to work the way it used to. It's taking me roughly an order of magnitude (base 10) longer to debug because of this.

Thanks for ideas

[S_M_A]

In some situations it's impossible for the debugger to display a call-stack and one such situation is when your code executes in valid program space but out of symbol space. Buffer overflow and c-style casting of pointers are some efficient ways of creating this so I would double-check such potential dangerous code. If that doesn't resolve the issue get yourself something similar to BoundsChecker and/or run for instance PCLint on the code.

[GeoRanger]

Thanks for your interest in this issue.

This is very definitely something above-and-beyond the "normal" kinds of issues that you're thinking of.

I'm sure of this because of the bug I just found since posting my initial message: It was actually an integer mod-by-zero, but yet the debugger still reported the ridiculous and unrelated activation context crash.

To be very specific, I traced into the disassembly, and the crash occurred on execution of the "div" instruction. Except that instead of getting the traditional and expected "divide- or mod-by-zero" message with the instruction pointer aimed at the "div", I instead got the loathsome message about the "...activation context being deactivated is not..." and again with the completely unrelated call stack.


Do I need to reinstall Visual Studio?

[GeoRanger]

This is some kind of problem with Windows 7.

A coworker is able to duplicate this nasty result with a divide-by-zero on his Windows 7 machine. If we go to Windows XP with VS2008, we instead get the expected "divide-by-zero" with the execution pointer on the offending instruction.

[S_M_A]

I don't think that you have to reinstall, you probably have some other bug that make this happen. The "beauty" of C/C++ in a nutshell so to say. You never know what effect a bug has on the execution...

Anyway, just to rule out the need of a re-install create a mod-by-zero as the very thing in main and if that is catched as it should you at least know what not to spend time on.

Edit: I don't run Win7 so I can't test it but could this be a 32/64 bit issue? I.e. debugging a 32 bit application in a 64 bit Win7 environment.