2009-02-23 18 views
108

Aparece un mensaje de error que no puedo resolver. Se origina en Visual Studio o en el depurador. No estoy seguro de si la condición de error final está en VS, el depurador, mi programa o la base de datos.Visual Studio: ContextSwitchDeadlock

Esta es una aplicación de Windows. No es una aplicación web.

El primer mensaje de VS es un cuadro emergente que dice: "No se cargan símbolos para ningún marco de pila de llamadas. No se puede mostrar el código fuente". Cuando se hace clic, obtengo: "ContextSwitchDeadlock se detectó", junto con un mensaje largo que se reproduce a continuación.

El error se produce en un bucle que explora una DataTable. Para cada línea, utiliza un valor de clave (HIC#) de la tabla como parámetro para un SqlCommand. El comando se usa para crear un SqlDataReader que devuelve una línea. Los datos son comparados. Si se detecta un error, se agrega una fila a un segundo DataTable.

Parece que el error está relacionado con la duración del procedimiento (es decir, después de 60 segundos), no cuántos errores se encuentran. No creo que sea un problema de memoria. No se declaran variables dentro del ciclo. Los únicos objetos que se crean son los SqlDataReaders, y están en Uso de estructuras. Agregar System.GC.Collect() no tuvo ningún efecto.

El db es un sitio SqlServer en la misma computadora portátil.

No hay artilugios o artilugios de lujo en el formulario.

No conozco nada en este proceso que sea muy diferente de lo que he hecho docenas de veces antes. He visto el error antes, pero nunca de manera constante.

¿Alguna idea, alguien?

texto de error completo: El CLR no ha sido capaz de hacer la transición a partir del contexto COM 0x1a0b88 al contexto COM 0x1a0cf8 durante 60 segundos. El hilo que posee el contexto/apartamento de destino probablemente esté haciendo una espera de no bombeo o procesando una operación de muy larga ejecución sin bombear mensajes de Windows. Esta situación generalmente tiene un impacto negativo en el rendimiento e incluso puede llevar a que la aplicación no responda o el uso de la memoria se acumule continuamente a lo largo del tiempo. Para evitar este problema, todos los subprocesos de apartamento de rosca única (STA) deben usar primitivas de espera de bombeo (como CoWaitForMultipleHandles) y rutinariamente bombear mensajes durante operaciones de larga ejecución.

Respuesta

184

El ContextSwitchDeadlock no significa necesariamente que su código tenga un problema, solo que existe un potencial. Si va al Debug > Exceptions en el menú y expande el Managed Debugging Assistants, encontrará ContextSwitchDeadlock habilitado. Si deshabilita esto, VS ya no lo avisará cuando los elementos tarden en procesarse. En algunos casos, puede válidamente tener una operación de larga duración. También es útil si está depurando y se ha detenido en una línea mientras se está procesando; no quiere que se queje antes de que haya tenido la oportunidad de investigar un problema.

+4

justo en! Gracias. Tuve que ir a Personalizar y agregar excepciones al menú Depurar. No es el aspecto más intuitivo de la interfaz de usuario. Herramientas \ Personalizar, luego reorganizar comandos (botón), luego Seleccionar depuración del menú desplegable en la esquina superior derecha, luego Agregar (botón). ¡Uf! – SeaDrive

+0

Sí, parece que algunas instalaciones tienen eso en el menú y otras no. Lo he visto también con otros elementos útiles del menú, y aún tengo que descubrir qué los enciende o los apaga por defecto. – Pedro

+46

'ctrl-alt-e' trae el diálogo de excepción. –

8

Parece que está haciendo esto en el hilo de la IU principal en la aplicación. El subproceso de interfaz de usuario es responsable de bombear mensajes de Windows a medida que llegan, y sin embargo, debido a que el suyo está bloqueado en las llamadas a la base de datos, no puede hacerlo. Esto puede causar problemas con los mensajes de todo el sistema.

Debería buscar engendrar un hilo de fondo para la operación de larga ejecución y colocar algún tipo de diálogo "estoy ocupado" para el usuario mientras sucede.

5

Si no desea deshabilitar esta excepción, todo lo que necesita hacer es dejar que su aplicación muestre algunos mensajes al menos una vez cada 60 segundos. Evitará que esta excepción suceda. Intenta llamar a System.Threading.Thread.CurrentThread.Join (10) de vez en cuando. Hay otras llamadas que puede hacer para que los mensajes se activen.

+0

¿Podría explicar por qué esto ayuda? – rolls

+0

Esto no funcionará, tengo una interfaz de usuario de actualización de bucle y sigo recibiendo el mensaje de error. – htm11h

13

Como dijo Pedro, tiene un problema con el depurador que impide la bomba de mensajes si está pasando por el código.

Pero si está realizando una operación de larga ejecución en el hilo de la interfaz de usuario, llame a Application.DoEvents() que expulsa explícitamente la cola de mensajes y luego devuelve el control a su método actual.

Sin embargo, si lo hace, le recomendaría que mire su diseño para que pueda realizar el procesamiento fuera del hilo de la interfaz de usuario para que su interfaz de usuario permanezca agradable y ágil.

0

La solución anterior es buena en algunos escenarios, pero hay otro escenario en el que esto sucede cuando se prueban unidades e intenta "Depurar pruebas seleccionadas" desde el Explorador de pruebas cuando su solución no está configurada como Depurar.

En este caso, necesita cambiar su solución de versión o lo que sea que esté configurado para depurar en este caso. Si este es el problema, cambiar "ContextSwitchDeadlock" no te ayudará.

Me lo perdí porque el mensaje de error fue tan desagradable que no verifiqué lo que era la configuración de depuración.

0

En Visual Studio 2017 versión española.

"Depurar" -> "Ventanas" -> "Configuracion de Excepciones"

y buscar "ContextSwitchDeadlock". Luego, desmárcala. o el acceso directo

Ctrl + D, E

mejor.

0

Puede resolver este desmarcando contextswitchdeadlock de

de Depuración> Excepciones ... -> Expandir nodo MDA -> desmarcar -> contextswitchdeadlock