Jump to content
  • Advertisement
Sign in to follow this  
Cwiddy

Crash Addresses, Map Files and DLLs [MSVC]

This topic is 3558 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I generate a map file with all my projects (exe and dlls). When my app crashes I know what map file to check and how to read the map file to find the problem in my code. I don't know how to use them with a pdb to find the exact line, but I can find the function from the mapfile which is usually good enough. My project is dynamically linked to the runtime (not an option to change it due to dependence on some 3rd party libs). So my question is how do I trace back to the faulting function in my exe? I currently have a crash coming from mscvr80.dll and the offset is ( 0x00008aa0 ) which I think is dereferencing an invalid iterator. This time I lucked out since it was easily reproducible for me.

Share this post


Link to post
Share on other sites
Advertisement
In this case, you'd want to look at the stack at the point of the crash. In the debugger, it should show up automatically when debugging. If it doesn't, Ctrl-7 will bring up the call stack on recent versions of MSVC.

Share this post


Link to post
Share on other sites
Unfortunately that isn't an option. It is a release build and the person using is 10000km away.

Guess it might not be possible, was looking for a way to trace back with the offset somehow I think DrWatson logs more information where the dll is loaded, but not sure if there is enough there to figure it out, I will need to dig deeper. Thanks anyways!

Share this post


Link to post
Share on other sites
Depending on the operating system and installed software that exists on the client computer, the system may automatically generate a crash dump or minidump when the program dies. They typically end with a .dmp and can be opened in Visual Studio by using Open Project and selecting the .dmp file. If the system doesn't generate a dump automatically, you can have your program generate a dump using MiniDumpWriteDump(). This generally involves writing a SEH filter to catch otherwise unhandled SEH exceptions and invoking MiniDumpWriteDump() the filter expression which will create a dump containing the stack at the time of the unhandled exception. Alternately, you can use StackWalk64() to perform a stack walk in the exception filter instead of generating the crash dump. This would contain less information than a full dump, but often has the advantage of being more human readable without needing to load up the debugger. An example of the latter is in the source code at the end of my article here.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!