1

I have a 32 bit .Net 4.0 application running in a wow64 environment in a 64 bit machine.

The application encountered an error and I took a dump with 32 bit taskmanager present in C:\Windows\SysWOW64\taskmgr.exe

I am using a 32 bit Windebugger to analyze this dump. I loaded the following dlls.

1).loadby sos CLR

2).load mscordacwks ( from the client machine).

But still I am not able to use SOS commands like !clrstack,!threads etc.

I get the error: Failed to load data access DLL, 0x80004005

What did I do wrong?

Rockstart
  • 2,337
  • 5
  • 30
  • 59

2 Answers2

2

Seems that mscordacwks is not correctly loaded

One way

Try:

.cordll -u -ve -lp <absolute-path-to-directory-where-client-mscordacwks-is-placed>

The correct output should be:

CLRDLL: Loaded DLL <your-path>\mscordacwks.dll
CLR DLL status: Loaded DLL <your-path>\mscordacwks.dll

If you see:

CLR DLL status: No load attempts

rename your mscordacwks to the name suggested by .cordll:

0:000> .cordll
CLR DLL status: ERROR: Unable to load DLL mscordacwks_x86_x86_2.0.50727.3625.dll, Win32 error 0n87

and add the path where renamed mscordacwks resides to symbols:

.sympath+ <your-path>

and try your SOS command.

Other way

Get procdumpext.dll from Andrew Richard's skydrive : http://sdrv.ms/11C7S9c, load it into windbg (.load procdumpext.dll) and execute !loadsos.

Good luck! :)

Sebastian
  • 3,764
  • 21
  • 28
  • .cordll does not show the name of mscordacwks. It shows as "no Load attempts" – Rockstart Feb 18 '14 at 13:28
  • and !threads for example? It should be something like: CLRDLL: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscordacwks.dll:2.0.50727.5446 f:0 doesn't match desired version 2.0.50727.3625 f:0 CLRDLL: Unable to find mscordacwks_x86_x86_2.0.50727.3625.dll by mscorwks search – Sebastian Feb 18 '14 at 14:08
  • Also, which version of windbg are you using? In newer versions you may try `!analyse -v` and they should load the valid sos automatically. – Sebastian Feb 18 '14 at 14:09
  • The Skydrive link is broken. Do you have a copy of ProcDumpExt? – Thomas Weller Aug 16 '15 at 23:11
  • It seems this is now named PDE and available on https://onedrive.live.com/?cid=dae128bd454cf957&id=DAE128BD454CF957!7152&ithint=folder,zip&authkey=!ALq3LqMcfgs8JoM – Thomas Weller Aug 16 '15 at 23:30
  • @ThomasWeller have a look at netext.codeplex.com - I also wrote about it here: https://lowleveldesign.wordpress.com/2015/07/09/netext-sos-on-steroids/. It loads the valid SOS version automatically and adds interesting diagnostics commands as well – Sebastian Aug 17 '15 at 11:28
  • Actually I was looking for ProcDumpExt due to other features, not for a way of loading the correct version of SOS :-) – Thomas Weller Aug 17 '15 at 12:57
2

I had the best results in case I didn't only get mscordacwks.dll but also sos.dll from the client machine. I even had SxS issues with those files, so getting the files from the default .NET framework directory was not helpful either. Therefore I created the mscordacwks collector which gets all possible files for you.

However, you still need to find out which version to use. You can start by looking at the .NET framework version:

lm vm clr; *** .NET CLR 4
lm vm mscorwks; *** .NET CLR 2
lm vm coreclr; *** Silverlight

(In worst case, you have two different version of .NET loaded, in which case you are out of luck).

Once you know the exact version, you can load SOS of that version by full path

.load c:\mypath\SOS_AMD64_AMD64_4.0.30319.18444.dll

Note that the collected versions of SOS.dll will also be renamed to avoid file name conflicts. For more convenience, you can create a copy and just rename it to SOS.dll.

If there are still any mscordacwks.dll issues, you can proceed as proposed by @lowleveldesign. The tool should already have renamed data access files appropriately. If you find any bug, feedback is welcome.

Community
  • 1
  • 1
Thomas Weller
  • 55,411
  • 20
  • 125
  • 222