3

I'm pretty new to WinDbg and I'm trying to find a bug which has my application hanging for no appearent reason. I'm not sure I'm doing things right, but I understand that I need both symbols for the system dlls aswell as the .exe I'm debugging. Thus, I set up my symbol path like this: 

srv*c:\websymbols*http://msdl.microsoft.com/download/symbols;S:\MY\PATH

The second path pointing to a folder where I placed the .pdb that was generated by VS. I'm positive that's the correct .pdb file, but it was built on a different architecture (not sure if this is an issue). I would like to see a complete stack trace for a start, so I ran !analyze-v. The output looks like this. As you can see it lists APPLICATION_HANG_WRONG_SYMBOLS as primary problem. So I ran .reload /f, giving me this output. I have no symbols for dnAnalytics or Vertec.Interop, so these errors make sense, but there are some missing checksums and iphlpapi.pdb was not found.

So my questions would be: Why does WinDBG lists wrong symbols as primary problem, even though I'm positive I do have the right .pdb file available? (I'm running WinDBG on the same machine the dump was generated). To what extent can I trust the stack trace even thought my symbols are wrong, appearently? Does anyone see a obvious problem that could cause a hang in my application from the stack trace already? Any pointers appreciated!

Matthias
  • 506
  • 5
  • 16
  • Alright, I tried the following: recompiled the application on the same machine, provoked a hang, dumped the memory, loaded it up in WinDBG. Naturally, I had the correct pdb available, since I just recompiled (ruling out any chance that the problems were caused by the wrong pdb), and pointed WinDBG to it just as above. Wrong Symbols again! (c.f. [the output](http://pastebin.com/xzqN38uD)). Why is WinDBG looking for the BJM.exe symbols on the microsoft server in this case? – Matthias Apr 28 '11 at 15:28

2 Answers2

4

The "wrong symbols" here is probably because you are using 64-bit CLR with version less than 4.0 and the !analyze extension has some trouble decoding the mixed native / managed stack.

Why is WinDBG looking for the BJM.exe symbols on the microsoft server in this case?

This is because you put the symbol server before you local path in the symbol path. Windbg does not know which module is yours and which is Microsoft's. It just looks for the PDB file for the module in the order speicified by the symbol path.

To what extent can I trust the stack trace even thought my symbols are wrong, appearently?

Stacks on x64 are very reliable since the stack-walk does not require symbols. Symbols are reliable (that is you do not have wrong symbols) unless you forced windbg to ignore wrong timestamp / checksum with .reload /f /i

In some cases the address -> symbol may seem wrong. This is usually due to small functions that have the same code (very common in C++ code if the functions are virtual or the code is not optimized)

John
  • 5,561
  • 1
  • 23
  • 39
0

Try using !sym noisy to get some more information about what it's actually looking at (docs). !itoldyouso may also be useful here (link)

the_mandrill
  • 29,792
  • 6
  • 64
  • 93
  • The output after .reload /f shown above is actually with !sym noisy. But I'll have a look at !itoldyouso tomorrow at work, thanks for your input. – Matthias Apr 28 '11 at 19:57
  • I just ran !itoldyouso on my executable as suggested the [output](http://pastebin.com/25sf7KZX) tells me that it was matched correctly. Can I conlcude from the line `FAILURE_BUCKET_ID: APPLICATION_HANG_WRONG_SYMBOLS_80000007_user32.dll!NtUserWaitMessage` that user32.dll is causing the wrong symbols message? !itoldyouso suggests this is fine aswell though... – Matthias Apr 29 '11 at 09:50
  • I'm not sure -- I regularly get a wrong symbols warning but I still get useful output. If you're looking at a hang, try using `!analyze -v -hang` and also try the `!locks` command which will tell you if there are any locks/mutexes being held by another thread. – the_mandrill Apr 29 '11 at 12:05