Cant track down access violation 0xC00000FD

Question

Im using VS2008 and My MFC application has started to crash when setting breakpoints or running to cursor. I get lots of errors like this:-

First-chance exception at 0x78a5727c (mfc90ud.dll) in MyApp.exe: 0xC0000005: Access violation reading location 0xfffffffc.
First-chance exception at 0x00000000 in MyApp.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x00000000 in MyApp.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x00000000 in MyApp.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x00000000 in MyApp.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x00000000 in MyApp.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x00000000 in MyApp.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x00000000 in MyApp.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x00000000 in MyApp.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x00000000 in MyApp.exe: 0xC0000005: Access violation reading location 0x00000000.
First-chance exception at 0x00000000 in MyApp.exe: 0xC0000005: Access violation reading location 0x00000000.

The call stack is not much left either it only lists code in NT.dll

>   00000000() 
    ntdll.dll!7c9032a8()  
    [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll] 
    ntdll.dll!7c90327a()  
    ntdll.dll!7c92aa0f()  
    ntdll.dll!7c90e48a()  
    ntdll.dll!7c9032a8()

I am not able to find the problem using break points or stepping through my code. The application "seems" to run normally if run using F5 in VS.

Whats the best method to track this problem down?

Answer 1

Where is the stack overflow from your question title? Access violations generally indicate an invalid pointer dereference.

Use your revision history to find the first version where things started going boom, then critically analyze all pointer stuff going on in and around the code modified in that revision.

Answer 2

Visual Studio has an option somewhere to break on first chance exception (don't remember exactly where it is, maybe an exception menu item in the debug submenu?) You want to turn that on and look at your call stacks the moment they occur.

There is also an option to turn on Microsoft Symbol Server, that would automatically download the matching symbols for whatever system dll you happen to see in the stack. (sorry, don't remember how exactly thats setup either).

Answer 3

I will use my psychic debugging skills and tell you that you are overwriting a buffer that lives on the stack - specifically, you're writing too many zeros into a buffer that isn't big enough to hold it.

You've got the classic symptoms of a smashed stack - the first AV you hit is trying to access zero minus a few bytes - clearly an offset from your stack pointer into either your parameters or your local variables. (I can never remember which ones are above the stack pointer and which ones are below.) Then you have a bunch of lines that indicate the instruction pointer has been set to zero, which often happens because the function return addresses in the stack frames have been overwritten with zero values - because you overwrote the stack-based buffer and corrupted all the other important stuff on the stack. As your program tries to return from the current function, it looks in the stack to see where it thinks it came from, sees the zero, and jumps right there. Whoops!

Since your stack is trashed, you may not find the stack trace too useful; your stack frames are likely to be corrupted by this point.