web-dev-qa-db-ja.com

WinDbg x64：クラッシュダンプをデバッグできません-データアクセスのロードに失敗しましたDLL

実行中のプロセスにWinDbgをアタッチし、プロセスをクラッシュさせました（その場合、別の質問があります）。プログラムがクラッシュすると、WinDbgが停止し、プログラムをデバッグできるようになりました。 「.dump/ma」コマンドを使用して、さらに調査するためにクラッシュダンプを取得しました。

プログラムは「任意のCPU」としてコンパイルされ、WinDbg x64を使用してダンプを取得しました。次に、同じコンピューターでWinDbg x64を再度開き、クラッシュダンプを開きます。これが言うことです：

Loading Dump File [C:\crashdump.dmp]
User Mini Dump File with Full Memory: Only application data is available

Symbol search path is: SRV*c:\symbols*http://msdl.Microsoft.com/download/symbols
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Mon Aug 15 10:24:57.000 2011 (UTC + 1:00)
System Uptime: 17 days 0:54:39.021
Process Uptime: 12 days 14:01:31.000
................................................................
...............................................................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1be0.b78): Access violation - code c0000005 (first/second chance not available)
*** WARNING: symbols timestamp is wrong 0x4dd2333e 0x4da4281c for clr.dll
clr!WKS::gc_heap::find_first_object+0x92:
000007fe`ea129a1d f70100000080    test    dword ptr [rcx],80000000h ds:00000000`00003d80=????????

次に、SOS by ".load sos clr"をロードしようとすると、次のエラーが発生します。

The call to LoadLibrary(sos clr) failed, Win32 error 0n2
    "The system cannot find the file specified."
Please check your debugger configuration and/or network access.

「.loadby sos clr」で試してみると、うまくいきます。ここで、「！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
            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 the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                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.

「.symfix」と「.reload」を試しました：

0:027> .symfix
0:027> .reload
..................*** WARNING: symbols timestamp is wrong 0x4dd2333e 0x4da4281c for clr.dll
..............................................
...............................................................

立ち往生。 WinDgbでプロセスが実行されているときに、実行を一時停止し、SOSをロードして、「！clrstack」コマンドを正常に実行できます。

何か案は？ありがとうございました。

更新-2番目の回答で提供されている手順に従いましたが、まだ機能しません。

1）私のシンボルパス：SRV * c：\ symbols * http：//msdl.Microsoft.com/download/symbols; srv *

2）ロードされたCLR：4.0.30319 .237：

0:027> lm v clr
Unknown option 'r'
start             end                 module name
00000000`77b60000 00000000`77d09000   ntdll      (pdb symbols)          c:\symbols\ntdll.pdb\6192BFDB9F04442995FFCB0BE95172E12\ntdll.pdb
    Loaded symbol image file: ntdll.dll
    Image path: C:\Windows\System32\ntdll.dll
    Image name: ntdll.dll
    Timestamp:        Sat Nov 20 13:11:21 2010 (4CE7C8F9)
    CheckSum:         001B55EA
    ImageSize:        001A9000
    File version:     6.1.7601.17514
    Product version:  6.1.7601.17514
    File flags:       0 (Mask 3F)
    File OS:          40004 NT Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft® Windows® Operating System
    InternalName:     ntdll.dll
    OriginalFilename: ntdll.dll
    ProductVersion:   6.1.7601.17514
    FileVersion:      6.1.7601.17514 (win7sp1_rtm.101119-1850)
    FileDescription:  NT Layer DLL
    LegalCopyright:   © Microsoft Corporation. All rights reserved.
