VB.NET-Anwendung gibt Speicherfehler 0xc0000005 in ntdll.dll

Question

Ich habe Probleme mit einer Speicherzugriffsausnahme in einer VB.NET-Anwendung, an der ich arbeite. Ich hoffte hier einige Einblicke zu bekommen, da keine meiner Recherchen mir geholfen haben, das Problem zu identifizieren.

Hintergrund:

Ich konvertiere eine Reihe von Anwendungen von VB6 auf .NET 4.0. Auf Wunsch des Kunden führe ich eine reine Konvertierung durch und refakturiere nur, wenn es notwendig ist, um andere Probleme im Code zu vermeiden, während ich konvertiere. Die meisten Apps werden im Modus Any CPU kompiliert, obwohl einige als x86 kompiliert werden müssen aufgrund der Abhängigkeit von 32-Bit-PLC-Software oder älteren Hardware-Treibern. Mein Entwicklungsrechner läuft unter Windows 7 64-Bit.

Problem:

Nach erfolgreicher Konvertierung von zwei Apps stürzt die dritte Anwendung an zufälligen Stellen im Code ab. Die Ausnahme wird nicht abgefangen und ich muss mir das genauer ansehen. Im Ereignisprotokoll sehe ich die Ausnahme-Code: 0xc0000005 auf ntdll.dll, was ich glaube, dass eine Speicherzugriffsausnahme ist. Da die Anwendung nicht immer am selben Ort abstürzt, ist es schwierig zu verfolgen. Ich habe bemerkt, dass viele Fehler bei Aufrufen von ADODB auftreten (nicht immer am selben Ort oder beim selben Aufruf), aber es ist auch bei Aufrufen von form.ShowDialog() abgestürzt.

Das Formular, in dem ShowDialog aufgerufen wird, schreibt einige Protokollinformationen in die DB mit ADODB. Obwohl ich es nicht bestätigen konnte, vermute ich, dass die Ausnahme innerhalb des form.ShowDialog() während eines dieser ADODB-Aufrufe auftritt. Die Abstürze bei den ADODB-Anrufen treten in Assemblys auf, die in den anderen beiden konvertierten Apps erfolgreich verwendet werden, und sie stürzen nicht konsistent am selben Ort ab.

In meinen Recherchen zu diesem Thema habe ich gesehen, dass eine schlechte Interoperation dieses Problem verursachen kann. Ich frage mich, ob die ADODB-COM-Aufrufe auf irgendeine Weise das Problem in dieser App verursachen, obwohl diese Aufrufe in den anderen Apps in Ordnung sind.

Einige der Stellen, an denen ich festgestellt habe, dass offensichtlich eine Ausnahme im Ereignisprotokoll ausgelöst wird:

• Erstellung eines ADODB.Recordset
• Erstellen eines neuen Parameters innerhalb eines Command.Append
• Verbindungsoffen-Aufrufe

Hätte jemand Ideen, wie ich dies eingrenzen kann, um möglicherweise das Problem auf die Wurzel zurückzuführen? Ich freue mich über jede Hilfe oder jeden Einblick, den Sie bereitstellen können.

Answer 1

Ah... PLC's, die erinnern mich zurück. Wenn der Hersteller keine aktualisierte Treiber-Sammlung hat, könnten Sie einen harten Kampf führen. Was wahrscheinlich passiert, ist, dass das neuere Betriebssystem viel schneller ist oder mehr Kerne hat oder eine Kombination aus beidem, was "Renn"-Bedingungen im Treibercode verursacht. Dies gilt besonders für die Kommunikation, wo oft Threading verwendet wird. Da der Treibercode wahrscheinlich in C oder C++ (nicht verwaltet) geschrieben ist, haben Sie wahrscheinlich nicht viel Kontrolle über diese Bedingungen. Sie könnten versuchen, mit dem Threading-Modell herumzuspielen, unter dem die Anwendung läuft. Wenn das die Stabilität verbessert, verwenden Sie es.

Apartment-Model Threading in Visual Basic 6

DotNet MTA Thread Attribute

DotNet STA Thread Attribute

Im schlimmsten Fall können Sie einen separaten Prozess starten, der den Treiber verwendet und mit ihm von Ihrer Hauptanwendung aus über verschiedene "Inter-Process Communication"-Techniken kommuniziert. Wenn dieser abstürzt, starten Sie einen anderen, aber Ihre Hauptanwendung läuft weiter. Sie könnten sogar den externen Prozess als VB6-Anwendung schreiben, im absolut schlimmsten Fall.

Viel Glück.