views:

19

answers:

1

I know that when an application crashes, the system reports that it crashed at location 0x00004b79 in mydll.dll. I have the source code, and I have the binary, but I don't have a PDB or any listing files from the build of that DLL.

The crash is repeatable, but I can't install a debugger on the production machine, and the crash does not occur in development or debugging environments. I have set up Dr. Watson, and I have a crash dump and Dr. Watson log file.

The Dr. Watson log file contains this disassembly for the function that was being executed:

        10604b70 8b442408         mov     eax,[esp+0x8]
        10604b74 8b542404         mov     edx,[esp+0x4]
        10604b78 50               push    eax
FAULT ->10604b79 8b4120           mov     eax,[ecx+0x20]    ds:0023:00000020=????????
        10604b7c 52               push    edx
        10604b7d 6801800000       push    0x8001
        10604b82 50               push    eax
        10604b83 ff156c946210 call dword ptr [mydll!DllUnregisterServer+0x1720c (1062946c)]
        10604b89 c20800           ret     0x8

(INT 3 instructions precede and succeed the assembly snippet above.)

The stack trace only includes the address mydll+0x4b79. It doesn't give any caller information.

Loading up the crash dump in windbg didn't provide any additional information.

How can I determine in what function (or even better, which line of code) the crash occurred?

+1  A: 

Create a crash dump of your application and exmaine it using a debugger, WinDbg is the obvious choice here. A crash dump will give you a stack trace and detailed error information.

Edit: As for not being able to install a debugger, DrWatson is preinstalled and able to generate crash dumps which can then be examined on a different machine.

Jim Brissom
I've got a crash dump in WinDbg. However, still clueless as to which function I'm looking at. Stack trace just has mydll.dll+0x4b79. Disassembly is just a bunch of calls to other places in the DLL, mixed with lots of MOV, PUSH, and JZ instructions.
Kristopher Johnson
Easiest way? Rebuild the DLL with debug information, reproduce the crash. Harder, manual work: Trace the crash up to a known/exported function and work from there.
Jim Brissom
I was trying to avoid a rebuild and reinstall, but that's what I had to do. Thanks.
Kristopher Johnson