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.