Function name from Windows stack trace

▲
1
▼

How do I restore the stack trace function name instead of <UNKNOWN>?

    Event Type: Error
    Event Source:   abcd
    Event Category: None
    Event ID:   16
    Date:       1/3/2010
    Time:       10:24:10 PM
    User:       N/A
    Computer:   CMS01
    Description:
    Server.exe caused a  in module  at 2CA001B:77E4BEF7

    Build 6.0.0.334

    WorkingSetSize: 1291071488 bytes

    EAX=02CAF420  EBX=00402C88  ECX=00000000  EDX=7C82860C  ESI=02CAF4A8
    EDI=02CAFB68  EBP=02CAF470  ESP=02CAF41C  EIP=77E4BEF7  FLG=00000206
    CS=2CA001B   DS=2CA0023  SS=7C820023  ES=2CA0023   FS=7C82003B  GS=2CA0000

    2CA001B:77E4BEF7 (0xE06D7363 0x00000001 0x00000003 0x02CAF49C) 
    2CA001B:006DFAC7 (0x02CAF4B8 0x00807F50 0x00760D50 0x007D951C) 
    2CA001B:006DFC87 (0x00003561 0x7F6A0F38 0x008E7290 0x00021A6F) 
    2CA001B:0067E4C3 (0x00003561 0x00000000 0x02CAFBB8 0x02CAFB74) 
    2CA001B:00674CB2 (0x00003561 0x006EBAC7 0x02CAFB68 0x02CAFA64) 
    2CA001B:00402CA4 (0x00003560 0x00000000 0x00000000 0x02CAFBB8) 
    2CA001B:00402B29 (0x00003560 0x00000001 0x02CAFBB8 0x00000000) 
    2CA001B:00683096 (0x00003560 0x563DDDB6 0x00000000 0x02CAFC18) 
    2CA001B:00688E32 (0x02CAFC58 0x7C7BE590 0x00000000 0x00000000) 
    2CA001B:00689F0C (0x02CAFC58 0x7C7BE590 0x00000000 0x00650930) 
    2CA001B:0042E8EA (0x7F677648 0x7F677648 0x00CAFD6C 0x02CAFD6C) 
    2CA001B:004100CA (0x563DDB3E 0x00000000 0x00000000 0x008E7290) 
    2CA001B:0063AC39 (0x7F677648 0x02CAFD94 0x02CAFD88 0x77B5B540) 
    2CA001B:0064CB51 (0x7F660288 0x563DD9FE 0x00000000 0x00000000) 
    2CA001B:0063A648 (0x00000000 0x02CAFFEC 0x77E6482F 0x008E7290) 
    2CA001B:0063A74D (0x008E7290 0x00000000 0x00000000 0x008E7290) 
    2CA001B:77E6482F (0x0063A740 0x008E7290 0x00000000 0x00000000)
c++
windows
stack
stack-trace
asked on Stack Overflow Jan 11, 2010 by Sanjiv • edited Jan 12, 2010 by Thomas Bonini

5 Answers

▲
1
▼

Get the exact same build of the program, objdump it, and have a look at what function is at the address. If symbol names have been stripped from the executable, this might be a little bit difficult.

If the program code is in any way dynamic, you may have to run it into a debugger to find the addresses of functions.

If the program is deliberately obfuscated and nasty, and it randomises its function addresses in some way at runtime (evasive things like viruses, or copy-protection code sometimes do this) then all bets are off.

In general: The easiest way to find out what caused the crash is to follow the steps necessary to reproduce it in an instance of the application running in a debugger. All other approaches are much more difficult. This is why developers will often not spend time trying to tackle bugs which there are no known methods to reproduce.

answered on Stack Overflow Jan 11, 2010 by James
▲
0
▼

Try to run the same built from your IDE, pause it and jump to the adresses in assembly. Then you can switch to source code and see the functions there.

At least that's how it works in Delphi. And I know of this possibility in Visual Studio as well.

If you don't have the built in your IDE, you have to use a Debugger like OllyDbg. Run the exe that caused the errors and pause the application in OllyDbg. Go to the adresses from the stack trace. Open a similar application project in your IDE, run it and pause it. Search for the same binary pattern you see in OllyDbg and then switch to source code.

The last possibility I know is analysing the map file if you built it during your built.

answered on Stack Overflow Jan 11, 2010 by Tobias Langner
▲
0
▼

You need to have the debug info file (.pdb) next to the exe when the crash occurs.
Then hopefully, your crash dumping code can load it and use the information in it.

answered on Stack Overflow Jan 11, 2010 by shoosh
▲
0
▼

I use StackWalker - just compile it into the source of your program, and if it crashes you can generate a stack trace at that time, including function names.

answered on Stack Overflow Jan 11, 2010 by Cheeso
▲
0
▼

The most common cause is that you in fact don't have a module at the specified address. This can happen e.g. when you dereference an uninitialized function pointer, or call a virtual function using an invalid this pointer.

This is probably not the case here: "77E4BEF7" is with very high probability a Windows DLL, and 006DFAC7 an address in one of your modules. You don't need PDB files for this: Windows should always know the module name (.EXE or .DLL) - in fact, it needs first that module name to even find the proper PDB file.

Now, the remaining question is why you don't have the module information. This I can't tell from the information above. You need information about the actual system. For instance, does if have DEP? Is DEP enabled for your process?

answered on Stack Overflow Jan 12, 2010 by MSalters

User contributions licensed under CC BY-SA 3.0