title: How to load SOS in Windbg for a 32bit app running on a 64bit server
body: <p>Trying to debug a process dump of a 32-bit .NET application running on a 64-bit Windows edition Using debugger 6.3.9600.16384 x86.</p>
  
  <p>Spent a couple of hours searching for a solution. Found numerous topics on stackoverflow and other sites, however I'm unable to fix the issue. I'm about to pull my hair out.</p>
  
  <p>Checked the .NET version that was in use by the process</p>
  
  <pre><code>0:000&gt; lmv m clr
  start    end        module name
  618a0000 61f3b000   clr        (pdb symbols)          c:\symcache\clr.pdb\5182A0CFB60D40DB90EEF44DEC7ACB932\clr.pdb
      Loaded symbol image file: clr.dll
      Mapped memory image file: c:\symcache\clr.dll\52717E8469b000\clr.dll
      Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
      Image name: clr.dll
      Timestamp:        Wed Oct 30 22:47:48 2013 (52717E84)
      CheckSum:         0069CCD3
      ImageSize:        0069B000
      File version:     4.0.30319.18444
      Product version:  4.0.30319.18444
      File flags:       8 (Mask 3F) Private
      File OS:          4 Unknown Win32
      File type:        2.0 Dll
      File date:        00000000.00000000
      Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
  </code></pre>
  
  <p>Copied clr.dll, mscordacwks.dll and SOS.dll from the server running the application to C:\Temp\Dlls. Renamed mscordacwks.dll to mscordacwks_x86_x86_4.0.30319.18444.dll.</p>
  
  <pre><code>0:000&gt; .cordll -u -lp c:\temp\dlls -ve
  CLRDLL: Unable to get version info for 'c:\temp\dlls\mscordacwks.dll', Win32 error 0n87
  CLRDLL: Unable to get version info for 'c:\temp\dlls\SOS_x86_x86_4.0.30319.18444.dll', Win32 error 0n87
  Cannot Automatically load SOS
  CLRDLL: Loaded DLL c:\temp\dlls\mscordacwks_x86_x86_4.0.30319.18444.dll
  CLR DLL status: Loaded DLL c:\temp\dlls\mscordacwks_x86_x86_4.0.30319.18444.dll
  
  0:000&gt; .loadby sos clr
  0:000&gt; !clrstack
  Failed to load data access DLL, 0x80004005
  Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
              2) the file mscordacwks.dll that matches your version of clr.dll is 
                  in the version directory or on the symbol path
              3) or, if you are debugging a dump file, verify that the file 
                  mscordacwks_&lt;arch&gt;_&lt;arch&gt;_&lt;version&gt;.dll is on your symbol path.
              4) you are debugging on supported cross platform architecture as 
                  the dump file. For example, an ARM dump file must be debugged
                  on an X86 or an ARM machine; an AMD64 dump file must be
                  debugged on an AMD64 machine.
  
  You can also run the debugger command .cordll to control the debugger's
  load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
  If that succeeds, the SOS command should work on retry.
  
  If you are debugging a minidump, you need to make sure that your executable
  path is pointing to clr.dll as well.
  </code></pre>
  
  <p>Tried setting the executable path</p>
  
  <pre><code>0:000&gt; .exepath c:\temp\dlls
  Executable image search path is: c:\temp\dlls
  Expanded Executable image search path is: c:\temp\dlls
  
  ************* Symbol Path validation summary **************
  Response                         Time (ms)     Location
  OK                                             c:\temp\dlls
  0:000&gt; .reload
  ................................................................
  ..........................................................
  Loading unloaded module list
  .....
  0:000&gt; !clrstack
  Failed to load data access DLL, 0x80004005
  Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
              2) the file mscordacwks.dll that matches your version of clr.dll is 
                  in the version directory or on the symbol path
              3) or, if you are debugging a dump file, verify that the file 
                  mscordacwks_&lt;arch&gt;_&lt;arch&gt;_&lt;version&gt;.dll is on your symbol path.
              4) you are debugging on supported cross platform architecture as 
                  the dump file. For example, an ARM dump file must be debugged
                  on an X86 or an ARM machine; an AMD64 dump file must be
                  debugged on an AMD64 machine.
  
  You can also run the debugger command .cordll to control the debugger's
  load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
  If that succeeds, the SOS command should work on retry.
  
  If you are debugging a minidump, you need to make sure that your executable
  path is pointing to clr.dll as well.
  </code></pre>
  
  <p>Tried .loadby sos clr</p>
  
  <pre><code>0:000&gt; .loadby sos clr
  0:000&gt; !clrstack
  Failed to load data access DLL, 0x80004005
  Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
              2) the file mscordacwks.dll that matches your version of clr.dll is 
                  in the version directory or on the symbol path
              3) or, if you are debugging a dump file, verify that the file 
                  mscordacwks_&lt;arch&gt;_&lt;arch&gt;_&lt;version&gt;.dll is on your symbol path.
              4) you are debugging on supported cross platform architecture as 
                  the dump file. For example, an ARM dump file must be debugged
                  on an X86 or an ARM machine; an AMD64 dump file must be
                  debugged on an AMD64 machine.
  
  You can also run the debugger command .cordll to control the debugger's
  load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
  If that succeeds, the SOS command should work on retry.
  
  If you are debugging a minidump, you need to make sure that your executable
  path is pointing to clr.dll as well.
  </code></pre>
  
  <p>Who can help me? Don't know what else I can try anymore.</p>