.loadby sos-clr - das angegebene Modul konnte nicht gefunden werden

Ich versuche auf den Grund zu gehen, was die CLR-Ausnahme in meinem dump-Datei, aber ich habe ein Problem versuchen zu führen:

0:000> .loadby sos clr
The call to LoadLibrary(C:\ProgramData\dbg\sym\clr.dll\5348A1EF9a0000\sos) failed, Win32 error 0n126
    "The specified module could not be found."

Ich habe versucht, zu schauen, was geladen wird und ich sehe:

0:000> lm
start             end                 module name
00000000`00190000 00000000`001a4000   MyTest   (deferred)             
00000000`77a00000 00000000`77afa000   user32     (deferred)             
00000000`77b00000 00000000`77c1f000   kernel32   (pdb symbols)          C:\ProgramData\dbg\sym\kernel32.pdb\CEE1211DAF10494CAFDDBE2C4232EAE82\kernel32.pdb
00000000`77c20000 00000000`77dca000   ntdll      (pdb symbols)          C:\ProgramData\dbg\sym\ntdll.pdb\8AAAEEE259C340FCADC53FAF9FEF22E92\ntdll.pdb
000007fe`f8950000 000007fe`f9ef1000   mscorlib_ni   (deferred)             
000007fe`f9f00000 000007fe`f9fd6000   MSVCR120_CLR0400   (deferred)             
000007fe`f9fe0000 000007fe`fa980000   clr        (pdb symbols)          C:\ProgramData\dbg\sym\clr.pdb\E3E0C76A7909454FB3C56B0C2CE5FFEB2\clr.pdb
000007fe`fa980000 000007fe`faa1d000   mscoreei T (pdb symbols)          C:\ProgramData\dbg\sym\mscoreei.pdb\6D65F80ABA3D403D8F6F7214972B9BBF2\mscoreei.pdb
000007fe`faa20000 000007fe`faa8f000   mscoree    (deferred)             
000007fe`fd800000 000007fe`fd80f000   CRYPTBASE   (deferred)             
000007fe`fdbb0000 000007fe`fdc1a000   KERNELBASE   (pdb symbols)          C:\ProgramData\dbg\sym\kernelbase.pdb\D396875654E9416CBA16E51F8B0A8B1E2\kernelbase.pdb
000007fe`fdd60000 000007fe`fde69000   msctf      (deferred)             
000007fe`fde70000 000007fe`fe073000   ole32      (deferred)             
000007fe`fe0b0000 000007fe`fe121000   shlwapi    (deferred)             
000007fe`fe310000 000007fe`fe3da000   usp10      (deferred)             
000007fe`fe3e0000 000007fe`fe47f000   msvcrt     (deferred)             
000007fe`fe480000 000007fe`fe48e000   lpk        (deferred)             
000007fe`fe590000 000007fe`fe5af000   sechost    (deferred)             
000007fe`fe600000 000007fe`fe62e000   imm32      (deferred)             
000007fe`fe630000 000007fe`fe697000   gdi32      (deferred)             
000007fe`fe910000 000007fe`fe9eb000   advapi32   (deferred)             
000007fe`ff800000 000007fe`ff92d000   rpcrt4     (deferred)

Suchen Sie mehr auf der clr:

0:000> lmvm clr
Browse full module list
start             end                 module name
000007fe`f9fe0000 000007fe`fa980000   clr        (pdb symbols)          C:\ProgramData\dbg\sym\clr.pdb\E3E0C76A7909454FB3C56B0C2CE5FFEB2\clr.pdb
    Loaded symbol image file: clr.dll
    Mapped memory image file: C:\ProgramData\dbg\sym\clr.dll\5348A1EF9a0000\clr.dll
    Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
    Image name: clr.dll
    Browse all global symbols  functions  data
    Timestamp:        Fri Apr 11 22:16:15 2014 (5348A1EF)
    CheckSum:         009A762B
    ImageSize:        009A0000
    File version:     4.0.30319.34209
    Product version:  4.0.30319.34209
    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.34209
    FileVersion:      4.0.30319.34209 built by: FX452RTMGDR
    PrivateBuild:     DDBLD104
    FileDescription:  Microsoft .NET Runtime Common Language Runtime - WorkStation
    LegalCopyright:   © Microsoft Corporation.  All rights reserved.
    Comments:         Flavor=Retail

Und dann gemäß Vorschlag von @Thomas Weller:

0:000> lmf m clr
Browse full module list
start             end                 module name
000007fe`f9fe0000 000007fe`fa980000   clr      C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll

Den Pfad (C:\Windows\Microsoft.NET\Framework64\v4.0.30319) existiert auf meinem PC und es ist ein SOS.dll im inneren.

Zusätzliche Informationen:

ld clr; .reload /f hilft nicht
Habe ich nicht verwendet .cordll zum ändern der CLR laden Pfade
.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll funktioniert, aber es ist mehr zu geben

