none
Aus der MSDN-Hotline: Speicherverletzungen und Debuggen von Erste-Chance-Ausnahmen RRS feed

  • Allgemeine Diskussion

  • Hallo zusammen,
    heute wurde uns bei der MSDN Hotline unter anderem folgende Frage gestellt:

    Ich erhalte im Debugger folgende Ausgabe:

    Eine Ausnahme (erste Chance) des Typs "System.IO.IOException" ist in Microsoft.VisualBasic.dll aufgetreten.
    Eine Ausnahme (erste Chance) des Typs "System.IO.IOException" ist in Microsoft.VisualBasic.dll aufgetreten.
    Eine Ausnahme (erste Chance) des Typs "System.ArgumentNullException" ist in System.Windows.Forms.dll aufgetreten.
    Eine Ausnahme (erste Chance) des TEine Ausnahme (erste Chance) des Typs "System.AccessViolationException" ist in System.Windows.Forms.dll aufgetreten.

    Wie entstehen solche Meldungen und wie geht man mit ihnen um?

    Unsere Antwort bzw. unser Lösungsvorschlag darauf war:

    Wir unterscheiden zwischen Ausnahmen („exception“) und Fehlern („error“). Beides sind Zustände eines Programms oder eines Moduls. Ausnahmen sind diejenigen Zustände, in welchen sich Fehler andeuten, aber noch nicht aufgetreten sind. Man hat in diesen Zuständen die Chance, diese Fehler zu vermeiden. Fehler sind Zustände, die nur durch das Betriebssystem behebbar sind. Die offensichtliche Lösung für die meisten Fehler ist, das fehlerhafte Programm zu beenden und aus dem Speicher zu löschen. In .NET wird ein fehlerhaftes Programm nicht sofort gelöscht, sondern hat jederzeit die Gelegenheit, den aufgetretenen Fehler selbst zu beheben. Wenn es das nicht tut, wird es vom Betriebssystem aus dem Speicher entfernt und der Benutzer erhält die Nachricht „<Programm> funktioniert nicht mehr.

    Die Ausnahme „AccessViolationException“ gibt einen Speicherzugriffs-Fehler an. Jedes Programm bekommt für seine Arbeit vom Betriebssystem einen Speicherbereich zugewiesen. Dieser Speicherbereich ist definiert durch eine untere und eine obere Speicheradresse. Wenn das Programm diese Adressen über- oder unterschreitet, dann bricht das Programm mit dieser Fehlermeldung ab. Üblicherweise entsteht ein solcher Fehler, wenn man eine Zahl oder ein Objekt als Speicheradresse verarbeitet, welches noch nie eine gültige Adresse war.

    Ein Beispiel: Ich definiere zwei Zahlen, „a“ und „b“ mit zwei verschiedenen Werten. Dann addiere ich beide und speichere sie in der Variable „c“. Dann weise ich das Betriebssystem an, den Speicher an der Adresse des Wertes in „c“ zu lesen. In „c“ kann natürlich alles Mögliche stehen, aber höchstwahrscheinlich keine gültige Speicheradresse. Das Ergebnis ist dann ein Speicherzugriff-Fehler

    Speicherzugriff-Fehler treten selten isoliert auf. Sie sind meist die letzten in einer Reihe von verschiedenen Fehlern oder Ausnahmen. Wenn Ausnahmen nicht korrekt behandelt werden, dann versucht das Programm mit ungültigen oder falschen Daten weiter zu arbeiten. In dem vorliegenden Fall sehen wir vier Ausnahme-Meldungen, die scheinbar alle behandelt werden. Behandelte Ausnahmen nennt man „First chance exception“ oder eben „Ausnahme (erste Chance)“. Wenn Sie diesen Eintrag lesen, dann bedeutet das, dass ein Modul die Chance wahrgenommen hat, die Ausnahme zu behandeln. Die Erste-Chance-Ausnahmen hier sind typisch für eine Verkettung von nicht korrekt behandelten Fehlern:

    1. Irgendwo im Visual Basic Sprachmodul tritt eine Input-Output-Ausnahme (IOException) auf. Das ist üblicherweise ein fehlerhafter Zugriff auf das Dateisystem.
    2. Die IOException wird behandelt. Vermutlich setzt die Behandlung irgendwelche Standardwerte, z.B. „0“ für erwartete Zahlenwerte oder NULL für Objekte. Diese Werte werden weitergegeben und verursachen den Fehler für unerwartete Standardwerte: ArgumentNullException
    3. Auch die unerwarteten Standardwerte werden erkannt und behandelt. Unermüdlich versucht das Programm, diesen ungültigen oder falschen Daten doch noch etwas Sinnvolles abzugewinnen. Oder es tut einfach so, als wäre nichts gewesen. Typischerweise erkennt man solche Stellen an den Anweisungen: „On Error Resume Next“. In unserem Fall versucht es, den Speicher an einer Adresse zu lesen. Ich tippe darauf, dass die Speicher-„Adresse“ die null von der Ausnahme davor ist. Die Null-Adresse oder „0x0000 0000“ wird von modernen Programmen niemals verwendet. Wenn man versucht, mit ihr zu arbeiten, erhält man immer eine AccessViolationException.

    Wo genau Ihre Ausnahme herkommt, können wir nicht feststellen. Wir schlagen vor, die Debugger-Ausnahmebehandlung zu aktivieren. Gehen Sie dazu vor wie unter [1] beschrieben und suchen Sie im Dialogfehlt „Ausnahmen“ nach der „IOException“. Aktivieren Sie dort das Häkchen für „Ausgelöst“. Jetzt können Sie die Ausnahmen mit dem Debugger betrachten, sobald sie auftreten. Achten Sie besonders auf die Parameterwerte, die von Ihrem Programmcode oder vom Betriebssystem gesetzt werden.

    Die Fehler liegen leider in den .NET-Bibliotheken. Sie können dort zwar ohne Einschränkungen Werte und Objekte untersuchen, allerdings können Sie keinen Quellcode betrachten. Wenn Sie auf die Ansicht von Quellcode nicht verzichten möchten, dann richten Sie den Zugriff auf Referenzcode wie unter [2] beschrieben ein.

    Bitte versuchen Sie, mit diesen Hinweisen mehr über den Fehler herauszufinden. Besonders wichtig sind diese Fragen:

    • Was war die Anweisung, welche die System.IO.IOException ausgelöst hat?
    • Welchen Wert hatten die Parameter, die zur System.IO.IOException geführt haben?
    • Hat die System.IO.IOException eine „innere Ausnahme“ und wenn ja, welche?

    Quellen
    [1] Wie man Ausnahmen nach Typ abfängt http://msdn.microsoft.com/de-de/library/d14azbfh
    [2] Wie man den .NET-Quellcode anzeigen kann http://blogs.msdn.com/b/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx

    Wir hoffen, vielen Besuchern derWir hoffen, vielen Besuchern der MSDN Foren durch das Posten dieses Problems und einer möglichen Lösung weiterhelfen zu können.

    Viele Grüße
    Jonathan Best
    MSDN Hotline für MSDN Online Deutschland

    Disclaimer:
    Bitte haben Sie Verständnis dafür, dass wir hier auf Rückfragen gar nicht oder nur sehr zeitverzögert antworten können.
    Bitte nutzen Sie für Rückfragen oder neue Fragen den telefonischen Weg über die MSDN Hotline: http://www.msdn-online.de/Hotline
    MSDN Hotline: Schnelle & kompetente Hilfe für Entwickler: kostenfrei!

    Es gelten für die MSDN Hotline und dieses Posting diese Nutzungsbedingungen, Hinweise zu MarkenzeichenInformationen zur Datensicherheit sowie die gesonderten Nutzungsbedingungen für die MSDN Hotline.



    • Bearbeitet Jonny Best Dienstag, 22. Mai 2012 14:11
    Dienstag, 22. Mai 2012 14:08