我试图使用WinDbg研究在x64机器上为我们的x86进程创建一个挂起转储文件。 这是一个4.0 x86的应用程序，所以只是为了得到一个非托管堆栈，我必须做到以下几点：
.loadby sos clr
.load wow64exts
!sw
kL
然而，每次我试图让通过管理堆栈!clrstack我得到错误的称号。 我在想什么？
Answer 1:
我相信，你将不得不使用32位的任务管理器，位于C：\ WINDOWS \ Syswow64资料\的TaskMgr.exe得到一个32位转储。
更多资讯： http://blogs.msdn.com/b/tess/archive/2010/09/29/capturing-memory-dumps-for-32-bit-processes-on-an-x64-machine.aspx
Answer 2:
正如其他人已经说过，这可以通过在64位应用程序（如默认任务管理器，例如）引起产生一个32位的处理的转储文件。
我能解决使用从soswow64 WinDbg的扩展问题在GitHub上poizan42 。 我发现它通过这个博客条目 ，这也提供了有关该问题的一些更详细的信息。
Answer 3:
我一直跟着位数匹配的建议，但从来不知道究竟为什么，直到我偶然发现这篇文章就来了： http://blogs.msdn.com/b/dotnet/archive/2013/05/01/net-crash-dump -and-活过程inspection.aspx其中规定：
“DAC具有一个标准化的接口，并且用于由调试器来获得关于这些抽象的状态的信息，例如，被管理堆，它使用相匹配的CLR版本和过程或碰撞的结构的DAC是必不可少甩了你要检查。”
和
“请注意，DAC是土生土长的DLL，必须下载到使用ClrMD程序。如果转储或实时进程是32位的，则必须使用DAC，这反过来，机构的32位版本你的检查计划必须是32位的为好。这同样适用于64位进程如此。确保你的程序的平台相匹配正在调试的东西。”
Answer 4:
还有的是为我工作多了一个选项： - 我有一个64位进程的崩溃转储。 - 因此，首先，我需要SOS.dll和mscordacwks.dll从机（C：\ WINDOWS \ Microsoft.NET \ Framework64 \ v4.0.30319）拍摄该转储。 -基于两篇MSDN文章（ http://msdn.microsoft.com/en-gb/library/windows/hardware/ff562263%28v=vs.85%29.aspx ， http://msdn.microsoft.com/en -gb /库/窗/硬件/ ff540665％28V = vs.85％29.aspx ），I加载CLR这种方式：
.cordll -u -ve -I clr -lp <path to SOS.dll & mscordacwks.dll>
在此之后，！线程工作。 我认为，应该同样适用于32位崩溃转储。
文章来源: SOS does not support the current target architecture
