Sometimes crash dump files of our customers will contain references to
mfc80u.dll *C:\Windows\winsxs\x86_microsoft.vc80.mfc_1fc8b3b9a1e18e3b_8.0.50727.5592_none_cbf62b764709d1c9\mfc80u.dll N/A N/A No matching binary found. 20 8.00.50727.5592 11.01.2011 07:32 6E860000-6E96F000 memory.dmp: Native
msvcr80.dll *C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.5592_none_d09196c24426e2d4\msvcr80.dll N/A N/A No matching binary found. 21 8.00.50727.5592 11.01.2011 06:17 74E40000-74EDB000 memory.dmp: Native
The problem is, I don't get proper stack traces for these, because these DLLs (from April, 2011) were superseded by a further patch from June, 2011 and contrary to what I can find on the net, the download from MS does not contain the 5592 version, but only the 6195 version of the CRT/MFC/... DLLs.
Our executable's manifest points to version 8.0.50727.4053 but that doesn't help as this version is superseded by 5592 and later by 6195. The SxSTrace output goes like this: (just ignore the german text and look at the version numbers)
INFORMATION: Verweis "Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.4053"" wird aufgelöst.
...
INFORMATION: Für ProcessorArchitecture "x86" wird der Verweis aufgelöst.
INFORMATION: Für ProcessorArchitecture "x86" wird der Verweis aufgelöst.
INFORMATION: Verweis für Kultur "Neutral" wird aufgelöst.
INFORMATION: Bindungsrichtlinie wird angewendet.
INFORMATION: Sucht nach Herausgeberrichtlinien in "C:\Windows\WinSxS\manifests\x86_policy.8.0.microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_517205a10f4550e3.manifest".
INFORMATION: Die Assemblierungsversion wurde von der Herausgeberrichtlinie umgeleitet.
INFORMATION: Die Bereitstellungsrichtlinien-Assemblierungsidentität ist Microsoft.VC80.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195".
Now, maybe I'll be able to obtain the exact DLLs from the customer's PC, but that still leaves me with the DLLs only, and I still won't have any debug symbols (PDB files).
Since, looking at my dump (e.g. for kernel32), I can see that normally all system DLLs should be loaded from the MS symbol servers (or its cache) --
kernel32.dll C:\WINDOWS\Symbols\Cache\kernel32.dll\4e211484100000\kernel32.dll N/A N/A Symbols loaded (source information stripped). C:\WINDOWS\Symbols\Cache\wkernel32.pdb\0EB73428EC4E430FB8EDD94C5946855B2\wkernel32.pdb 3 6.01.7600.16850 16.07.2011 05:33 76820000-76920000 memory.dmp: Native
I must assume that Microsoft purged the 5592 version of these files from their symbol server, thereby effectively preventing any useful debugging if a customer PC does include the April,2011 update but not the June,2011 update. From what I can infer from the MS pages, these updates are included in Windows Update, so there's really nothing I can do if a customer has an incomplete update mechanism.
Is there still a download from MS for the original patch that would include the 5592 DLL and PDB files?
Update: It would seem that the MS symbol server does contain the PDB file for the 5592 DLL verison, but it does not contain the DLL. (Now whether that makes sense is another question, but maybe that's the way it works with these DLLs.)
I could determine the following:
...\Cache\msvcr80.i386.pdb\7D5669C7431445CD84D149AE19FE3CD51\msvcr80.i386.pdb...\cache\msvcr80.i386.pdb\3FA5DD7B7FAF4F2EAC5ABEDC03012DB21\msvcr80.i386.pdb...Cache\msvcr80.i386.pdb\54C9E2F351544D1CB39517DC4B299EA81\msvcr80.i386.pdbThe pdb files are all that is needed to analyze a (full) dump with WinDbg - the binaries are not needed for WinDbg, but the Visual Stuido (2005) debugger does seem to require the binaries.
So in this case do not use VS, but use WinDbg to analyze this particular dump.