000007fe`e9fb0000 000007fe`ea915000   clr      # (pdb symbols)          c:\symbols\clr.pdb\1A7EA01DA29549DAB2B0BD012A6C5BA12\clr.pdb
    Loaded symbol image file: clr.dll
    Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
    Image name: clr.dll
    Timestamp:        Tue May 17 09:35:10 2011 (4DD2333E)
    CheckSum:         00967144
    ImageSize:        00965000
    File version:     4.0.30319.237
    Product version:  4.0.30319.237
    File flags:       8 (Mask 3F) Private
    File OS:          4 Unknown Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0409.04b0
    CompanyName:      Microsoft Corporation
    ProductName:      Microsoft® .NET Framework
    InternalName:     clr.dll
    OriginalFilename: clr.dll
    ProductVersion:   4.0.30319.235
    FileVersion:      4.0.30319.235 (RTMGDR.030319-2300)
    PrivateBuild:     DDBLD240
    FileDescription:  Microsoft .NET Runtime Common Language Runtime - WorkStation
    LegalCopyright:   © Microsoft Corporation.  All rights reserved.
    Comments:         Flavor=Retail

3） "C：\ Windows\Microsoft.NET\Framework64\v4.0.30319\mscordacwks.dll"のバージョンは4.0.30319です。239

4）WinDbgにダンプをロードすると、Webから正しい「mscordacwks.dll」がロードされることがわかりました。つまり、フォルダー「C：\ symbols\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD2333E965000」にファイル「 mscordacwks_AMD64_AMD64_4.0.30319.237.dll ".

5）

0:027> .cordll -ve -u -l
CLR DLL status: No load attempts

6）

0:027> !sym noisy
noisy mode - symbol prompts on
0:027> .restart

Loading Dump File [C:\crashdump.dmp]
User Mini Dump File with Full Memory: Only application data is available

DBGHELP: Symbol Search Path: srv*;srv*c:\symbols*http://msdl.Microsoft.com/download/symbols
DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.Microsoft.com/download/symbols;srv*c:\symbols*http://msdl.Microsoft.com/download/symbols
DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.Microsoft.com/download/symbols;srv*c:\symbols*http://msdl.Microsoft.com/download/symbols
Symbol search path is: srv*;SRV*c:\symbols*http://msdl.Microsoft.com/download/symbols
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: SingleUserTS
Machine Name:
Debug session time: Mon Aug 15 10:24:57.000 2011 (UTC + 1:00)
System Uptime: 17 days 0:54:39.021
Process Uptime: 12 days 14:01:31.000
................................................................
...............................................................
DBGHELP: ntdll - public symbols  
         C:\Program Files\Debugging Tools for Windows (x64)\sym\ntdll.pdb\6192BFDB9F04442995FFCB0BE95172E12\ntdll.pdb
DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.Microsoft.com/download/symbols;srv*c:\symbols*http://msdl.Microsoft.com/download/symbols
DBGHELP: Symbol Search Path: cache*;SRV*http://msdl.Microsoft.com/download/symbols;srv*c:\symbols*http://msdl.Microsoft.com/download/symbols
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1be0.b78): Access violation - code c0000005 (first/second chance not available)
*** WARNING: symbols timestamp is wrong 0x4dd2333e 0x4da4281c for clr.dll
DBGHELP: clr - public symbols  
         C:\Program Files\Debugging Tools for Windows (x64)\sym\clr.pdb\1A7EA01DA29549DAB2B0BD012A6C5BA12\clr.pdb
clr!WKS::gc_heap::find_first_object+0x92:
000007fe`ea129a1d f70100000080    test    dword ptr [rcx],80000000h ds:00000000`00003d80=????????

7）

0:027> !clrstack
SYMSRV:  C:\Program Files\Debugging Tools for Windows (x64)\sym\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD2333E965000\mscordacwks_AMD64_AMD64_4.0.30319.237.dll not found
SYMSRV:  mscordacwks_AMD64_AMD64_4.0.30319.237.dll from http://msdl.Microsoft.com/download/symbols: 502892 bytes - copied         
DBGHELP: C:\Program Files\Debugging Tools for Windows (x64)\sym\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD2333E965000\mscordacwks_AMD64_AMD64_4.0.30319.237.dll cached to C:\Program Files\Debugging Tools for Windows (x64)\sym\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD233F317b000\mscordacwks_AMD64_AMD64_4.0.30319.237.dll
DBGHELP: C:\Program Files\Debugging Tools for Windows (x64)\sym\mscordacwks_AMD64_AMD64_4.0.30319.237.dll\4DD233F317b000\mscordacwks_AMD64_AMD64_4.0.30319.237.dll - OK
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
            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 the same architecture as the dump file.
                For example, an IA64 dump file must be debugged on an IA64
                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.
