Jump to content

  • Log In with Google      Sign In   
  • Create Account

VC2008: Corrupt call stack after access violation


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 Evil Steve   Members   -  Reputation: 1987

Like
0Likes
Like

Posted 19 September 2012 - 03:36 AM

Hi guys,

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 bytes	
And 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

Steve Macpherson
Systems Programmer

Rockstar North


Sponsor:

#2 Evil Steve   Members   -  Reputation: 1987

Like
2Likes
Like

Posted 19 September 2012 - 03:54 AM

And, 20 minutes after posting, I find the answer of course: http://www.altdevblogaday.com/2012/07/06/when-even-crashing-doesnt-work/

Cheers,
Steve

Steve Macpherson
Systems Programmer

Rockstar North





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS