Ich habe eine Fehlermeldung erhalten, die ich nicht beheben kann. Sie stammt von Visual Studio oder dem Debugger. Ich bin mir nicht sicher, ob die eigentliche Fehlerbedingung in VS, im Debugger, in meinem Programm oder in der Datenbank liegt.
Dies ist eine Windows-Anwendung. Keine Web-App.
Die erste Meldung von VS ist ein Popup-Fenster mit der Meldung: "Es sind keine Symbole für einen Aufrufstapelrahmen geladen. Der Quellcode kann nicht angezeigt werden." Wenn das weggeklickt wird, erhalte ich: " ContextSwitchDeadlock wurde entdeckt ", zusammen mit einer langen Nachricht, die im Folgenden wiedergegeben wird.
Der Fehler tritt in einer Schleife auf, in der eine DataTable durchsucht wird. Für jede Zeile wird ein Schlüsselwert (HIC #) aus der Tabelle als Parameter für einen SqlCommand verwendet. Der Befehl wird verwendet, um einen SqlDataReader zu erstellen, der eine Zeile zurückgibt. Die Daten werden verglichen. Wird ein Fehler festgestellt, wird eine Zeile zu einer zweiten DataTable hinzugefügt.
Der Fehler scheint damit zusammenzuhängen, wie lange die Prozedur dauert (d. h. nach 60 Sekunden), und nicht damit, wie viele Fehler gefunden werden. Ich glaube nicht, dass es ein Speicherproblem ist. Innerhalb der Schleife werden keine Variablen deklariert. Die einzigen Objekte, die erstellt werden, sind die SqlDataReader, und sie befinden sich in Using-Strukturen. Das Hinzufügen von System.GC.Collect() hatte keine Wirkung.
Die Datenbank ist eine SqlServer-Site auf demselben Laptop.
Das Formular enthält keine ausgefallenen Spielereien oder Gadgets.
Mir ist nichts bekannt, was sich wesentlich von dem unterscheidet, was ich schon dutzende Male gemacht habe. Ich habe den Fehler schon einmal gesehen, aber nie auf einer konsistenten Basis.
Hat jemand eine Idee?
Vollständiger Fehlertext: Die CLR war 60 Sekunden lang nicht in der Lage, vom COM-Kontext 0x1a0b88 zum COM-Kontext 0x1a0cf8 zu wechseln. Der Thread, der den Zielkontext/das Ziel-Apartment besitzt, führt höchstwahrscheinlich entweder ein nicht pumpendes Warten durch oder verarbeitet eine sehr lange laufende Operation ohne das Pumpen von Windows-Nachrichten. Diese Situation wirkt sich im Allgemeinen negativ auf die Leistung aus und kann sogar dazu führen, dass die Anwendung nicht mehr reagiert oder die Speichernutzung im Laufe der Zeit kontinuierlich ansteigt. Um dieses Problem zu vermeiden, sollten alle Single Threaded Apartment (STA) Threads pumping wait primitives (wie CoWaitForMultipleHandles) verwenden und routinemäßig Nachrichten während lang laufender Operationen pumpen.