debuggingwindbgdump
20
net_prog

サイトからのミニダンプでデバッグするとき、私はこれを定期的にヒットしました。あなたのケースでそれがどのように起こったかは私にはわかりません。通常、これは、ダンプの取得時に読み込まれたCLRのバージョンがデバッグマシンで利用できない場合に発生します。あなたの場合、それらは同じマシンなので、おそらくすべてうまくいくはずです。なぜそうでないのかを正確に説明できる人はきっといるでしょう。

それまでの間、これが私のサイトダンプの処理方法です。 Windbgは、mscordacwks.dllの "正しいバージョン"を探しています。そのため、そのバージョンを指定し、どこを探すかを伝えます。

最初に、mscordacwks.dllを削除してすべてを偽装すると、windbgがオフになり、Microsoftシンボルサーバーからロードされます。そのため、Microsoftシンボルサーバーからシンボルをダウンロードし、もう一度実行するようにシンボルが正しく設定されていることを確認してください。 。

今、それがうまくいかなかったと仮定して、どのバージョンが「正しいバージョン」であるかを正確に確認してください。 「lm v clr」を使用してモジュール情報をリストし、実際にロードされているCLRバージョンを確認します。鉱山は4.0.30319.239です。 Ok-ここで、mscordacwks.dllのそのバージョンを見つけます。マシン上の通常の.NET Frameworkインストール（C：\ Windows\Microsoft.NET\Framework64\v4。 0.30319）。バージョンが完全に一致することを確認してください（右クリック、プロパティなど）！それを取り出して安全な場所に置きます（私はD：\ Symbols\_Imagesを使用します）。windbgがファイルの名前を変更するときに指示した指示に従ってください。mscordacwks_ .dllはmscordacwks_AMD64_AMD64_4.0.30319.239.dllになります。

次に、実行可能イメージのパス（ ".exepath D：\ Symbols\_Images"）を設定して、windbgがどこに配置したかを認識できるようにします。

これで「mscordacwksの正しいバージョン」が得られ、Windbgが探しているものを認識できるように名前が変更され、どこに配置したかがわかります。

そのSTILLが機能しない場合は、「。cordll -ve -u -l」と「！sym noisy」を試して、cordllロードとシンボルサーバーの両方の詳細ログをオンにしてから、もう一度！CLRStackを試してください。おそらく、これらの2つのコマンドの出力から、ロードしようとしているものが正確にわかり、なぜそれが実行されないのかを理解できます...

17
Pete

このシナリオに遭遇した多くのケースのデバッグに1日を費やしました。クラッシュと同じボックスのSOS + CLRがWinDbg内でロードできず、「lm v」は同じモジュールに対して2つの異なるバージョンを報告しました。

0：011> lm vM * clr.dll 
 start end module name 
 000007fe`f2f50000 000007fe`f38b0000 clr＃（pdb symbols）c：\ symbols\clr.pdb\EDFF900AC9B94C1D9B32696A7759891A2\clr.pdb 
ロードされたシンボルイメージファイル：clr.dll 
イメージパス：C：\ Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll 
イメージ名：clr.dll 
タイムスタンプ：2013年4月21日03:36:04（5173C114）
チェックサム：0095F379 
画像サイズ：00960000 
ファイルバージョン： 4.0.30319.18052
製品バージョン： 4.0.30319.18052
ファイルフラグ：8（マスク3F）プライベート
ファイルOS：4不明Win32 
ファイルタイプ：2.0 Dll 
ファイル日付：00000000.00000000 
翻訳：0409.04b0 
 CompanyName：Microsoft Corporation 
 ProductName：Microsoft®.NET Framework 
 InternalName：clr.dll 
 OriginalFilename：clr.dll 
 ProductVersion ： 4.0.30319.18047
