Minidump Debug Symbol Loading Issue

[CraigH]

Hi,

I'm attempting to debug a minidump which was submitted to Windows Error
Reporting as a result of a crash of our managed .Net application. I'm having
problems however, when pointing WinDbg in the direction of the symbols for
the application (.Pdbs). I use the "sympath+ <path to symbols>" command to
set this up but when I execute this command WinDbg gives me a list of errors
saying:

"*** ERROR: Module load completed but symbols could not be loaded for
XXXXX.dll
Unable to load image C:\Program Files\CompanyName\ProductName\XXXXX.dll,
Win32 error 0n2"

and finally,

“Couldn't resolve error at 'ympath+ <path to symbols>' “ - (NOTE - the
'ympath' is not a typo here)

As far as I can tell, WinDbg is attempting to load the symbols from the path
that the application is installed to on the actual machine where the
mini-dump is generated (C:\Program Files\CompanyName\ProductName is the
install path for our application) rather than the location I have added to
the symbols path. Is there any reason that it would be looking for symbols
in the wrong directory like this?

I should say that our application is a 32 bit application and I'm debugging
on a 64 bit machine (using the 32 bit version of WinDbg).

Thanks in advance

[Pavel A.]

CraigH wrote:
>.... I use the "sympath+ <path to symbols>" command to

> set this up but when I execute this command WinDbg gives me a list of errors
> saying:
>
> "*** ERROR: Module load completed but symbols could not be loaded for
> XXXXX.dll
> Unable to load image C:\Program Files\CompanyName\ProductName\XXXXX.dll,
> Win32 error 0n2"
>
> and finally,
>
> “Couldn't resolve error at 'ympath+ <path to symbols>' “ - (NOTE - the
> 'ympath' is not a typo here)

the command is ".sympath" - and you typed it without the dot.

Regards,
--pa

[CraigH]

Hi,

Apologies for the delay, I've been looking into this a bit further.

Actually that was a typo in my mail, I had been entering the command
correctly into WinDbg(“.sympath+ ...”).

As I mentioned in the previous mail the modules seem to be loaded from the
path that the application is installed to on the actual machine that
generated the mini-dump. So when I execute the “lmf” command I see all of
the dlls of our application but in the install directory rather than where
I’ve pointed the symbols to – is this the correct behaviour?

To give some background, I’m attempting to analyse a mini-dump to get
detailed information on the exception that terminated our application but
when I inspect the exception (!pe –nested) I’m not getting any stack trace
(see the exception details below). This was why I was attempting to get the
symbols loaded correctly and suspected something was amiss when I saw the
paths of the loaded modules. Would there be any reason that the stack trace
for the exception isn’t being returned in the mini-dump?

Thanks in advance,

Exception object: 01d13c28
Exception type: <Unknown>
Message: An unhandled exception has occurred. See inner exception for detail
InnerException: _innerException, use !PrintException 01c699fc to see more
StackTrace (generated):
SP IP Function

StackTraceString: <none>
HResult: 80131500

Nested exception -------------------------------------------------------------
Exception object: 01c699fc
Exception type: <Unknown>
Message: An unhandled exception has occurred. See inner exception for detail
InnerException: System.NullReferenceException, use !PrintException 01c3a3fc
to see more
StackTrace (generated):
SP IP Function

StackTraceString: <none>
HResult: 80131500

[pat styles [microsoft]]

Hello Craig.

Would you please show me the actual sympath command that you execute along
with the response from the debugger. Then do a simple .sympath command
afterwards so we can see what the path is.

The lmf command shows the load location of the image in memory on the target
machine. If you want to see the load location of the file when a minidump
is resolved, use the !sym noisy command. You can learn more about this
command and other symbol triaging issues from the debugger documentation.

.pat styles [microsoft]

"CraigH" <Cra...@discussions.microsoft.com> wrote in message
news:8C0D4FC2-5F8D-43A7...@microsoft.com...

[CraigH]

Hi Pat,

The commands I’m executing are as follows:

“.sympath SRV*C:\localsymbols*http://msdl.microsoft.com/download/symbols“
and the debugger output is as follows:
Symbol search path is:
SRV*C:\localsymbols*http://msdl.microsoft.com/download/symbols

“.sympath+ C:\localsymbols\AppSymbols” – where the AppSymbols folder
contains the Pdbs for our application - the debugger output is as follows:
Symbol search path is:
SRV*C:\localsymbols*http://msdl.microsoft.com/download/symbols;C:\localsymbols\AppSymbols

And when i execute “.sympath” I get the same response from the debugger:
Symbol search path is:
SRV*C:\localsymbols*http://msdl.microsoft.com/download/symbols;C:\localsymbols\AppSymbols

After doing this (and executing the “!sym noisy” command) when I attempt to
analyze the exception (“!analyze –v”) I get lots of output like this:

“DBGHELP: C:\localsymbols\ AppSymbols \NewCommonInterfaces.pdb - mismatched
pdb”.

Now I realise this seems to indicate the wrong pdb is being used but what’s
the best way to verify that that is the case?

Thanks in advance,

Craig

[pat styles [microsoft]]

I don't think you need more verification. The output speaks for itself. If
you want to confirm, try this...

!IToldYouSo NewCommonInterfaces C:\localsymbols\ AppSymbols
\NewCommonInterfaces.pdb

I don't expect that it will correct the earlier data.

.pat styles [microsoft]

"CraigH" <Cra...@discussions.microsoft.com> wrote in message

news:ABDB77B1-6625-4BEC...@microsoft.com...