Hi there,
So the title pretty much says it all. I've been using Visual Studio 2010 to make this game in C++/Opengl.
If the game crashes while I'm debugging well I can see the problem, but what I would like is to know if there is a way to output the stacktrace to a file when the game crashes.
I've seen some game that I play doing that so it's probably possible. I just don't know how. Also something that could be somewhat portable would be nice if possible.
Cheers.
How to generate a stacktrace when my C++ game crashers outside VS
Excuse the link dump 
DIY: Structured exception handling (SEH), StackWalk64, MiniDumpWriteDump
Existing libraries: gperftools, crashrpt
Articles:
http://www.codeproject.com/Articles/11132/Walking-the-callstack
http://www.codeproject.com/Articles/1934/Post-Mortem-Debugging-Your-Application-with-Minidu#_Creating_a_Minidump
http://stackoverflow.com/questions/696580/getting-a-dump-of-a-process-that-crashes-on-startup/700108#700108
DIY: Structured exception handling (SEH), StackWalk64, MiniDumpWriteDump
Existing libraries: gperftools, crashrpt
Articles:
http://www.codeproject.com/Articles/11132/Walking-the-callstack
http://www.codeproject.com/Articles/1934/Post-Mortem-Debugging-Your-Application-with-Minidu#_Creating_a_Minidump
http://stackoverflow.com/questions/696580/getting-a-dump-of-a-process-that-crashes-on-startup/700108#700108
Here's some more ideas for you...
1) wrap your game update function with try/catch... catch any exception and have your code do the work for you in the catch block
2) Use OllyDbg to debug at the assembly language level
I've used OllyDbg for creating patches, solving "hack-me" puzzles, debugging native code, etc. I've never tried exactly what you're trying to do but I hear its more than capable of virtually anything. You dont even need to be an expert in assembly language. There are plenty tutorials to show you what to do.
1) wrap your game update function with try/catch... catch any exception and have your code do the work for you in the catch block
2) Use OllyDbg to debug at the assembly language level
I've used OllyDbg for creating patches, solving "hack-me" puzzles, debugging native code, etc. I've never tried exactly what you're trying to do but I hear its more than capable of virtually anything. You dont even need to be an expert in assembly language. There are plenty tutorials to show you what to do.
For MSVC a catch (...) block isn't guaranteed to catch crashes, which generally raise SEH exceptions. For a more detailed discussion on how SEH and C++ exception handling interact, including example code that does a stack trace see my article on the MSVC exception model. (There's a version on gdnet proper, but during one software upgrade or another the formatting got completely mangled.)
One interesting thing to highlight about the above post -- regular C++ catch blocks are executed after the stack has been unwound, which means a lot of your debugging information has already been destroyed by the time you get to respond to the error.
However, with SEH catch blocks, the "filter expression" is executed at the site of the error, before stack unwinding, which makes it the perfect tool for responding to crashes for debugging purposes.
However, with SEH catch blocks, the "filter expression" is executed at the site of the error, before stack unwinding, which makes it the perfect tool for responding to crashes for debugging purposes.
Sorry, you guys are right. The OP wasn't asking about debugging in general but how to do it outside VS.
But OllyDbg will nonetheless be very helpful.
But OllyDbg will nonetheless be very helpful.
Remote debugger? http://www.cprogramming.com/tutorial/visual_studio_remote_debugging.html
If you are using windows, I'd suggest the SetUnhandledExceptionFilter() WinApi call.
With that you can hook your custom execption handler instead of the OP's "unexpected error occured the program will stop" or similar message.
In that callback you can do "emergency" operation, for example I do an autosave, also you can write a stackdump, that can be loaded in the Visual Studio.
Here comes some source to save you time ;)
[source lang="cpp"]HMODULE dll=LoadLibrary("dbghelp.dll");
if (dll!=NULL) {
MINIDUMPWRITEDUMP p_dump=(MINIDUMPWRITEDUMP)GetProcAddress(dll,"MiniDumpWriteDump");
if (p_dump!=NULL) {
MessageBox(0,"We are sorry, the system encountered a critical error, and will stop. A log file has been created of the error.","Error",0);
// ... DO SOME ADDITIONAL DUMP HERE ...
CFile f;
if (f.create("crashdump.dmp")) {
_MINIDUMP_EXCEPTION_INFORMATION ex_info;
ex_info.ThreadId=GetCurrentThreadId();
ex_info.ExceptionPointers=p_exception_info;
ex_info.ClientPointers=NULL;
if (p_dump(GetCurrentProcess(),GetCurrentProcessId(),(HANDLE)f.GetHandle(),MiniDumpNormal,&ex_info,NULL,NULL)) {
// ... EVERYTHING IS FINE ...
f.close();
}
}
}
}
[/source]
The code is stripped, hopefuly not too much.
So after a crash, you can load that DMP file in Visual Studio, and you see the call stack, parameters, and some locals too (if you are lucky).
This method is very "fragile" tough, the smallest change in the project database or in the sources, and VS will complain about that, and you are lost..
With that you can hook your custom execption handler instead of the OP's "unexpected error occured the program will stop" or similar message.
In that callback you can do "emergency" operation, for example I do an autosave, also you can write a stackdump, that can be loaded in the Visual Studio.
Here comes some source to save you time ;)
[source lang="cpp"]HMODULE dll=LoadLibrary("dbghelp.dll");
if (dll!=NULL) {
MINIDUMPWRITEDUMP p_dump=(MINIDUMPWRITEDUMP)GetProcAddress(dll,"MiniDumpWriteDump");
if (p_dump!=NULL) {
MessageBox(0,"We are sorry, the system encountered a critical error, and will stop. A log file has been created of the error.","Error",0);
// ... DO SOME ADDITIONAL DUMP HERE ...
CFile f;
if (f.create("crashdump.dmp")) {
_MINIDUMP_EXCEPTION_INFORMATION ex_info;
ex_info.ThreadId=GetCurrentThreadId();
ex_info.ExceptionPointers=p_exception_info;
ex_info.ClientPointers=NULL;
if (p_dump(GetCurrentProcess(),GetCurrentProcessId(),(HANDLE)f.GetHandle(),MiniDumpNormal,&ex_info,NULL,NULL)) {
// ... EVERYTHING IS FINE ...
f.close();
}
}
}
}
[/source]
The code is stripped, hopefuly not too much.
So after a crash, you can load that DMP file in Visual Studio, and you see the call stack, parameters, and some locals too (if you are lucky).
This method is very "fragile" tough, the smallest change in the project database or in the sources, and VS will complain about that, and you are lost..
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
