当你在64位Windows系统上抓32位进程的dmup文件时
如果用的是64位任务管理器那么在用Windbg加载后要用!wow64exts.sw切换到X86模式下.
如果不想做这步切换 就要用32位的任务管理器来生成dmp文件。
32位任务管理器在C:\Windows\SysWOW64\Taskmgr.exe
The version of SOS does not match the version of CLR you are debugging
分析dump文件时，由于客户生产环境与分析dump文件的环境不一致，常常会出现下面的错误
The version of SOS does not match the version of CLR you are debugging. Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.34209
SOS Version: 4.7.2650.0
问题原因：客户生产环境的net版本是4.0.30319.34209，但分析环境的net版本是4.7.2650.0，二个环境的版本不一致。
解决方案：从客户生产环境（C:\Windows\Microsoft.NET\Framework64\v4.0.30319）拷贝这clr.dll，mscordacwks.dll，SOS.dll 这三个组件
替换到分析环境Symbol File Path路径，重新打开windbg，就正常了。
以上方法不行 就用WINDBG 32位版 试试
以上方法不行 用这里的方式试试 https://github.com/poizan42/soswow64
On a 64-bit Windows installation is it possible to make both 32-bit and 64-bit dumps of
32-bit processes.
The task manager will create a 64-bit dump, which therefore is often what you end up with
users sending you. This is not a problem for native executeables since you can still load
it in windbg and use the !wow64exts.sw extension to switch into the 32-bit view.
However if your process is a .NET process and you want to use SoS to investigate it then
you are out of luck, you'll just get the message
"SOS does not support the current target architecture."
This extension gets around this by hooking/patching functions in dbgeng.dll so that SoS
thinks it's working with a 32-bit dump.
** Usage **
Copy soswow64.dll into the "winxp" subfolder of windbg. Then after loading a 64-bit memory
dump of a 32-bit process you can simply load the extension:
0:000> .load soswow64
Successfully hooked IDebugControl::GetExecutingProcessorType.
Successfully patched DbgEng!X86MachineInfo::ConvertCanonContextToTarget.
Example:
0:000> .loadby sos clr
0:000> !wow64exts.sw
Switched to 32bit mode
0:000:x86> !threads
SOS does not support the current target architecture.
0:000:x86> .load soswow64
Successfully hooked IDebugControl::GetExecutingProcessorType.
Successfully patched DbgEng!X86MachineInfo::ConvertCanonContextToTarget.
0:000:x86> !threads
ThreadCount: 16
UnstartedThread: 0
BackgroundThread: 4
PendingThread: 0
DeadThread: 11
Hosted Runtime: no
Lock
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
0 1 318c 00fe9d58 202a020 Preemptive 029CD30C:00000000 00fdd4d0 0 MTA
2 2 5858 00ff78c8 2b220 Preemptive 00000000:00000000 00fdd4d0 0 MTA (Finalizer)
XXXX 3 0 00fd63b8 8039820 Preemptive 00000000:00000000 00fdd4d0 0 Ukn (Threadpool Completion Port)
3 5 1ddc 01045c68 8029220 Preemptive 00000000:00000000 00fdd4d0 0 MTA (Threadpool Completion Port)
XXXX 6 0 01046c18 8039820 Preemptive 00000000:00000000 00fdd4d0 0 Ukn (Threadpool Completion Port)
XXXX 7 0 010857c8 1039820 Preemptive 00000000:00000000 00fdd4d0 0 Ukn (Threadpool Worker)
XXXX 8 0 01089a20 1039820 Preemptive 00000000:00000000 00fdd4d0 0 Ukn (Threadpool Worker)
XXXX 9 0 0108b300 1039820 Preemptive 00000000:00000000 00fdd4d0 0 Ukn (Threadpool Worker)
XXXX 10 0 0108ceb8 1039820 Preemptive 00000000:00000000 00fdd4d0 0 Ukn (Threadpool Worker)
XXXX 12 0 0109d418 1039820 Preemptive 00000000:00000000 00fdd4d0 0 Ukn (Threadpool Worker)
XXXX 13 0 0109dc38 1039820 Preemptive 00000000:00000000 00fdd4d0 0 Ukn (Threadpool Worker)
XXXX 14 0 010b2b10 1039820 Preemptive 00000000:00000000 00fdd4d0 0 Ukn (Threadpool Worker)
XXXX 15 0 01084b98 1039820 Preemptive 00000000:00000000 00fdd4d0 0 Ukn (Threadpool Worker)
XXXX 16 0 010be6b0 1039820 Preemptive 00000000:00000000 00fdd4d0 0 Ukn (Threadpool Worker)
4 18 5b88 01032318 1020220 Preemptive 00000000:00000000 00fdd4d0 0 Ukn (Threadpool Worker)
5 20 192c 0102ee48 202b220 Preemptive 029CE75C:00000000 00fdd4d0 0 MTA
标签：XXXX,Windbg,DUMP,00000000,Threadpool,Ukn,Preemptive,64,00fdd4d0
From： https://www.cnblogs.com/ioriwellings/p/17061310.html