Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Analyzing a crash in Windows: what does the error message tell us?

A small utility of mine that I made for personal use (written in C++) crashed randomly yesterday (I've used it roughly 100+ hours with no issues so far) and while I don't normally do this, I was feeling a bit adventurous and wanted to try and learn more about the problem. I decided to go into the Event Viewer and see what Windows had logged about the crash:

Faulting application StraightToM.exe, version 0.0.0.0, time stamp 0x4a873d19  Faulting module name : StraightToM.exe, version 0.0.0.0, time stamp 0x4a873d19 Exception code : 0xc0000005 Fault offset : 0x0002d160, Faulting process id: 0x17b4 Faulting application start time: time 0x01ca238d9e6b48b9. 

My question is, what do each of these things mean, and how would I use these to debug my program? Here's what I know so far: exception code describes the error, and 0xc0000005 is a memory access violation (tried to access memory it didn't own). I'm specifically interested in knowing more about the following:

  1. What does the fault offset mean? Does that represent the location in the file where the error occured, or does it mean the assembly 'line' where the error occured? Knowing the fault offset, how would I use a program like OllyDbg to find the corresponding assembly code that caused the error? Or -- even better -- would it be possible to (easily) determine what line of code in the C++ source caused this error?
  2. It's obvious that the time stamp corresponds to the 32-bit UNIX time at the time of the crash, but what does the 64-bit application start time mean? Why would it be 64-bits if the time stamp is 32?

Note that I'm primarily a C++ programmer, so while I know something about assembly, my knowledge of it is very limited. Additionally, this really isn't a serious problem that needs fixing (and is also not easily reproduced, given the nature of the program), I'm just using this more as an excuse to learn more about what these error messages mean. Most of the information about these crash logs that I've found online are usually aimed at the end-user, so they haven't helped me (as the programmer) very much.

Thanks in advance

like image 413
GRB Avatar asked Aug 23 '09 18:08

GRB


People also ask

How do you analyze an application crash dump?

You can analyze crash dump files by using WinDbg and other Windows debuggers. This content is for developers. If you are a customer who has received a blue screen error code while using your computer, see Troubleshoot blue screen errors.

What is crash dump analysis?

Crash dump analysis is the ability to record the state of the system when a crash occurs and then analyze that state at a later time to determine the cause of the failure. For instance, the state of the stack may be collected in order to generate a call stack showing the calls leading up to the failure.


1 Answers

The 64-bit time stamp is the time application's primary thread was created in 100-nanosecond intervals since January 1, 1601 (UTC) (this is known as FILETIME). The 32-bit timestamp is indeed in time_t format (it tells the time the module was created and is stored in the module's header).

I'd say 0x0002d160 is an offset from the module's load address (it seems too low for an absolute address). Fire up Visual Studio, start the debugger, take a look at the "modules" debug window. Your exe file should be listed there. Find the address where the module is loaded, add 0x0002d160 to that address and take a look at the disassembly at the resulting address. Visual Studio shows source code intermixed with the assembly, you should have no problem figuring out what source line caused the problem.

like image 90
avakar Avatar answered Sep 20 '22 06:09

avakar