Was ist der "Break instruction exception" in WinDbg?
Ich bin Debuggen einige random crash-bugs, die aber eigentlich sehr schwierig, in die Tiefe zu gehen. Denn wenn ich open crash dump, der nur einen Fehler:
0:000> .exr -1
ExceptionAddress: 00000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0
Eigentlich habe ich nicht gesetzt, werden bei jedem hard-code Haltepunkt im code, damit ich die Suche zu dieser Ausnahme in google, einige Leute sagten, diese Ausnahme kann verursacht werden durch heap-Beschädigung.
Also meine Frage ist,
Gibt es einen anderen Grund, warum die Ursache dieser Ausnahme, außer harte-code Haltepunkt, manuelle Haltepunkt während des Debuggens, heap-Beschädigung?
Ist eine andere Frage, ich versuche, Application Verifier verwenden, um zu überprüfen, heap corruption verstehe ich, wie es funktioniert, app verifier ausgelöst break instruction exception während heap-Beschädigung. Aber derzeit Laufe ich ohne app-verifier, wer wird heben Sie die break Anweisung Ausnahme?
Zusätzliche info: call-stack für den aktuellen thread.
*0:000> k
ChildEBP RetAddr
0012f96c 7c827d19 ntdll!KiFastSystemCallRet
0012f970 77e6202c ntdll!NtWaitForMultipleObjects+0xc
0012fa18 7739bbd1 kernel32!WaitForMultipleObjectsEx+0x11a
0012fa74 3b288523 user32!RealMsgWaitForMultipleObjectsEx+0x141
0012fab8 3b32b9bd msenv!EnvironmentMsgLoop+0x1ea
0012fae4 3b32b94d msenv!CMsoCMHandler::FPushMessageLoop+0x86
0012fb0c 3b32b8e9 msenv!SCM::FPushMessageLoop+0xb7
0012fb28 3b32b8b8 msenv!SCM_MsoCompMgr::FPushMessageLoop+0x28
0012fb48 3b32be4e msenv!CMsoComponent::PushMsgLoop+0x28
0012fbe0 3b327561 msenv!VStudioMainLogged+0x482
0012fc0c 3000a4a6 msenv!VStudioMain+0xc1
0012fc38 30007301 devenv!util_CallVsMain+0xff
0012ff14 3000760c devenv!CDevEnvAppId::Run+0x91f
0012ff30 30007680 devenv!WinMain+0x74
0012ffc0 77e6f23b devenv!License::GetPID+0x258
0012fff0 00000000 kernel32!BaseProcessStart+0x23*
Unsere Anwendung ist ein Visual Studio-Paket.
Unten ist das Ergebnis aus !analysieren -v
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
*** WARNING: Unable to verify checksum for mscorlib.ni.dll
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: kernel32!pNlsUserInfo ***
*** ***
*************************************************************************
FAULTING_IP:
+0
00000000 ?? ???
EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0
FAULTING_THREAD: 00001f1c
DEFAULT_BUCKET_ID: STATUS_BREAKPOINT
PROCESS_NAME: devenv.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
MANAGED_STACK:
SP IP Function
0012E584 09C8A903 Microsoft_VisualStudio_Design!Microsoft.VisualStudio.NativeMethods.ThrowOnFailure(Int32, Int32[])+0x3b
0012E590 09C8C604 Microsoft_VisualStudio_Design!Microsoft.VisualStudio.Design.VSDesignSurfaceManager.Microsoft.VisualStudio.Shell.Interop.IVsSelectionEvents.OnElementValueChanged(UInt32, System.Object, System.Object)+0x144
StackTraceString: <none>
HResult: 80004005
EXCEPTION_OBJECT: !pe 3115d464
Exception object: 3115d464
Exception type: System.Runtime.InteropServices.COMException
Message: Error HRESULT E_FAIL has been returned from a call to a COM component.
InnerException: <none>
StackTrace (generated):
SP IP Function
0012E584 09C8A903 Microsoft_VisualStudio_Design!Microsoft.VisualStudio.NativeMethods.ThrowOnFailure(Int32, Int32[])+0x3b
0012E590 09C8C604 Microsoft_VisualStudio_Design!Microsoft.VisualStudio.Design.VSDesignSurfaceManager.Microsoft.VisualStudio.Shell.Interop.IVsSelectionEvents.OnElementValueChanged(UInt32, System.Object, System.Object)+0x144
StackTraceString: <none>
HResult: 80004005
MANAGED_OBJECT: !dumpobj 3201988
Name: System.String
MethodTable: 79330a00
EEClass: 790ed64c
Size: 158(0x9e) bytes
(C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)
String: Error HRESULT E_FAIL has been returned from a call to a COM component.
Fields:
MT Field Offset Type VT Attr Value Name
79332c4c 4000096 4 System.Int32 1 instance 71 m_arrayLength
79332c4c 4000097 8 System.Int32 1 instance 70 m_stringLength
793316e0 4000098 c System.Char 1 instance 45 m_firstChar
79330a00 4000099 10 System.String 0 shared static Empty
>> Domain:Value 00219c28:03031198 <<
79331630 400009a 14 System.Char[] 0 shared static WhitespaceChars
>> Domain:Value 00219c28:03031798 <<
EXCEPTION_MESSAGE: Error HRESULT E_FAIL has been returned from a call to a COM component.
MANAGED_OBJECT_NAME: System.Runtime.InteropServices.COMException
LAST_CONTROL_TRANSFER: from 7c827d19 to 7c82860c
PRIMARY_PROBLEM_CLASS: STATUS_BREAKPOINT
BUGCHECK_STR: APPLICATION_FAULT_STATUS_BREAKPOINT
STACK_TEXT:
09c8a903 Microsoft_VisualStudio_Design!Microsoft.VisualStudio.NativeMethods.ThrowOnFailure
09c8c604 Microsoft_VisualStudio_Design!Microsoft.VisualStudio.Design.VSDesignSurfaceManager.Microsoft.VisualStudio.Shell.Interop.IVsSelectionEvents.OnElementValueChanged
STACK_COMMAND: dds 12e584 ; kb
FOLLOWUP_IP:
+9c8a903
09c8a903 8bc6 mov eax,esi
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: Microsoft_VisualStudio_Design!Microsoft.VisualStudio.NativeMethods.ThrowOnFailure+9c8a903
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Microsoft_VisualStudio_Design
IMAGE_NAME: Microsoft.VisualStudio.Design.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 0
FAILURE_BUCKET_ID: STATUS_BREAKPOINT_80000003_Microsoft.VisualStudio.Design.dll!Microsoft.VisualStudio.NativeMethods.ThrowOnFailure
BUCKET_ID: APPLICATION_FAULT_STATUS_BREAKPOINT_Microsoft_VisualStudio_Design!Microsoft.VisualStudio.NativeMethods.ThrowOnFailure+9c8a903
Followup: MachineOwner
...
In der verwalteten stack, es ist ein expliziter Fehler,Microsoft.VisualStudio.NativeMethods.ThrowOnFailure..
Aber das bedeutet, dass die com-Ausnahme verursachen die break Anweisung Ausnahme?
!analysieren scheint nur dump die managed-Ebene, die com-Ausnahme vielleicht der Letzte Fehler in der verwalteten Ebene.
Ich auch auf die Suche nach etwas, das über interrupt-und exception von google in der Regel die break Anweisung Ausnahme kann ausgelöst werden bei folgenden Bedingungen:
1. Fest interrupt-Anforderung, wie: __asm int 3 (ASM), System.Diagnostik.Debugger.Pause (C#), DebugBreak() (WinAPI).
2. OS aktivieren Speicher-Laufzeit überprüfen, wie Sie Application Verifier ausgelöst werden kann, nach heap-Beschädigung, Speicherüberlauf.
3. Compiler können einige Konfiguration, um enble, was ausgefüllt werden sollte, für den nicht initialisierten Speicher-block und am Ende der Funktion(leere Fläche, nach der Rückfahrt..). Zum Beispiel, Microsoft VC complier füllen kann, 0xCC, wenn " enable /GZ. 0xCC ist eigentlich ein opcode der __asm int 3. Also, wenn einige Fehler Auftritt, wird die Anwendung ausgeführt, in einen solchen block, löst einen break-Punkt.
Richtig?
Dass, wenn, ich denke, Application Verifier sollte die beste Wahl, um die Grundursache finden.
InformationsquelleAutor Winston | 2010-07-22
Du musst angemeldet sein, um einen Kommentar abzugeben.
Für die Zukunft, die Ihr debugger ist nicht mit den richtigen Symbolen Warnung verursacht wird, weil Sie brauchen, um Windows-Symbole, um den Windbg-Symbole Weg. Hier ist, wie zu tun:
Microsoft symbol server-Pfad automatisch:
Optional können Sie einen zusätzlichen Speicherort angeben, wo Sie download-symbol aus, z.B.:
Informieren Sie sich über aktuelle symbol suchen Pfad:
Sollten Sie etwas wie dieses:
Reload Symbole:
Dann werden Sie in der Lage, um zu sehen, Informationen über die aktuelle exception mit diesem Befehl:
Sollten Sie eine Zeile ähnlich der folgenden:
Glück Fehler zu beheben!
Wie kann die Festsetzung der Symbole umwandeln, INT3 Haltepunkt in eine access-violation?
InformationsquelleAutor kiewic
Den Befehl zu verwenden, um zu finden, die Ausnahme, die die crash-dump ist
.ecxr. Die outpt, die Sie von.exr -1ist falsch, da die ExceptionAddress null ist.InformationsquelleAutor John