WinDbg x64: Cannot debug a crash dump - failed to load data access DLL

Question

I attached WinDbg to a running process and had the process crashed (I have a separate question re. that case). Once the program crashed, WinDbg stopped and allowed me to deb

Answer 1

I hit this regularly when debugging with minidumps from the site. Quite how it's happened in your case I'm not sure. Usually, it happens when the version of CLR that was loaded when the dump was taken is not available on your debugging machine. In your case, they're the same machine, so it should all probably just work. I'm sure there will be others who can explain exactly why it isn't.

In the meantime, here's what I do with my site dumps. Windbg is looking for "the right version" of mscordacwks.dll. So we give it that version and tell it where to look for it.

First - if I spoof all of this, by deleting mscordacwks.dll, windbg goes off and loads it from the Microsoft symbol server, so do make sure your symbols are set up correctly to download symbols from the Microsoft symbol server and give it another go.

Now - assuming that didn't work, check exactly which version is the "right version". List the module info with "lm v clr" and check your CLR version that is ACTUALLY loaded. Mine is 4.0.30319.239. Ok - now find that version of mscordacwks.dll. Let's assume it can be found in the normal .NET framework installation on your machine (C:\Windows\Microsoft.NET\Framework64\v4.0.30319). Do check the version matches exactly (right-click, properties etc)! Take it and put it in a safe place (I use D:\Symbols\_Images). Follow the instructions that windbg gave you on renaming the file. mscordacwks_.dll would be mscordacwks_AMD64_AMD64_4.0.30319.239.dll.

Now set up your executable image path (".exepath D:\Symbols\_Images") so windbg knows where you've put it.

You've now got "the right version of mscordacwks", and renamed it so that Windbg knows what it's looking for, and told it where you've put it.

If that STILL isn't working, then try ".cordll -ve -u -l" and also "!sym noisy" to turn on verbose logging of both the cordll load and the symbol server, then try !CLRStack again. Maybe the output of those two commands will tell you exactly what it's trying to load and you can figure out why it won't do it...

Answer 2

Sounds like you did a custom install of windbg and did not select all the extensions that you require. The Win32 error n2 is generally a sign of this problem.

Answer 3

Is the process which you are trying to debug a 32-bit? What does the task manager-processes listing say ? If its 32-bit process then you need to use 32-bit windbg. Otherwise, I don't see why .load sos clr should fail.

ps: (windbg noob alert), so i apologize if this sounds lame. Just trying to help.

Answer 4

I just spent the day debugging a bunch of cases where we ran into this scenario. The SOS+CLR on the same box as the crash were unable to load within WinDbg, and "lm v" reported two different versions for the same module:

0:011> lm vM *clr.dll
start             end                 module name
000007fe`f2f50000 000007fe`f38b0000   clr      # (pdb symbols)          c:\symbols\clr.pdb\EDFF900AC9B94C1D9B32696A7759891A2\clr.pdb
    Loaded symbol image file: clr.dll
    Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
    Image name: clr.dll
    Timestamp:        Sun Apr 21 03:36:04 2013 (5173C114)
    CheckSum:         0095F379
    ImageSize:        00960000
    File version:     4.0.30319.18052
    Product version:  4.0.30319.18052
    File flags:       8 (Mask 3F) Private
    File OS:          4 Unknown Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft® .NET Framework
    InternalName:     clr.dll
    OriginalFilename: clr.dll
    ProductVersion:   4.0.30319.18047
    FileVersion:      4.0.30319.18047 built by: FX45RTMGDR
    PrivateBuild:     DDBLD320
    FileDescription:  Microsoft .NET Runtime Common Language Runtime - WorkStation
    LegalCopyright:   © Microsoft Corporation.  All rights reserved.
    Comments:         Flavor=Retail

Backing Details

The file Timestamp (0x5173C114), Checksum (0x0095F379), and Version (4.0.30319.18052) stored in the MINIDUMP_MODULE structure in the minidump's module-list-stream was for the newer CLR. Cracking open the minidump file myself and looking directly at the stream data:

MINIDUMP_MODULE : (pack:8 size:112) 
  +0x000 .BaseOfImage UInt64 : 8791579230208 (0x7FEF2F50000)
  +0x008 .SizeOfImage UInt32 : 9830400 (0x960000)
  +0x00C .CheckSum UInt32 : 9827193 (0x95F379)
  +0x010 .TimeDateStamp UInt32 : 1366540564 (0x5173C114)
  +0x014 .ModuleNameRva UInt32 : 107828 (0x1A534)
  +0x018 .VersionInfo tagVS_FIXEDFILEINFO : (pack:8 size:52) 
    +0x000 .dwSignature UInt32 : 4277077181 (0xFEEF04BD)
    +0x004 .dwStrucVersion UInt32 : 65536 (0x10000)
    +0x008 .dwFileVersionMS UInt32 : 262144 (0x40000)
    +0x00C .dwFileVersionLS UInt32 : 1987004036 (0x766F4684)

