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

Question

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?

Secern

Did you find a solution to the problem? – Shrine

Answer 1

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.

Philately

Answer 2

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. :)

Shandashandee

This worked for me, i have no clue why, could you please explain what it does – Weevil

learn.microsoft.com/en-us/windows-hardware/drivers/debugger/… – Shandashandee

Answer 3

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

Amine

The symbols loaded ok for his module. You can see line numbers for the statically-linked CRT. – Philately

'lm' listed me 'WINSPAMCATCHER (private pdb symbols)'. !itoldyouso WINSPAMCATCHER listed 'MATCH: winspamcather.pdb and WINSPAMCATCHER.dll' .reload /f with !sym noisy showed 'DBGHELP: WINSPAMCATCHER - private symbols & lines' But still when I run !analyze -v I don't see a line number. I get the same stack trace listed in the question. – Secern

Answer 4

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

• Enable

  .lines -e
  

• Disable

  .lines -d
  

• Toggle

  .lines -t
  

Harrier

Already tried that too. No luck. I am specifically looking to find if there is any way to correlate the offset 0x338 to a particular line number in the code. – Secern

what you are specifying is exactly what happens with the commands above. where are you looking for the line no's? they appear at the extreme right of each frame in the stack trace. – Harrier

yes I am checking the extreme right. I keep getting the same stack trace listed in the question. Is it possible that Windbg is not loading files from the source path I have mentioned? .srcpath lists the path I have set. Is there a way to check whether windbg is getting the required files while analyzing? – Secern