ファイルバージョン： 4.0.30319.18047 ビルド：FX45RTMGDR 
 PrivateBuild：DDBLD320 
 FileDescription：Microsoft .NET Runtime Common Language Runtime-WorkStation 
 LegalCopyright：©Microsoft Corporation。 All rights reserved。
コメント：フレーバー=小売

バッキング詳細

ミニダンプのmodule-list-streamの MINIDUMP_MODULE 構造体に格納されているファイルタイムスタンプ（0x5173C114）、チェックサム（0x0095F379）、およびバージョン（4.0.30319.18052）は、新しいCLR用でした。自分でミニダンプファイルをクラックしてストリームデータを直接調べます。

MINIDUMP_MODULE：（pack：8 size：112）
 + 0x000 .BaseOfImage UInt64：8791579230208（0x7FEF2F50000）
 + 0x008 .SizeOfImage UInt32：9830400（0x960000）
 + 0x00C .CheckSum UInt32：9827193（0x95F379）
 + 0x010 .TimeDateStamp UInt32：1366540564（0x5173C114）
 + 0x014 .ModuleNameRva UInt32：107828（0x1A534）
 + 0x018 .VersionInfo tagVS_FIXEDFILEINFO：（pack：8 size：52）
 + 0x000 .dwSignature UInt32：4277077181（0xFEEF04BD）
 + 0x004 .dwStrucVersion UInt32：65536（0x10000）
 + 0x008 .dwFileVersionMS UInt32：262144（0x40000）
 + 0x00C .dwFileVersionLS UInt32：1987004036（0x766F4684）

上位と下位の単語をdwFileVersionMSから分割すると、4と0になります。
dwFileVersionLSから上位と下位の単語を分割すると、30319と18052が取得されます。


dumpchk.exe を使用して、PEBでモジュールの詳細を見ると、古い（18047）バージョンに実際に対応する別のタイムスタンプ（0x515530CE）が表示されます。

7fef2f50000 515530ce 3月28日23:12:30 2013 C：\ Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll


clr.dllがロードされているクラッシュダンプのrawメモリを見ると、バージョン4.0.30319.18047のチェックサム（0x00965F80）とタイムスタンプ（0x515530CE）が表示されます。

