chitti
chitti

Reputation: 281

How to find line numbers corresponding to offsets in stack trace using windbg?

I have a crash dump of unmanaged C++ code.

I opened it with Windbg, set the symbol path and source path. Ran !analyze -v and got the following stack trace

STACK_TEXT:  
094efec0 7439fdc8 8b6ac787 00000000 00000000 WINSPAMCATCHER!_invalid_parameter_noinfo+0xc [f:\dd\vctools\crt_bld\self_x86\crt\src\invarg.c @ 125]
094eff3c 743a005e 085c37d8 74547d66 085c37d8 WINSPAMCATCHER!SpamCatcher::SCEngine::ruleUpdateLoop+0x338
094eff44 74547d66 085c37d8 8b6ac637 00000000 WINSPAMCATCHER!SpamCatcher::SCEngine::ruleUpdateLoopWrapperWin+0xe
094eff7c 74547e0e 00000000 094eff94 771df13c WINSPAMCATCHER!_callthreadstartex+0x1b [f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 348]
094eff88 771df13c 091707c8 094effd4 7769d80d WINSPAMCATCHER!_threadstartex+0x82 [f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c @ 326]
WARNING: Stack unwind information not available. Following frames may be wrong.
094eff94 7769d80d 091707c8 7e3e52db 00000000 kernel32+0x8f13c
094effd4 7769da1f 74547d8c 091707c8 00000000 ntdll+0x7d80d
094effec 00000000 74547d8c 091707c8 00000000 ntdll+0x7da1f

From the above stack trace I cannot see the line number of SCEngine::ruleUpdateLoop+0x338. Instead I see the offset 0x338. I guess this is some kind of assembly offset. Is it possible to find the line number corresponding to this offset using windbg?

Upvotes: 9

Views: 13293

Answers (4)

sergiol
sergiol

Reputation: 4335

Open the Call Stack Window (available in main window toolbar), then in Call Stack window's toolbar, toggle the "Source" push button to activate it. Next, on the main window type

.excr

Then in the call stack window, the entries will have file path and line number.

Finally if you have the source file(s) loaded, you can just double-click an entry and it will pop-up a window, with the line in question highlighted. :)

Upvotes: 5

Sriram Subramanian
Sriram Subramanian

Reputation: 2753

using ".lines" will toggle line numbers on or off

  • Enable

    .lines -e
    
  • Disable

    .lines -d
    
  • Toggle

    .lines -t
    

Upvotes: -2

John
John

Reputation: 5635

The symbols for your program (or is it a DLL?) were loaded correctly as evident from the line numbers for the CRT functions. Verify that you have specified /Zi to the compiler.

You can also try to figure out the line number by looking at the disassembly u WINSPAMCATCHER!SpamCatcher::SCEngine::ruleUpdateLoop WINSPAMCATCHER!SpamCatcher::SCEngine::ruleUpdateLoop+0x338 and de-compiling in your head. This is not as difficult as you might think. I recommend this paper as a start.

Upvotes: 1

pepsi
pepsi

Reputation: 6865

This usually happens when your module's symbols cannot be found. Use the lm command to list all modules.

lm

Look for SpamCatcher and see if it found your private symbols (good), or if it's using export symbols (bad).

The itoldyouso extension should also tell you if your PDBs match or not.

!itoldyouso SpamCatcher

If you need to troubleshoot the symbols problem further, try enabling verbose symbol loading, and then reload symbols:

!symnoisy
.reload /f

Upvotes: 4

Related Questions