title: Where can I get VC++ 2005 redistributable version 8.0.50727.5592 including PDBs?
body: <p>Sometimes crash dump files of our customers will contain references to</p>
  
  <pre><code>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  
  </code></pre>
  
  <p>The problem is, I don't get proper stack traces for these, because these DLLs (<a href="http://support.microsoft.com/kb/2465367" rel="nofollow">from April, 2011</a>) were superseded by a further patch <a href="http://support.microsoft.com/kb/2538218" rel="nofollow">from June, 2011</a> and <a href="http://wiki.mcneel.com/developer/sdksamples/vcredist" rel="nofollow">contrary to what I can find on the net</a>, the <a href="http://www.microsoft.com/en-us/download/details.aspx?id=26347" rel="nofollow">download from MS</a> does <em>not</em> contain the 5592 version, but only the 6195 version of the CRT/MFC/... DLLs.</p>
  
  <p>Our executable's manifest points to version <code>8.0.50727.4053</code> 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)</p>
  
  <pre><code>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".
  </code></pre>
  
  <p>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).</p>
  
  <p>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) --</p>
  
  <pre><code>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  
  </code></pre>
  
  <p><strike>I must assume that</strike> Microsoft <strike>purged the 5592 version of these files from their symbol server, thereby</strike> 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.</p>
  
  <p>Is there still a download from MS for the original patch that would include the 5592 DLL and PDB files?</p>
  
  <hr>
  
  <p>Update: It would seem that the MS symbol server <em>does</em> contain the PDB file for the 5592 DLL verison, but it <em>does not</em> contain the DLL. (Now whether that makes sense is another question, but maybe that's the way it works with these DLLs.)</p>
  
  <p>I could determine the following:</p>
  
  <ul>
  <li>PDB for 4053 : <code>...\Cache\msvcr80.i386.pdb\7D5669C7431445CD84D149AE19FE3CD51\msvcr80.i386.pdb</code></li>
  <li>PDB for 5592 (because WinDbg does load that one) : <code>...\cache\msvcr80.i386.pdb\3FA5DD7B7FAF4F2EAC5ABEDC03012DB21\msvcr80.i386.pdb</code></li>
  <li>PDB for 6195: <code>...Cache\msvcr80.i386.pdb\54C9E2F351544D1CB39517DC4B299EA81\msvcr80.i386.pdb</code></li>
  </ul>