如何在64位服务器上运行的32位应用程序在Windbg中加载SOS

试图调试运行在64位Windows版本上的32位.NET应用程序的进程转储使用调试器6.3.9600.16384 x86。如何在64位服务器上运行的32位应用程序在Windbg中加载SOS

花了几个小时寻找解决方案。在stackoverflow和其他网站上发现了很多主题，但是我无法修复这个问题。我正要把我的头发拉出来。

经过的.NET版本，是由使用过程中

0:000> 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

复制clr.dll，从运行的应用程序到C服务器mscordacwks.dll和SOS.dll：\ TEMP \的DLL。将mscordacwks.dll重命名为mscordacwks_x86_x86_4.0.30319.18444.dll。

0:000> .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> .loadby sos clr 
0:000> !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_<arch>_<arch>_<version>.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.

尝试设置可执行文件的路径

0:000> .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> .reload 
................................................................ 
.......................................................... 
Loading unloaded module list 
..... 
0:000> !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_<arch>_<arch>_<version>.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.

试图.loadby SOS CLR

0:000> .loadby sos clr 
0:000> !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_<arch>_<arch>_<version>.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.

谁能帮我？不知道我还能再试一次。

来源

2014-11-17 RB84

尝试['.loadby SOS clr'（http://blogs.msdn.com/b/rihamselim/ archive/2012/03/04/error-loading-clr.aspx） –

@RemusRusanu编辑该职位。试过它，但不幸的是没有结果 – RB84

Windbg本身应该64位味道。 –

-1

你是如何创建转储文件的？如果你正在调试在64位Windows 32位过程中，你必须使用任务管理器的32位版本位于

C：\ WINDOWS \ Syswow64资料\的TaskMgr.exe

然后继续右键点击该进程并点击'创建转储文件'

一旦你采取了正确的转储，在转储的机器上的WinDbg（X64）中打开它 - 即在可能的情况下在远程PC上安装windbg因为如果你有不同的版本，这可以减少调试问题NS的.NET Framework（哪怕是细微的）

来源

2014-11-17 14:20:00 wal

转储是使用Windows错误报告创建的。 http://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx。这个问题也影响到WER吗？试着在机器上运行调试器，等待更新 – RB84

@RamonBertrand您可能会错过调试器仍然需要的一些dll - 请参阅如何在远程机器上运行windbg。关于WER我不知道，但如果在上面给出的目录中有一个32位版本，那么它的可能性也会受到影响。我使用任务管理器获取转储文件 – wal

试图立即在远程机器上运行。我应该改用Framework64 DLL还是应该切换体系结构（.load wow64exts; .effmach x86）？使用64位框架加载SOS但不允许.loadby sos clr。 32位框架似乎根本不适用。无法从中加载SOS。 – RB84

你做了正确的东西很多：

已经采取了使用WER LocalDumps 32位应用程序的32位转储
你已拷贝在SOS，并从原来的PC mscordacwks
您正确更名为
你选择了32位的WinDbg
您使用.cordll和正确mscordacwks DLL加载

有只有一个地方出了错小东西：

.loadby sos clr

这个命令会从那里clr.dll位于同一位置加载SOS。这将在您的PC上确定，因此这可能会加载与转储中的SOS不同的SOS版本。

相反，提供完整路径SOS您已经从PC收集：

.load c:\temp\dlls\sos.dll

来源

2015-07-30 17:13:49

如何在64位服务器上运行的32位应用程序在Windbg中加载SOS

回答

相关问题