2

I have a dump file and loaded it with WinDbg.

I've used !pe (print exceptions) to see the exception (a null reference exception). However, it points me to a method that contains ~100 lines.

Is it possible to find out the line where the exception is thrown away?

    0:000> !pe
   Exception object: 00000000822e7e28
    Exception type:   System.NullReferenceException
    Message:          Object reference not set to an instance of an object.
    InnerException:   <none>
    StackTrace (generated):
SP               IP               Function
00000000001FBDC0 000007FF06468F6B Utils.Page.OnActivate()+0x6db

What does +0x6db mean?

Thanks a lot, Dan

EDIT:

I have the source files but i cannot reproduce this issue. That's why i want to find out the exact line

EDIT2: (after Brian s suggestion to use the !u command)

Here's a snapshot after using the !u command 

    0:000> !u 000007ff03af9a38
   Normal JIT generated code
  Page.OnActivate()
  Begin 000007ff06468890, size 84b
  000007ff`06468890 53              push    rbx
  000007ff`06468891 55              push    rbp
  000007ff`06468892 56              push    rsi
  000007ff`06468893 57              push    rdi
  000007ff`06468894 4883ec78        sub     rsp,78h
  000007ff`06468898 488d6c2430      lea     rbp,[rsp+30h]
  000007ff`0646889d 488bf2          mov     rsi,rdx

and so on...

Is it correct to add 6db to 06468890 (the first pointer)?

Dan Dinu
  • 32,492
  • 24
  • 78
  • 114
  • `+0x6db` is the offset. You need the PDBs and exact source code that the PDBs and assemblies where created from. Then you should be able to get line numbers. – vcsjones Oct 10 '12 at 15:34
  • @vcsjones i have the sources and pdbs. how can i calculate the line number? – Dan Dinu Oct 10 '12 at 15:37
  • Brian's answer includes that. You need to `.reload` with the PDBs in the same dir as the assembly, or use `.sympath` to tell WinDbg where to look for the PDB, then `.reload` – vcsjones Oct 10 '12 at 15:40

1 Answers1

7

+0x6db is the offset into the method OnActivate where the exception was thrown. The reason you don't see a line number is because you don't have the correct PDB files. If you have the PDB files set your path to include these.

If you don't you can still get a pretty good indication of where the exception happened. The !u command will list a .NET annotated version of the code and from that you should be able to get the location in the source code. Please see this answer for more detail on using the !u command.

Community
  • 1
  • 1
Brian Rasmussen
  • 114,645
  • 34
  • 221
  • 317
  • Brian, can you please give me some details on how to use the !u command? I've used !dumpmt -md as in your other answer: !dumpmt -md 000007ff03af9c50 . then i used !u 000007ff03af9a38 (000007ff03af9a38 is the method description) and got the assembly code. Begin 000007ff06468890, size 84b 000007ff`06468890 53 push rbx etc ... How can i find the line number? – Dan Dinu Oct 10 '12 at 16:04
  • Sorry, let me clarify: You won't find the line number directly from using the `!u` command. However, the assembly will be annotated with .NET code details, so you should be able to correlate this with the source code. Also, the position of the exception will be highlighted in the output from `!u` by `>>>`. If the method is big, you'll have to look through a bit of assembly code. Once you find the marker, look at the annotations and correlate that with your source code. – Brian Rasmussen Oct 10 '12 at 16:37
  • @DanDinu I think that you should be passing the IP (instruction pointer) to !u. Hence, !u 000007FF06468F6B. Then look for the >>> as Brian wrote. – Dono Oct 10 '12 at 23:19
  • 1
    If you have private syms, use !sosex.muf. It will interleave source, IL and native code. – Steve Johnson Oct 11 '12 at 01:55
  • @BrianRasmussen Brian, there no ">>>" pointing to the exception in the !u ouput. Also, i can't seem to understand what annotations you're talking about. Thank you! – Dan Dinu Oct 11 '12 at 09:48
  • Missing annotations is probably due to some PDB mismatch. However, even without correct PDBs the `>>>` should show up. – Brian Rasmussen Oct 12 '12 at 17:02