it-swarm.com.de

Visual Studio: ContextSwitchDeadlock

Ich habe eine Fehlermeldung erhalten, die ich nicht beheben kann. Es stammt aus Visual Studio oder dem Debugger. Ich bin nicht sicher, ob die endgültige Fehlerbedingung in VS, dem Debugger, meinem Programm oder der Datenbank liegt. 

Dies ist eine Windows-App. Keine Web-App.

Die erste Nachricht von VS ist ein Popup-Fenster, in dem Folgendes angezeigt wird: "Für keinen Aufruf-Stack-Frame werden keine Symbole geladen. Der Quellcode kann nicht angezeigt werden." Wenn Sie auf dieses Symbol klicken, wird Folgendes angezeigt: "ContextSwitchDeadlock wurde erkannt ", zusammen mit einer langen Nachricht, die unten wiedergegeben ist.

Der Fehler tritt in einer Schleife auf, in der eine DataTable gescannt wird. Für jede Zeile wird ein Schlüsselwert (HIC #) aus der Tabelle als Parameter für einen SqlCommand verwendet. Mit dem Befehl wird ein SqlDataReader erstellt, der eine Zeile zurückgibt. Daten werden verglichen. Wenn ein Fehler erkannt wird, wird eine Zeile zu einer zweiten DataTable hinzugefügt.

Der Fehler scheint sich darauf zu beziehen, wie lange die Prozedur dauert (d. H. Nach 60 Sekunden), und nicht wie viele Fehler gefunden werden. Ich denke nicht, dass es ein Gedächtnisproblem ist. Innerhalb der Schleife werden keine Variablen deklariert. Die einzigen Objekte, die erstellt werden, sind die SqlDataReaders, und sie befinden sich in Using-Strukturen. Das Hinzufügen von System.GC.Collect () hatte keine Auswirkung.

Die Datenbank ist eine SqlServer-Site auf demselben Laptop.

Das Formular enthält keine ausgefallenen Spielereien oder Gadgets.

Mir ist nichts in dieser Proc bekannt, das sich stark von dem unterscheidet, was ich schon dutzende Male gemacht habe. Ich habe den Fehler schon früher gesehen, aber nie auf einer konsistenten Basis.

Irgendwelche Ideen?

Full error Text: Die CLR konnte 60 Sekunden lang nicht vom COM-Kontext 0x1a0b88 in den COM-Kontext 0x1a0cf8 übergehen. Der Thread, dem der Zielkontext/das Zielobjekt gehört, führt höchstwahrscheinlich entweder eine Wartezeit ohne Pumpen durch oder verarbeitet einen sehr langen Vorgang, ohne Windows-Meldungen zu pumpen. Diese Situation hat im Allgemeinen einen negativen Einfluss auf die Leistung und kann sogar dazu führen, dass die Anwendung nicht mehr reagiert oder sich der Speicherbedarf im Laufe der Zeit kontinuierlich ansammelt. Um dieses Problem zu vermeiden, sollten alle Singlethread-Apartment-Threads (STA-Threads) Pump-Wait-Primitive (wie CoWaitForMultipleHandles) verwenden und Meldungen während eines langen Betriebs routinemäßig pumpen.

134
SeaDrive

Die Variable ContextSwitchDeadlock bedeutet nicht notwendigerweise, dass Ihr Code ein Problem hat, es gibt nur ein Potenzial. Wenn Sie im Menü Debug > Exceptions gehen und den Managed Debugging Assistants erweitern, werden Sie feststellen, dass ContextSwitchDeadlock aktiviert ist. Wenn Sie dies deaktivieren, werden Sie von VS nicht mehr gewarnt, wenn die Verarbeitung von Elementen lange dauert. In einigen Fällen haben Sie möglicherweise eine lange Laufzeit. Es ist auch hilfreich, wenn Sie debuggen und während einer Verarbeitung in einer Zeile stehen geblieben sind. Sie möchten nicht, dass sich dies beschwert, bevor Sie die Möglichkeit hatten, in ein Problem zu gelangen.

233
Pedro

Wie Pedro sagte, haben Sie ein Problem mit dem Debugger, der die Message-Pumpe verhindert, wenn Sie den Code durchgehen.

Wenn Sie jedoch einen lang andauernden Vorgang im UI-Thread ausführen, rufen Sie Application.DoEvents () auf, das die Nachrichtenwarteschlange explizit pumpt und dann die Steuerung an Ihre aktuelle Methode zurückgibt. 

Wenn Sie dies tun, würde ich jedoch empfehlen, Ihr Design so zu betrachten, dass Sie die Verarbeitung über den UI-Thread durchführen können, sodass Ihre UI schön bleibt.

13
Spence

Es klingt, als würden Sie dies im Haupt-UI-Thread der App tun. Der UI-Thread ist für das Pumpt von Windows-Meldungen beim Eintreffen verantwortlich. Da Ihr Datenbank-Datenbankaufruf jedoch blockiert ist, kann er dies nicht tun. Dies kann zu Problemen mit systemweiten Meldungen führen.

Sie sollten einen Hintergrund-Thread für den langwierigen Betrieb erzeugen und ein "Ich bin beschäftigt" -Dialogfeld für den Benutzer erstellen, während dies geschieht.

10
Rob Walker

Wenn Sie diese Ausnahme nicht deaktivieren möchten, müssen Sie Ihre Anwendung mindestens einmal alle 60 Sekunden einige Meldungen pumpt lassen. Dadurch wird verhindert, dass diese Ausnahme auftritt .. __ Versuchen Sie, ab und zu System.Threading.Thread.CurrentThread.Join (10) aufzurufen. Es gibt andere Anrufe, die Sie tun können, um die Nachrichten zu pumpen.

6
rold2007

Die obige Lösung ist in einigen Szenarien gut, aber es gibt ein anderes Szenario, in dem dies der Fall ist, wenn Sie Unit-Tests durchführen und versuchen, ausgewählte Tests vom Test Explorer zu "debuggen", wenn die Lösung nicht auf Debug eingestellt ist. 

In diesem Fall müssen Sie Ihre Lösung von Release ändern oder in diesem Fall auf Debugging setzen. Wenn dies das Problem ist, wird das Ändern von "ContextSwitchDeadlock" Ihnen nicht wirklich helfen.

Ich habe das selbst vermisst, weil die Fehlermeldung so unangenehm war, dass ich nicht das Offensichtliche geprüft habe, was die Debug-Einstellung war!

1
Ewan

Deaktivieren Sie in Visual Studio 2017 die Option ContextSwitchDeadlock folgendermaßen:

Debug> Windows> Ausnahmeeinstellungen

 enter image description here 

In Windows mit Ausnahmeeinstellungen: Deaktivieren Sie die Option ContextSwitchDeadlock

 enter image description here 

0
Hassan Rahman

Sie können dieses Problem lösen, indem Sie Contextswitchdeadlock von deaktivieren

Debug-> Ausnahmen ... -> MDA-Knoten erweitern -> Häkchen entfernen -> Contextswitchdeadlock

0
KR Akhil

In der spanischen Version von Visual Studio 2017. 

"Depurar" -> "Ventanas" -> "Configuración de Excepciones"

und suchen Sie nach "ContextSwitchDeadlock". ... Deaktivieren Sie es dann. .__ Oder eine Verknüpfung 

Strg + D, E

Beste.

0
kahonmlg