Analyse der CLR .dmp-Datei in WinDbg

Ich habe ein C# .NET 3.5-Anwendung erstellt in Visual Studio 2008 Absturz auf einem Windows XP SP3 (x86) PC, keine Entwicklungsumgebung.

War ich in der Lage zu bekommen .dmp-Datei vom PC aus und nehmen Sie es zurück zu meinem Windows 7 in der 64-bit-Entwicklungs-PC und laden Sie Sie in WinDbg 6.12.

Aber ich sehe keinen code in der Aufrufliste aus meiner C# - Anwendung. Wie es aussieht ist es völlig einen systemeigenen Aufruf-stack.

Ergebnis aus !analyze -v ist unten.

Habe ich die relevanten EXE -, DLL-und PDB-Dateien in das gleiche Verzeichnis wie die .DMP. Die ausführbare Datei, die abgestürzt war kompiliert in den debug-Modus.

Ich habe auch Visual Studio 2008, wenn das einfacher zu verwenden ist. Aber das öffnen der dump-Datei, in der es auch nur zeigt einen systemeigenen Aufruf-stack, der nichts von meinem code.

Wie kann ich die CLR call-stack?

0:004> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************


FAULTING_IP:
kernel32!RaiseException+53
7c812afb 5e              pop     esi

EXCEPTION_RECORD:  0392f018 -- (.exr 0x392f018)
ExceptionAddress: 7c812afb (kernel32!RaiseException+0x00000053)
   ExceptionCode: e0434f4d (CLR exception)
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: 80070057

PROCESS_NAME:  foo.exe

ERROR_CODE: (NTSTATUS) 0xe0434f4d - <Unable to get error code text>

EXCEPTION_CODE: (NTSTATUS) 0xe0434f4d - <Unable to get error code text>

EXCEPTION_PARAMETER1:  80070057

MOD_LIST: <ANALYSIS/>

MANAGED_STACK: !dumpstack -EE
No export dumpstack found

MANAGED_BITNESS_MISMATCH:
Managed code needs matching platform of sos.dll for proper analysis. Use 'x86' debugger.

ADDITIONAL_DEBUG_TEXT:  Followup set based on attribute [Is_ChosenCrashFollowupThread] from Frame:[0] on thread:[PSEUDO_THREAD]

LAST_CONTROL_TRANSFER:  from 79ef2bfc to 7c812afb

FAULTING_THREAD:  ffffffff

DEFAULT_BUCKET_ID:  STACKIMMUNE

PRIMARY_PROBLEM_CLASS:  STACKIMMUNE

BUGCHECK_STR:  APPLICATION_FAULT_STACKIMMUNE_NOSOS_CLR_EXCEPTION

STACK_TEXT:
00000000 00000000 foo.exe+0x0


SYMBOL_NAME:  foo.exe

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: foo

IMAGE_NAME:  foo.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4d5da0cd

STACK_COMMAND:  ** Pseudo Context ** ; kb

FAILURE_BUCKET_ID:  STACKIMMUNE_e0434f4d_foo.exe!Unknown

BUCKET_ID:  APPLICATION_FAULT_STACKIMMUNE_NOSOS_CLR_EXCEPTION_foo.exe

Followup: MachineOwner
---------
Minidump Debuggen für ein verwaltetes Programm, das nicht .NET 4.0 ist sehr wenig Freude. Er bombardiert auf eine unbehandelte verwaltete Ausnahme. Verbessern Sie Ihre Chancen, um dies zu diagnostizieren, indem Sie einen Ereignis-handler für die Anwendungsdomäne.CurrentDomain.UnhandedException und Protokollierung oder Anzeige der Wert von e ist.ExceptionObject.ToString(). Gut genug, um zu diagnostizieren die Ursache der Probleme in der überwiegenden Mehrzahl der Fälle.
Ich war die Verpackung der code im Programm.cs in einen try/catch-block, aber dieses Ereignis ist viel ordentlicher. Danke.

InformationsquelleAutor PaulH | 2011-02-25

  1. 6

    Managed code benötigt, eine passende Plattform
    der sos.dll für eine angemessene Analyse. Verwenden
    die 'x86' - debugger.

    Mussten Sie die x86 debugger WinDbg zum Debuggen einer x86-Speicher-dump. Verwenden .loadby sos mscorwks zum laden des entsprechenden sos. Sie könnte auch überprüfen, ob die Erweiterung geladen wird ordnungsgemäß über die .chain Befehl.

    Tess hat einige gute debugging-tutorials.

    Mein Entwicklungs-PC ist Win 7 64-bit. Kann ich die x86 debugger oder brauche ich zum erstellen eines 32-bit-VM ausführen?
    Debugging tools für Windows x86 verwendet werden muss (matching-dump Bitanzahl). Ein 32-bit-VM funktioniert auch, ist aber nicht notwendig.
    Sobald der dump ist offen und SOS ist geladen !CLRStack oder !pe zeigen, können Sie den call-stack oder der Ausnahme.
    Ich ging zu der microsoft-Website zum herunterladen der Debugging Tools For Windows 32-bit Version die es mir erlaubt, laden Sie das Windows SDK für Windows 7 und .NET framework 4. In diesem installer, ich kann nur wählen, zu installieren Debugging Tools for Windows. Ich don ' T haben die Wahl zwischen einer 64 und 32 bit version. Nach der Installation, alles, was ich finden kann, ist WinDbg:6.12.0002.633 AMD64
    Hier ist ein link für die Vorherige version von windbg für x86 msdn.microsoft.com/en-us/windows/hardware/gg463016#ERD

    InformationsquelleAutor Naveen

  2. 3

    Dieses tutorial ist ein guter start, um zu sehen, einige WinDbg Kommandos. Ich denke, die folgenden Befehle sollen Ihnen zeigen den aktuellen stack-trace:

    .sympath SRV*d:\localsymbols*http://msdl.microsoft.com/download/symbols
!reload
.loadby sos mscorwks
K

    InformationsquelleAutor BrandonAGr

  3. 1

    Debuggen von verwaltetem crash-dumps in WinDbg erfordert zusätzliche Module (vor allem SOS.dll) und Befehle.

    Einige gute Ausgangsposition links sind hier.

    .load sos Erträge The call to LoadLibrary(sos) failed, Win32 error 0n193

    InformationsquelleAutor John Arlen

Schreibe einen Kommentar