Visual Studio: ContextSwitchDeadlock

Ho ricevuto un messaggio di errore che non riesco a risolvere. Proviene da Visual Studio o dal debugger. Non sono sicuro se la condizione di errore finale sia in VS, nel debugger, nel mio programma o nel database.

Questa è un’app di Windows. Non è un’app web.

Il primo messaggio di VS è una finestra popup che dice: “Nessun simbolo viene caricato per nessun frame di stack di chiamate.Il codice sorgente non può essere visualizzato.” Quando si fa clic su di esso, viene visualizzato: ” Rilevato ContextSwitchDeadlock “, insieme a un messaggio lungo riprodotto di seguito.

L’errore si presenta in un ciclo che analizza un DataTable. Per ogni riga, utilizza un valore chiave (HIC #) dalla tabella come parametro per un SqlCommand. Il comando viene utilizzato per creare un SqlDataReader che restituisce una riga. I dati sono confrontati. Se viene rilevato un errore, una riga viene aggiunta a un secondo DataTable.

L’errore sembra essere relativo al tempo di esecuzione della procedura (ovvero dopo 60 secondi), non al numero di errori rilevati. Non penso che sia un problema di memoria. Nessuna variabile è dichiarata all’interno del ciclo. Gli unici oggetti che vengono creati sono SqlDataReaders e sono in Uso delle strutture. Aggiungi System.GC.Collect () non ha avuto alcun effetto.

Il db è un sito SqlServer sullo stesso laptop.

Non ci sono aggeggi fantasia o gadget sul modulo.

Non sono a conoscenza di nulla in questo proc, che è molto diverso da quello che ho fatto decine di volte prima. Ho visto l’errore prima, ma mai su una base coerente.

Qualche idea, qualcuno?

Testo di errore completo: CLR non è stato in grado di passare dal contesto COM 0x1a0b88 al contesto COM 0x1a0cf8 per 60 secondi. Il thread che possiede il contesto / l’appartamento di destinazione è più probabile che effettui un’attesa senza pompaggio o che elabori un’operazione molto lunga senza pompare messaggi di Windows. Generalmente, questa situazione ha un impatto negativo sulle prestazioni e può persino portare a un’applicazione non retriggers o all’utilizzo della memoria che si accumula continuamente nel tempo. Per evitare questo problema, tutti i thread a thread singolo apartment (STA) devono utilizzare i primitivi di attesa di pompaggio (come CoWaitForMultipleHandles) e pompare regolarmente i messaggi durante le operazioni a esecuzione prolungata.