CODEWITHSUNDEEP
windbg
mark
mark

Reputation: 62866

What is the role of the image path when debugging a crash dump with WinDbg?

Until now I always included the image path as part of the symbols path, so I had something like this:

Symbol search path is: srv*e:\Symbols*http://msdl.microsoft.com/download/symbols;e:\tmp\BackgroundJobEngine

But what is the correct approach?

  1. Should I include the image path as part of the symbols path as I do today?
  2. Should I pass it as the image path?
  3. Both?

Upvotes: 2

Views: 2550

Answers (1)

Thomas Weller
Thomas Weller

Reputation: 59513

.sympath

If your symbol path is

srv*e:\Symbols*http://msdl.microsoft.com/download/symbols;e:\tmp\BackgroundJobEngine

it means that

  1. WinDbg will search for symbols in e:\Symbols. If found, use it from there.
  2. if not found, it will look on the Microsoft symbol server, download symbols if available, store it in e:\Symbols and use it from there.
  3. if not found, it will look in e:\tmp\BackgroundJobEngine. If found, use it from there.

What actually happens in your case is not clear, because we don't know how you store symbols. If you add them to e:\Symbols, e.g. using symstore add in a post build step, the symbols for your executable will be used from e:\Symbols and e:\tmp\BackgroundJobEngine is useless.

If you don't use symstore and your symbols are actually located in e:\tmp\BackgroundJobEngine, symbols are used from that location.

If symbol information is in the executable (an exe may contain the full path to a PDB), WinDbg will also try to load it from there. If the executable was not built on your machine, that might fail due to the different paths, so adding a path like e:\tmp\BackgroundJobEngine can make sense.

.exepath

There's another case where the minidump file does not contain the executable itself in order to minimize the size, so WinDbg has a hard task disassembling etc.

I never had that case myself (mainly because I work with .NET a lot, which needs full memory anyway), but an example is given in the book "Memory Dump Analysis Anthology Collector's Edition" by Dmitry Vostokov:

1:kd> ub bfabc399
                ^ Unable to find valid previous instruction for 'ub bfabc399'

1:kd> uf driver!ProcessObject
No code found, aborting

which can be solved by setting the executable path with the .exepath command. WinDbg will then load the assembly itself (not necessarily the symbols) from that location.

Upvotes: 2

Related Questions