SOS does not support the current target architectu

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?

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

Answer 2

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."

Answer 3

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.

Answer 4

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.