0
Myself and as far as I can tell everyone else at my work has been having problems where whenever a SEH exception such as an access violation or floating point exception (We have floating point exceptions enabled) occurs, the call stack gets garbled.
Here's my code (Based on a new Win32 console application):
// Temp.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
void foo()
{
*(int*)0=0;
}
int _tmain(int argc, _TCHAR* argv[])
{
foo();
return 0;
}
My call stack before the crash:
> Temp.exe!foo() Line 8 C++ Temp.exe!wmain(int argc=1, wchar_t * * argv=0x00696e70) Line 14 C++ Temp.exe!__tmainCRTStartup() Line 583 + 0x19 bytes C Temp.exe!wmainCRTStartup() Line 403 C kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytesAnd then I execute the deliberate null pointer dereference by stepping over the instruction with F10:
ntdll.dll!_ZwRaiseException@12() + 0x12 bytes ntdll.dll!_ZwRaiseException@12() + 0x12 bytes > Temp.exe!wmain(int argc=4454604, wchar_t * * argv=0x76e8339a) Line 14 C++ Temp.exe!wmainCRTStartup() Line 403 C ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes
As you can see, the top of the call stack gets garbled (because of the ZwRaiseException function I guess); the foo() function has gone from the stack, and the argc and argv parameters are gibberish inside wmain(). This is obviously a very simple example, but in the game we're working on the top 2-3 functions on the stack get destroyed, some of which may be hundreds of lines long, making it extremely difficult to find the problem.
Interestingly, when our Technical Director in Florida tries the same code on his machine, he doesn't get the ntdll.dll stack frames, and the call stack is un-mangled, so this must be some environment setting that everyone here has set up...
Has anyone seen this before? I'm getting very close to reinstalling Visual Studio (Which would be a pain in the ass since there's about 4 or 5 different VSI plugins loaded for various devkits), but since everyone here is getting this, I'm not convinced it'll help. Running as Administrator / normal user doesn't seem to make any difference.
As far as I can remember, this didn't used to happen, but I can't think what would have changed between then and now, apart from Windows updates - But then I can't see why that would cause this to happen...
Googling "visual studio access violation corrupt callstack" yields several results, but no solutions unfortunately
. We're all using Visual Studio 2008 Professional (We can't update due to several console platforms not supporting newer versions of Visual Studio), and we're writing x86-only code (I.e. no x64 target).Cheers,
Steve
