CODEWITHSUNDEEP
c++windowsvisual-studiowindbgcrash-dumps
Martin Ba
Martin Ba

Reputation: 38961

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

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.

Upvotes: 2

Views: 783

Answers (4)

michael
michael

Reputation: 11

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

Upvotes: 1

Luke Kim
Luke Kim

Reputation: 1056

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.

Upvotes: 2

Lex Li
Lex Li

Reputation: 63289

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).

Upvotes: 3

Loghorn
Loghorn

Reputation: 2807

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

Upvotes: 2

Related Questions