How can I get the name of the function that crashed given just a module name and offset?

The only information a customer had regarding a crash was the following:

Faulting application name: Contoso.exe, version:, time stamp: 0x4a425e19
Faulting module name: Contoso.exe, version:, time stamp: 0x4a425e19
Exception code: 0xc0000005
Fault offset: 0x000050d0
Faulting process id: 0x1910
Faulting application start time: 1cad18414e63580

They wanted to know what function crashed.

This is an application of techniques for restoring symbols to a stack trace that was generated without symbols, but in the simplified case where there is only one address, not an entire stack trace (so you need to do the work only once), and in the special case where all you have is a module name and an offset.

The first step is to find the correct executable. The time stamp in the event log is 0x4a425e19, which we recognize as a UNIX style timestamp. This handy online converter says that it's June 24, 2009 at 17:10:49 GMT. Dig into your archives and find a build generated around that time and check the time stamp in the file header. The link /dump /headers command will tell you:

             14C machine (x86)
               3 number of sections
        4A1ECBC2 time date stamp Thu May 28 10:37:06 2009

Okay, that's the wrong one since the time stamps don't match. Keep looking until you find the right one, and also grab its matching symbol file (contoso.pdb).

Once you do, you can load it up in the debugger.

C:\> ntsd -z contoso.exe

ModLoad: 00100000 00130000   contoso.exe

0:001> u 0x00100000+0x50d0 L1
001050d0 8a18             mov     bl,[eax]  

Okay, so at least you know that the crash was in the CView­Report­Task::Run method. You can also ask for line number information:

0:001> .lines
Line number information will be loaded
0:001> u 0x00100000+0x50d0 L1
contoso!CViewReportTask::Run+0x102 [viewreporttask.cpp @ 250]:
001050d0 8a18             mov     bl,[eax]  

We see that the crash was on line 250.

To figure out what part of line 250, you'll have to dig into the disassembly and reverse-compile the code to see exactly which part of line 250 is being executed at 001050d0. You don't know what value is in any of the registers, so all you know is that the pointer is invalid; you don't know whether it is null or wild, or how it got that way.

Bonus chatter: You probably should sign up for Windows Error Reporting so that you will receive crash dumps automatically, which provide a full stack trace instead of a single address, and it also captures register values and limited contents of the stack. You can also ask for more information to be captured in future crash dumps.

Bonus exercise: Use your time stamp recognition skills to determine what Faulting application start time corresponds to.

Comments (9)
  1. Brian_EE says:

    Bonus Exercise: It’s a 64-bit WIN32 FILETIME, I think it is Thursday, April 1, 2010 10:14:15am

    Unless Raymond is “fooling” with us….

    1. IanBoyd says:

      Looks like Windows Error Reporting won’t let me receive crash dumps from my digitally signed applications in the wild: “The digital certificate is not from Symantec Inc. Only Symantec class 3 certificate is accepted”.

      I wish the fact that i have the private key corresponding to the digital signatures on the crash dumps sitting in WinQual was enough to prove that i signed those applications.

      1. Brian_EE says:

        According to this page: ( there are multiple vendors whose certificates are acceptable.

      2. Joshua says:

        Indeed so do I. Liars certificates are inherently adequate in this case.

      3. Henri Hein says:

        I have had this problem before, but it wasn’t an issue what certificate the executable is signed with. It was just that the winqual service itself required a Symantec certificate. Once I had signed up with winqual, the WER database accepted crash reports from my executables signed with non-Symantec certificates. I’m using past tense here, since I cannot be certain this has not changed, but it seems doubtful.

        1. nikos says:

          here’s an idea to cut the middleman out: create your own minidump file, then have your program sending it automatically to you via email (with the user’s consent of course).

  2. Joshua says:

    And then you get that one where the crash at the top of an unmapped page, and the previous page is backed by the pagefile. But oh look, the previous page starts to disassemble into something that looks like code about a third of the way down the page, and just stops in the middle.

  3. Piotr Siódmak says:

    You don’t need no handy online converters

    .formats 0x4a425e19
    Time: Wed Jun 24 19:10:49 2009
    .formats 1cad18414e63580
    Time: Thu Apr 1 11:14:15.000 2010 (UTC + 1:00)

    Mind the timezones.

  4. Dave Bacher says:

    I cannot speak for WER — but the Windows Store error reporting is Godly.

Comments are closed.

Skip to main content