Warum ist .loadby sos clr nicht für mich arbeiten? (Ich habe gerade installiert WinDbg aus https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit), indem Sie zu installieren, die "Debugging Tools for Windows" aus dem installer)

Ich würde nicht gerne .load als Antwort, denn es ist nur ein workaround und erklärt nicht, warum es passiert und wie Sie zu verhindern.
"Mapped memory image file" erscheint das problem zu sein. Ich würde vermuten, dass die CLR-version auf der Maschine, dass die erstellten minidump ist nicht die gleiche wie auf Ihrem Computer. Du hast also die richtige version von irgendwo, ich kann mir nicht vorstellen, wie das endete in c:\programdata. Die sos.dll version müssen übereinstimmen clr.dll version also mit .laden ist nicht gerade garantiert ein workaround.

InformationsquelleAutor Denis | 2016-08-10

8

Wie erwähnt von @Thomas Weller diese Problemumgehung funktioniert für jetzt:
```
.load C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll
```
InformationsquelleAutor Denis
3

Herausgefunden, die Antwort mit, was ich gelernt von @Thomas Weller ' s Fragen. Also angeblich das "Symbol File Path" in File -> Symbol File Path ruft gelöscht, jedes mal, wenn Sie in der Nähe von WinDbg und ohne es .loadby sos clr produziert die Fehler, die ich bekam. Das "Symbol File Path" in File -> Symbol File Path muss ein Eintrag in es wie: srv*C:\windbg\websymbols (und natürlich das Verzeichnis muss existieren).

Beim öffnen einen crash-dump sollte es die folgende Ausgabe
(Beachten Sie die Zeile: Symbol search path is: srv*C:\windbg\websymbols):
```
Microsoft (R) Windows Debugger Version 10.0.14321.1024 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\XXXXXX\Desktop\AppCrash_XXXXXXXXXXXXX_d4c077fd50acba44bd2aceb966fe5424b98f3e_cab_9eb7d2f5\WERC4D4.tmp.hdmp]
User Mini Dump File: Only registers, stack and portions of memory are available


************* Symbol Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*C:\windbg\websymbols
Symbol search path is: srv*C:\windbg\websymbols
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Debug session time: Tue Aug  9 02:05:43.000 2016 (UTC - 4:00)
System Uptime: 79 days 17:08:17.121
Process Uptime: 0 days 0:00:06.000
```
Auf der anderen Seite, das ist, was ich vorher hatte, und dies bedeutet, dass Sie vergessen haben, setzen Sie die "Symbol File Path" (Beachten Sie die Zeile Symbol search path is: srv*)
```
Microsoft (R) Windows Debugger Version 10.0.14321.1024 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\XXXXXX\Desktop\AppCrash_XXXXXXXXXXXXX_d4c077fd50acba44bd2aceb966fe5424b98f3e_cab_9eb7d2f5\WERC4D4.tmp.hdmp]
User Mini Dump File: Only registers, stack and portions of memory are available

Symbol search path is: srv*
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: Server, suite: TerminalServer SingleUserTS
Machine Name:
Debug session time: Tue Aug  9 02:05:43.000 2016 (UTC - 4:00)
System Uptime: 79 days 17:08:17.121
Process Uptime: 0 days 0:00:06.000
```
- Gibt es nicht ein Weg, um zu sparen "Symbol File Path" Einstellung? Ich weiß, ich werde zu schlagen, dies wieder in ein paar Monaten, wenn ich WinDbg wieder...
- Vielleicht können Sie die _NT_SYMBOL_PATH env. Variablen, die als hier erklaert. Aber wenn ich mich Recht erinnere, WinDbg sollte bitten Sie wenn Sie möchten, um die Einstellungen zu speichern, um die Standard-workspace?
- Sind Sie sicher, dass das symbol Weg ist die Ursache? Ich Frage mich, warum .loadby würde die Arbeit mit dem symbol Weg, denn es sollte den Pfad der module (DLL), und nicht die Symbole (PDB-Datei)
- mit _NT_SYMBOL_PATH können Nebenwirkungen haben, z.B. auf den Prozess-Explorer und Visual Studio, die man vielleicht vermeiden wollen. Mit einem Arbeitsbereich ist sicherlich ein guter Ansatz oder einen link aufrufen WinDbg mit der -y option.
- Ich bin nicht sicher, warum es funktioniert, aber es ist definitiv das problem behoben. Auch scheint, dass, wenn Sie einen Arbeitsbereich erstellen in WinDbg und den Namen "Default" - es lädt automatisch, wenn Sie öffnen Sie WinDbg, so dass arbeiten werde.
InformationsquelleAutor Denis
1

WER erzeugt 2 Dateien, in meinem Fall: triagedump.dmp (2-MiB) und Speicher.hdmp (400 MB).

triagedump.dmp enthält eine Ausnahme bildet nur die info, SOS nicht mit ihm arbeiten.

Speicher.hdmp minidump ist, SOS geladen CLR erfolgreich.

InformationsquelleAutor Der_Meister

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.