0：011> db 000007fe`f2f50000 
 000007fe`f2f50000 4d 5a 90 00 03 00 00 00-04 00 00 00 ff ff 00 00 MZ .............. 
 000007fe`f2f50010 b8 00 00 00 00 00 00 00-40 00 00 00 00 00 00 00 ........ @ ....... 
 000007fe`f2f50020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 
 000007fe`f2f50030 00 00 00 00 00 00 00 00-00 00 00 00 18 01 00 00 ................ 
 000007fe`f2f50040 0e 1f ba 0e 00 b4 09 cd-21 b8 01 4c cd 21 54 68 .... ....！.. L.！Th 
 000007fe`f2f50050 69 73 20 70 72 6f 67 72-61 6d 20 63 61 6e 6e 6fはプログラムcanno 
 000007fe`f2f50060 74 20 62 65 20 72 75 6e-20 69 6e 20 44 4f 53 20 t DOSで実行
 000007fe`f2f50070 6d 6f 64 65 2e 0d 0d 0a-24 00 00 00 00 00 00 00モード.... $ ....... 
 0：011> db 
 000007fe`f2f50080 39 e4 28 ed 7d 85 46 be-7d 85 46 be 7d 85 46 be 9。（。}。F。 } .F。}。F。
 000007fe`f2f50090 81 f2 f8 be 79 85 46 be-81 f2 fa be 74 85 46 be .... yF .... tF 
 000007fe` f2f500a0 74 fd c5 be 73 85 46 be-74 fd c2 be c9 85 46 be t ... sFt .... F。
 000007fe`f2f500b0 ee 41 8d be 7f 85 46 be-e3 25 81 be 7c 85 46 be .A .... F ..％.. | .F。
 000007fe`f2f500c0 ee 41 88 be 6b 85 46 be-ee 41 89 be 78 85 46 be .A..kF.A .. xF 
 000007fe`f2f500d0 ee 41 8b be 64 85 46 be-7d 85 47 be ca 87 46 be .A..dF} .G ... F。
 000007fe`f2f500e0 81 f2 ff be 76 85 46 be-ee 41 9e be 70 87 46 be .... vF.A..pF 
 000007fe`f2f500f0 ee 41 8c be 7c 85 46 be-ee 41 8f be 7c 85 46 be。 A .. | ..F..A .. | .F。
 0：011> 
 000007fe`f2f50100 ee 41 8a be 7c 85 46 be-52 69 63 68 7d 85 46 be。 A .. | ..F。リッチ} .F。
 000007fe`f2f50110 00 00 00 00 00 00 00 00-50 45 00 00 64 86 06 00 ........ PE..d。 .. 
 000007fe`f2f50120 ce 30 55 51 00 00 00 00-00 00 00 00 f0 00 22 20 .0UQ .......... "
 000007fe`f2f50130 0b 02 0b 00 00 90 69 00-00 c2 2b 00 00 00 00 00 ...... i ... + ..... 
 000007fe`f2f50140 40 51 13 00 00 10 00 00-00 00 f5 f2 fe 07 00 00 @Q ...... ........ 
 000007fe`f2f50150 00 10 00 00 00 02 00 00-06 00 00 00 0a 00 00 00 ................ 
 000007fe`f2f50160 06 00 00 00 00 00 00 00-00 e0 95 00 00 04 00 00 ................ 
 000007fe`f2f50170 80 5f 96 00 02 00 60 01-00 00 10 00 00 00 00 00 ._.... `.........

また、メモリ内でジャンプして、メモリ内のバージョンリソースを調べ、18047バージョン文字列を確認しました。


これで、実際に使用されているclr.dllのバージョンに関する情報が競合するミニダンプが作成されました。

何が原因ですか

最近、IT部門が少数のWindows Updateを公開したこともわかりました。

  • アプリケーションの実行中に、CLRの更新がインストールされました。
  • C：\ Windows\Microsoft.NET\Framework64\v4.0.30319 \にあるファイルが新しいバージョン（4.0.30319.18052）に更新されました
  • アプリケーションがクラッシュしました
  • MiniDumpWriteDumpは、モジュールリストをクラッシュダンプファイルに保存するときに、ディスク上のファイル情報を使用したようです（4.0.30319.18052）。
  • WinDbgは、クラッシュダンプにスタンプされたバージョンを、情報が競合しているため、プロセスのメモリにあるものと関連付けることができませんでした。

これを確認するために、clr.dllのMINIDUMP_MODULEエントリを手動で変更して、チェックサム、タイムスタンプ、およびバージョンを18052から18047に変更しました。 sosコマンドを正常に実行し、有効なスタックトレースを取得できました。

ボトムライン

基本的に、プロセスに読み込まれるclr.dllのバージョンに関する情報が矛盾しているミニダンプファイルができ、SOSが正しいclrエンジンを識別できないようになっています。これはMiniDumpWriteDumpのバグである可能性があります。クラッシュダンプファイルが保存されるためですが、アプリケーションの実行中にCLRのバッキングバージョンが更新された場合にのみ発生します。

12
josh poley

あなたが32ビットをデバッグしようとしているプロセスはありますか？タスクマネージャーのプロセスリストには何が表示されますか？ 32ビットプロセスの場合は、32ビットwindbgを使用する必要があります。それ以外の場合、理由はわかりません.load sos clrは失敗するはずです。

ps：（windbg noob alert）、これが不自然に聞こえたら謝罪します。ただ助けようとしています。

0
Nikhil S

Windbgのカスタムインストールを実行し、必要なすべての拡張機能を選択しなかったようです。 Win32エラーn2は通常、この問題の兆候です。

0
steve