Analyzing Windows crash dumps generated on XP/32 machines with Win7/64?

2
votes

We have a problem with analyzing our Windows crash-dumps that were created on customer Windows XP/32 boxes on our development machines.

Many of our development machines are now Win7/64 boxes, but it appears that the crash-dumps generated under Windows XP cannot full resolve their binary dependency, thereby leading to warnings when displaying the call stacks in Visual Studio (2005).

For example, the msvcr80.dll cannot be resolved when loaded from a Win7 machine when the dump was generated on Windows XP:

On XP, the WinSxS path appears to be C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.4053_x-ww_e6967989\msvcr80.dll -- on Win7, the WinSxS path to the same DLL version seems to be: x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4053_none_d08d7da0442a985d

(I got this info from a forum thread on codeguru that link to an msdn article.)

Visual Studio (2005) can now no longer correctly resolve the binaries for the crash-dump.

How can I get Visual Studio to resolve all the correct binaries for my dump file?

Note: I have already correctly set up the symbol server. The public symbols for most system DLLs (kernel32.dll, etc) and our symbols of our own DLLs are correctly loaded. It is just that the symbols of DLLs that reside in the WinSxS folder are not loaded, because it appears that Vista/7 uses a different path scheme for these DLLs than XP does and therefore Visual Studio cannot find the dll (not the pdb) on the local dev machine and so cannot load the corresponding symbols for the dump file.

4
c++windowsvisual-studiowindbgcrash-dumps
You have tried .effmach x86 command? – Asha
@Asha : effmach is a WinDbg command (right?) and anyway, this has less to do with x86 vs. x64 mode, than (I think) with Windows XP vs. Windows Vista/7 – Martin Ba

4 Answers

3
votes

I think WinDbg should be used in this case to analyze the dumps. Then you can get rid of such roadblockers. But just remember to use x86 build of WinDbg (part of Debugging Tools for Windows).

2
votes

Use microsoft symbol server: http://support.microsoft.com/kb/311503
To do it, open the options dialog, goto ebugging\Symbols and add http://msdl.microsoft.com/download/symbols as a new location; then select a local path for caching and you are ready to go

2
votes

From what I understand, it's the binaries you are having difficulty resolving not the symbols correct?

Apart from copying over the respective binaries one option is to setup an x86 machine, share out it's C and just point your debugger to that machine.

You could have this in a VM for all your developers to access. When resolving the binaries just load them from the VM.

1
votes

try to use symchk.exe, it help you to pull symbols and binaries from a dump file. (or from a directory)

http://msdn.microsoft.com/en-us/library/ff558845%28v=VS.85%29.aspx

symchk could be found in the windbg package