Ich habe einen Code, der NullReferenceException :
Er wirft, weil dataSource ist null . GetView gibt DataTable zurück.
Wenn das Programm jedoch auf dem einen Computer (64 Bit) ausgeführt wird, wird das Programm ohne Probleme fortgesetzt. Die Ausnahme passiert, denn wenn ich gehe, lande ich komplett woanders. Der Debugger hört jedoch nicht auf.
Wenn es auf einem anderen (32 Bits) ausgeführt wird, löst es die Ausnahme aus und mein Debugger stoppt.
Mein Programm ist für 32 Bit kompiliert. Wenn ich auf "Any CPU" umschalte, stürzt der 64-Bit-Computer bei der Ausnahme ab.
Update Ich weiß, wie ich mein Problem beheben kann (ich habe es tatsächlich schon getan). Alles, was ich wissen möchte, ist, dass dies ein irgendwie bekanntes Verhalten ist oder etwas, das durch eine Reihe von Gründen verursacht werden kann.
Der Fix war 1) Wählen Sie "Any CPU" (was den 64-Bit-Rechner zum Absturz brachte) und 2) überprüfen Sie, ob dataSource vor dem Ausführen dieses Stücks null ist.
Zu viele Kommentare, um den doppelten Link sichtbar zu machen, also mache ich eine Antwort. Dies ist ein bekanntes Problem bei den 64-Bit-Versionen von Vista und Win7 beim Debuggen eines 32-Bit-Programms. Normalerweise gibt es einen Backstop im Nachrichtenverteiler, der unbehandelte Ausnahmen abfängt, wenn der Dispatcher eine Windows-Nachricht verarbeitet, und der Ereignishandler für die Nachricht eine Ausnahme auslöst, die nicht abgefangen wird. Das normalerweise löst das Application.ThreadException-Ereignis in Winforms, das Dispatcher.UnhandledException-Ereignis in WPF, aus.
Diese Ereignisse sind jedoch sehr peinlich, wenn Sie ein Programm debuggen, es macht es schwierig, nicht behandelte Ausnahmen zu diagnostizieren. Wenn Sie also Ihr Programm mit einem angehängten Debugger starten, wird dieser Backstop deaktiviert, damit der Debugger die Ausnahme sehen und den Ausnahmeassistenten anzeigen kann. Ihnen einen Tipp geben, wie Sie das Problem beheben können.
Microsoft hatte ein Problem mit bestimmten Nachrichten, die vom 64-Bit-Fenstermanager stammen und die Wow64-Emulationsschichtgrenze mehrmals durchlaufen. Sie konnten nicht herausfinden, wie eine unbehandelte Exception diese Layer durchläuft, die Exception-Info ist stark an das Code-Modell gebunden. Also haben sie das einzige andere getan, was sie tun konnten, sie fangen die Ausnahme ein. Dies aktiviert normalerweise den Anwendungskompatibilitätsdialog, der es dem Benutzer erlaubt, die Ausnahme als gutartig zu behandeln. Jeder klickt in diesem Dialog auf Ja, da sie keine Ahnung haben, was der Dialog verlangt und wie sein Programm kompatibel ist.
>Dies ist ziemlich fatal für Ihren Debugging-Versuch, der Debugger kann die unbehandelte Ausnahme nicht mehr sehen, da Windows sie fängt und schluckt. So bekommst du genau das, was du beschrieben hast, der Code hört einfach auf zu laufen ohne irgendeinen Hinweis warum. Alles, was Sie sehen können, ist eine Benachrichtigung über die erste Exception im Ausgabefenster, die sehr leicht zu übersehen ist.
Ich habe bereits eine Antwort zu diesem Problem gepostet und Workarounds für das Problem dokumentiert. Sie finden es hier .