33

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

zar
  • 11,361
  • 14
  • 96
  • 178
GRB
  • 3,982
  • 4
  • 27
  • 21
  • 0xc0000005 - access denied... – Mandrake Oct 24 '09 at 15:14
  • 7
    For future readers, `0xc0000005` is not access denied, it's 'an access violation occurred'. Correct code, wrong facility. Access denied is code 5 under the Windows facility, so is `0x80070005`, often shortened to `0x00000005`. – niemiro Aug 20 '14 at 07:14

5 Answers5

20

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.

avakar
  • 32,009
  • 9
  • 68
  • 103
  • Ah ok, I've heard of `FILETIME` before, I don't know why I didn't put the pieces together in this instance. As for looking through the modules in Visual Studio, that sounds like a sure fire way to do it -- the only problem is, I built this program using MinGW. I have MSVC and could rebuild the .exe using it, but my guess is that the original fault offset (generated with the MinGW-built exe) wouldn't correspond to the MSVC-built exe, right? – GRB Aug 23 '09 at 19:28
  • 1
    I see. No the offsets wouldn't correspond. I don't know what kind of debug info MinGW generates, but I'd certainly start by looking at `objdump` utility, it might be able to identify the culprit routine. – avakar Aug 23 '09 at 19:33
  • objdump helped me a lot. After an hour or so of experimenting with different settings and (MinGW) debug builds, it appears that the fault occured with an internal library function that I was using. While there's no way to know this for sure, this suggests that it was a fault in the library and not my code. – GRB Aug 23 '09 at 21:31
  • 1
    Just because a crash happens in a a library doesn't mean it is not your code at fault. If I pass an invalid pointer to strlen it may be possible to cause a crash; this would not be the fault of the library author, but my fault. – Stephen Nutt Aug 24 '09 at 02:10
  • 1
    You're absolutely right -- it's impossible to know either way without information like the stack trace or variable values at the time of crash. That said, given the nature of the code and how the error was (apparently) caused by the dereferencing of an internal library pointer (i.e. a variable my code never had access to nor set at any point) I am confident in believing my code is not at fault (though we can never know for sure). – GRB Aug 24 '09 at 03:10
  • @avakar Is there a way to look up the module address without debugging? – patrick Oct 21 '16 at 21:46
  • @ÞÄTRÏÇK, Process Explorer can list modules in a process along with their base addresses. However the address will not help you with regards to the original problem. So, why are you asking? – avakar Oct 22 '16 at 19:22
7

There isn't much you're going to be able to do postmortem with this information.

The useful bit of information is the exception code, 0xc0000005, which in this case just means an access violation. So you dereferenced null or some other bit of memory you didn't own.

Fault offset, I suspect, is the offset from where your DLL was loaded into memory, so you could in theory add it to your base address and find the offending code, but I'm not sure.

Your best bet for debugging this is to catch it in the debugger the next time this happens. You can use Image File Execution Options to run your app automatically in the debugger. Make sure you have symbols ready (consider building DEBUG if you're currently using RELEASE).

i_am_jorf
  • 53,608
  • 15
  • 131
  • 222
6

Debugging god John Robbins built a little tool called CrashFinder to help with situations like this: https://www.wintellect.com/crashfinder-2-8-yes-native-code-still-lives/

It's always a good idea to save PDBs for every build you release to the public (this sounds like a tool you only use in private, but it might be a good idea to keep the PDB symbols around for the latest build).

ChrisN
  • 16,635
  • 9
  • 57
  • 81
Kim Gräsman
  • 7,438
  • 1
  • 28
  • 41
  • CrashFinder seemed very promising, but unfortunately didn't seem to work. The original fault address and the fault address + module start address both yielded little information. Even after building a test app with an obvious error (`*(int*)0 = 1;`), using the fault address given with CrashFinder on that app didn't work. May have something to do with MinGW programs vs. MSVC built programs. – GRB Aug 23 '09 at 21:21
  • Ah, I see. I don't know if MinGW can generate PDB symbols -- I suspect CrashFinder needs those to locate the problem location. – Kim Gräsman Aug 24 '09 at 06:26
  • 1
    Apparently not. You would definitely need extra information to find back a source line given a binary. PDBs provide that information, as far as it's even possible. But modern compilers sometimes make it impossible: if two functions map to the same instructions, and you don't compare their function pointers, they can share the same address. If a crash happens there, you'd need to know the caller to determine which of the two was called. Also, after inlining and optimizing, caller and callee may be mixed beyond even C++'s statement level. – MSalters Aug 24 '09 at 08:04
  • Some debuggers fall back on PE exports to give a vague idea of where the problem is. That really only works for DLLs, however. Good info on optimizations, I didn't know compilers could eliminate equal but unrelated code. I suppose that's one of the benefits of link-time code generation, that there's a higher-level view of optimization opportunities. Thanks! – Kim Gräsman Aug 24 '09 at 09:33
  • MinGW/GCC has a similar feature that I figured out when using `objdump`. I rebuilt my binary with debugging information enabled in my GCC settings and then used `objdump` on that .exe with the --source setting. That allowed `objdump` to intermix source lines/line numbers into the assembly dump, so I could see what C++ source code the faulting assembly line corresponded to. So, yes, MinGW/GCC has its own way of doing this. – GRB Aug 24 '09 at 14:36
  • mingw-w64 used to give usable offset addresses in the .map file that you could generate with -xLinker -Map=somefile.map but I don't know if it was windows updates or me getting a new compiler version that messed this up. – Jim Michaels Jun 02 '14 at 07:17
  • http://support.microsoft.com/kb/954447 sigh... managed code apparently causes the mismatch between .map file and minidump offset P8? – Jim Michaels Jun 02 '14 at 07:54
1

looks like there is still no good answer here, what if the crash happens outside the development environment. I think off set is the address where the assembly code crash. But you need to know where the start of the assembly code of that dll is. or maybe you don't need to know the start address, because you can use assembly tool to open dll, and find the assembly code by adding the offset to start address

Tony
  • 89
  • 10
0

My program CrashExplorer will help to analyze such crashes using the Fault offset:

It will work with map and listing files generated with Visual Studio: The map file lists all functions of the program with addresses. The listing files maps source code to assembler code per translation unit.

pulp
  • 698
  • 1
  • 6
  • 13