SOS does not support the current target architecture

Question

I am trying to use windbg to research a hang dump file created on an x64 machine for our x86 process. This is a 4.0 x86 application, so just to get an unmanaged stack, I had to do the following:

.loadby sos clr
.load wow64exts
!sw
kL

However, everytime I try to get the managed stack via !clrstack I get the error in the title. What am I missing?

Hopson

Are you running WinDbg on a Windows 8 machine? I get the same error message only in a Windows 8 machine. If I dump memory to a file I cannot run SOS even if I do !wow64exts.sw to switch to 32-bit mode. I can however execute SOS if I attach to the process... – Keane

Answer 1

I believe you will have to use the 32-bit task manager, located in C:\Windows\SysWOW64\taskmgr.exe to get a 32-bit dump.

More info here: http://blogs.msdn.com/b/tess/archive/2010/09/29/capturing-memory-dumps-for-32-bit-processes-on-an-x64-machine.aspx

Understanding

So, there is no way to use the current dump? – Hopson

One comment in the link above mentions running !wow64exts.sw, which may let you run stack related commands, like !clrstack. Never tried that myself as i've been able to grab a new dump instead. – Understanding

I am going to leave this open for a day or so to see if anybody has an answer that isn't that I am doa, otherwise I will accept this one – Hopson

@BenG: web.archive.org/web/20160205021908/https://… – Understanding

Answer 2

As others have said already, this can be caused by a 64 bit application (like the default Task Manager, for example) creating a dump file of a 32 bit process.

I was able to resolve the problem using the soswow64 WinDbg extension from poizan42 on GitHub. I've found it through this blog entry, which also provides some more detailed information about the issue.

Invitatory

I'm pretty sure this should be the answer now, but I may be a bit biased ;) – Endostosis

@Endostosis Thanks a lot for soswow64, it had made my work so much easier! – Invitatory

@poizan42: That is a great tool which should have much more attention. It works also with Windbg of 10.0.17713.1000 of the latest platform SDK. Great Work! – Cornela

Answer 3

I've always followed the recommendation of the bitness matching but never knew exactly why until I came across this article: http://blogs.msdn.com/b/dotnet/archive/2013/05/01/net-crash-dump-and-live-process-inspection.aspx which states:

"The DAC has a standardized interface and is used by the debugger to obtain information about the state of those abstractions, for example, the managed heap. It is essential to use the DAC that matches the CLR version and the architecture of the process or crash dump you want to inspect."

AND

"Note that the DAC is a native DLL and must be loaded into the program that uses ClrMD. If the dump or the live process is 32-bit, you must use the 32-bit version of the DAC, which, in turn, means that your inspection program needs to be 32-bit as well. The same is true for 64-bit processes. Make sure that your program’s platform matches what you are debugging."

Fictile

Answer 4

There is one more option that worked for me: - I had crash dump of a 64 bit process. - So, first, I needed SOS.dll and mscordacwks.dll from the machine (C:\Windows\Microsoft.NET\Framework64\v4.0.30319) where the dump was taken. - Based on two msdn articles (http://msdn.microsoft.com/en-gb/library/windows/hardware/ff562263%28v=vs.85%29.aspx, http://msdn.microsoft.com/en-gb/library/windows/hardware/ff540665%28v=vs.85%29.aspx), I loaded CLR this way:

.cordll -u -ve -I clr -lp <path to SOS.dll & mscordacwks.dll>

After this, !threads worked. I think, same should apply for 32-bit crash dumps.

Merissameristem

Answer 5

In my case I had:

• a .Net Framework 4.6 app, targeting x86.
• The app was running and being debugged on Windows 10, 64 bit.
• I was using sysinternals procdump to get a memory dump.

The WinDbg steps I wanted to follow were:

1. Start WinDbg.

2. Load memory dump file.

3. Run WinDbg commands:

   !analyze -v
   .cordll
   .effmach
   !clrstack

There were a few different errors I got with this.

• CLR DLL status: No load attempts

• SOS does not support the current target architecture (8664).

  0:000> .loadby sos clr
  The call to LoadLibrary(C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll) failed, Win32 error 0n193
  "%1 is not a valid Win32 application."
  Please check your debugger configuration and/or network access.
  Error: Failed to load extension C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll

The fix for me was to use the x86 adplus.exe to get the memory dump. After this, WinDbg worked as expected.

mkdir c:\procdumps  
cd C:\Program Files (x86)\Windows Kits\10\Debuggers\x86  
adplus.exe -hang -pn MyApp.exe -o c:\procdumps\ -quiet  

Talapoin