2010-11-22 1 views
5

Ich habe eine Visual C++ 9 Win32-Anwendung, die eine Bibliothek von Drittanbietern verwendet. Wenn eine Funktion aus dieser Bibliothek mit einem bestimmten Parametersatz aufgerufen wird, stürzt das Programm mit dem "Ausnahmecode 0xC000000D" ab.Programm stürzt mit 0xC000000D ab und keine Ausnahmen - wie debugge ich es?

Ich habe versucht, Visual Studio Debugger anhängen - keine Ausnahmen werden ausgelöst (weder C++ noch strukturiert wie Zugriffsverletzungen) und terminate() wird auch nicht aufgerufen. Trotzdem endet das Programm einfach still.

Wie kommt es, dass das Programm nur abnormal endet, aber nicht im Debugger gestoppt wird? Wie kann ich das Problem lokalisieren?

+0

ist es Multithreading oder single-threaded? – Simone

+0

@Simone: Ein Worker-Thread, mehrere Dienst-Threads, die von RPC erstellt wurden. Wir haben die Synchronisation gründlich getestet, Multithreading ist unwahrscheinlich. – sharptooth

+0

Führen Sie eine Release-Version oder eine Debug-Version aus? Ich habe seltsame Fälle von Release-Versionen gesehen, die nicht im Debugger gestoppt wurden. –

Antwort

5

mit __try zu beenden Das STATUS_INVALID_PARAMETER ist, verwenden Sie WinDbg auf die Spur, die er warf (d anhängen WinDbg, sxe eh dann g.

+1

Das OP sagte bereits, dass "VS Debugger anhängen - keine Ausnahmen werden geworfen" ... Wie würde WinDbg das Bild ändern? –

+0

Suchen herum scheint anzuzeigen, dass es Funktionen gibt, die dies auslösen - aber auch, dass es Funktionen gibt, die STATUS_INVALID_PARAMETER als Rückgabewert verwenden. Also wird vielleicht doch nichts geworfen ... –

+0

@Martin VS wird bestimmte Arten von Ausnahmen verstecken, mit denen es nicht umgehen kann (selten). Mit WinDbg 100% wird jede Art von Ausnahme ausgeschlossen. –

1

Wenn Sie keine Quell- und Debuginformationen für Ihre Drittanbieterbibliothek haben, können Sie nicht mit dem Debugger darauf zugreifen. Wie ich es sehe, sind Ihre Entscheidungen;

  • Stellen Sie sich einen einfachen Fall Test den Absturz darstellt und auf die Bibliothek Entwickler
  • Wrap, dass Bibliotheksfunktion in Ihrem eigenen Code zu senden, die für illegale Parameter überprüft und eine Ausnahme auslösen/Return einen Fehlercode, wenn sie indem Sie Ihre eigene Anwendung übergeben
  • die Teile der Bibliothek Rewrite, die arbeiten oder verwenden Sie keine Alternative

Sehr schwer Code zu beheben, die als Objekt nur

zur Verfügung gestellt

bearbeiten Sie könnten auch in der Lage sein, mehr anmutig __finally um Ihre Hauptnachrichtenschleife, so etwas wie

int CMyApp::Run() 
{ 
    __try 
    { 
     int i = CWinApp::Run(); 
     m_Exitok = MAGIC_EXIT_NO; 
     return i; 
    } 
    __finally 
    { 
     if (m_Exitok != MAGIC_EXIT_NO) 
      FaultHandler(); 
    } 
} 
+1

Natürlich können Sie mit dem Debugger hineingehen. –

+0

@Paul, sicher, aber nur in Assembler ohne PDB. Mit der PDB, aber keine Quelle, erhalten Sie schön Assembler mit Etiketten aus der Quelle. IMO, diese sind selten Hand-Debuggen wert, da eine Reparatur in Assembler durchgeführt werden muss, was zeitaufwendig sein wird und einen zukünftigen Wartungs-Albtraum verursachen wird. –

+0

Ich glaube nicht, dass das Problem von OP darin bestand, in den Code zu gehen, sondern eher die Ausnahme zu erfassen, von der er sagt, dass sie nicht passiert. –

2

Andere Antworten und Kommentare zu der Frage haben sehr geholfen. Hier ist was ich getan habe.

Ich merke, dass, wenn ich das Programm unter Visual Studio Debugger läuft es einfach still, aber wenn ich es ohne Debugger stürzt es mit einem Meldungsfeld (üblichen Windows-Message-Box, dass ich verloren meine ungesicherten Daten und jeder ist sooo Es tut uns leid).

Also habe ich das Programm ohne Debugger gestartet, es abstürzen lassen und dann - während das Meldungsfeld noch da war - den Debugger angeschlossen und "Break" gedrückt. Hier ist die Aufrufliste:

[email protected]() 
[email protected]() + 0xc bytes 
[email protected]() - 0x48 bytes 
[email protected]() + 0x18 bytes 
faultrep.dll!StartDWException() + 0x5df bytes 
faultrep.dll!ReportFault() + 0x533 bytes 
[email protected]() + 0x55c bytes 
//SomeThirdPartyLibraryFunctionAddress 
//SomeThirdPartyLibraryFunctionAddress 
//SomeThirdPartyLibraryFunctionAddress 
//SomeThirdPartyLibraryFunctionAddress 
//OurCodeInvokingThirdPartyLibraryCode 

so offensichtlich ist das ein Problem innerhalb der Trid-Party-Bibliothek. Laut MSDN wird UnhandledExceptionFilter() in fatalen Situationen aufgerufen und der Aufruf wird aufgrund eines Problems in dem Bibliothekscode eindeutig ausgeführt. Wir werden versuchen, das Problem zuerst mit dem Bibliotheksanbieter zu lösen.

Verwandte Themen