Splitting the high and low words out of dwFileVersionMS we get 4 and 0.
Splitting the high and low words out of dwFileVersionLS we get 30319 and 18052.

Using dumpchk.exe, and looking at the module details in the PEB, we can see a different Timestamp (0x515530CE), one that actually corresponds to the older (18047) version:

7fef2f50000 515530ce Mar 28 23:12:30 2013 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll

Looking at the raw memory in the crash dump where clr.dll is loaded, you can see the Checksum (0x00965F80) and Timestamp (0x515530CE) of version 4.0.30319.18047:

0:011> db 000007fe`f2f50000 
000007fe`f2f50000  4d 5a 90 00 03 00 00 00-04 00 00 00 ff ff 00 00  MZ..............
000007fe`f2f50010  b8 00 00 00 00 00 00 00-40 00 00 00 00 00 00 00  ........@.......
000007fe`f2f50020  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
000007fe`f2f50030  00 00 00 00 00 00 00 00-00 00 00 00 18 01 00 00  ................
000007fe`f2f50040  0e 1f ba 0e 00 b4 09 cd-21 b8 01 4c cd 21 54 68  ........!..L.!Th
000007fe`f2f50050  69 73 20 70 72 6f 67 72-61 6d 20 63 61 6e 6e 6f  is program canno
000007fe`f2f50060  74 20 62 65 20 72 75 6e-20 69 6e 20 44 4f 53 20  t be run in DOS 
000007fe`f2f50070  6d 6f 64 65 2e 0d 0d 0a-24 00 00 00 00 00 00 00  mode....$.......
0:011> db
000007fe`f2f50080  39 e4 28 ed 7d 85 46 be-7d 85 46 be 7d 85 46 be  9.(.}.F.}.F.}.F.
000007fe`f2f50090  81 f2 f8 be 79 85 46 be-81 f2 fa be 74 85 46 be  ....y.F.....t.F.
000007fe`f2f500a0  74 fd c5 be 73 85 46 be-74 fd c2 be c9 85 46 be  t...s.F.t.....F.
000007fe`f2f500b0  ee 41 8d be 7f 85 46 be-e3 25 81 be 7c 85 46 be  .A....F..%..|.F.
000007fe`f2f500c0  ee 41 88 be 6b 85 46 be-ee 41 89 be 78 85 46 be  .A..k.F..A..x.F.
000007fe`f2f500d0  ee 41 8b be 64 85 46 be-7d 85 47 be ca 87 46 be  .A..d.F.}.G...F.
000007fe`f2f500e0  81 f2 ff be 76 85 46 be-ee 41 9e be 70 87 46 be  ....v.F..A..p.F.
000007fe`f2f500f0  ee 41 8c be 7c 85 46 be-ee 41 8f be 7c 85 46 be  .A..|.F..A..|.F.
0:011> 
000007fe`f2f50100  ee 41 8a be 7c 85 46 be-52 69 63 68 7d 85 46 be  .A..|.F.Rich}.F.
000007fe`f2f50110  00 00 00 00 00 00 00 00-50 45 00 00 64 86 06 00  ........PE..d...
000007fe`f2f50120  ce 30 55 51 00 00 00 00-00 00 00 00 f0 00 22 20  .0UQ.........." 
000007fe`f2f50130  0b 02 0b 00 00 90 69 00-00 c2 2b 00 00 00 00 00  ......i...+.....
000007fe`f2f50140  40 51 13 00 00 10 00 00-00 00 f5 f2 fe 07 00 00  @Q..............
000007fe`f2f50150  00 10 00 00 00 02 00 00-06 00 00 00 0a 00 00 00  ................
000007fe`f2f50160  06 00 00 00 00 00 00 00-00 e0 95 00 00 04 00 00  ................
000007fe`f2f50170  80 5f 96 00 02 00 60 01-00 00 10 00 00 00 00 00  ._....`.........

I also jumped ahead in memory and looked at the Version resource in memory and saw the 18047 version string.

So now we have a minidump with conflicting information about what version of clr.dll was actually in use.

What Caused It

I also found out that our IT department recently pushed out a handful of Windows Updates, so:

• While an application was running, an update to the CLR was installed.
• The file in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ was updated to the newer version (4.0.30319.18052)
• The application Crashed
• MiniDumpWriteDump apparently used the file-on-disk information when storing the module list in the crash dump file (4.0.30319.18052)
• WinDbg wasn't able to correlate the version stamped in the crash dump with what was in the process' memory as it had conflicting information.

To verify this, I manually modified the MINIDUMP_MODULE entry for clr.dll to change the Checksum, Timestamp, and Version from 18052 to 18047. After reloading the hacked up .dmp file in WinDbg and setting the exepath to the proper sos+clr dlls, I was able to successfully execute the sos commands and get a valid stack trace.

Bottom Line

We essentially ended up with a minidump file that has conflicting information about which version of clr.dll is loaded into the process, preventing SOS from identifying the correct clr engine. This is likely a bug in MiniDumpWriteDump as it saves out the crash dump file. But should only happen when the backing version of the CLR has been updated while your application was running.