with visual threadstart threads thread new net multi method example español book c# multithreading

visual - Se detectó ContextSwitchDeadlock error en C#



threadstart c# (7)

El hilo principal de su programa ha estado ocupado ejecutando código por un minuto. No se está ocupando de sus deberes normales, bombeando el ciclo de mensajes. Eso es ilegal cuando utiliza servidores COM en un hilo de trabajo: las llamadas a sus métodos no se pueden enviar hasta que su hilo principal vuelva a estar inactivo.

Debería ser fácilmente visible, tu UI debería estar muerta como un clavo de puerta. Windows debería haber reemplazado su ventana principal con un fantasma que muestra "No responde". Cerrar la ventana no funcionará, ningún evento de clic tendrá ningún efecto.

Lo que sea que esté haciendo su hilo principal debe hacerse con un hilo de trabajo en su lugar. La clase BackgroundWorker es buena para eso, encontrará mucha ayuda de uso en el artículo de MSDN Library. Use Debug + Break All, Debug + Windows + Threads si no tiene idea de lo que está haciendo el hilo principal.

Otra causa posible: asegúrese de instalar el Service Pack 1 si está utilizando la versión RTM de VS2005.

Estoy ejecutando una aplicación C #, y durante el tiempo de ejecución obtengo el siguiente error:

El CLR no ha podido pasar del contexto COM 0x20e480 al contexto COM 0x20e5f0 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.

¿Puede alguien ayudarme con el problema aquí?

Muchas gracias.


En algunos casos :
Depurar -> Excepciones -> Administrado Debug Assistants
y desmarcar el elemento ContextSwitchDeadlock.


Este error me surgió varias veces, y lo remonté a una iteración en DataGridViewRow , en el que establecí el valor de la casilla de verificación en verdadero. Como me estaba ejecutando en modo de depuración, tenía la opción de continuar, así que pude hacer esto.

Espero que esto ayude a alguien.


Este mensaje indica que algún código suyo está intentando cambiar los hilos, y el hilo de destino está ocupado. Por ejemplo, un hilo de fondo que intenta enviar una llamada al hilo de la interfaz de usuario para actualizar la interfaz de usuario, mientras que la interfaz de usuario ejecuta un ciclo cerrado durante un tiempo.

Para averiguar realmente qué está pasando, debe acceder al depurador y observar todos los hilos y lo que están haciendo.


Me encontré con este problema cuando estaba tratando de descubrir por qué mi OracleDataReader lanzaba una excepción. Pensé que era porque se le asignaba null porque la excepción estaba relacionada con un parámetro que era `nulo. Así que lo hice:

while (dr.Read()) { while (dr != null) // <-- added this line { ...

Resultó que el dr NUNCA era nulo, por lo que el ciclo siguió y siguió hasta que llegó este mensaje, y así sucesivamente, porque puede hacer clic en "Continuar" para continuar hasta que se quede sin memoria (no haga esto). - haga clic en "Aceptar" en su lugar). Tan morales de la historia, busque fugas de memoria que transmiten datos de la base de datos a la memoria en bucles hasta el infinito. El error en realidad está tratando de advertirte de un mal escenario. Lo mejor es prestarle atención.


Para encontrar qué operación está bloqueando el cambio de contexto y haciendo que se msdn.microsoft.com/en-us/library/ms172233%28v=vs.110%29.aspx el msdn.microsoft.com/en-us/library/ms172233%28v=vs.110%29.aspx , puede usar los siguientes pasos. Tenga en cuenta que me referiré a Visual Studio 2012.

  1. Reproducir el error Esto podría implicar un poco de prueba y error.
  2. Haga clic en "Aceptar" en lugar de "Continuar" en el asistente de depuración administrada que se muestra.
  3. Asegúrese de que la barra de herramientas Ubicación de depuración esté activa haciendo clic con el botón derecho en la región de acoplamiento de la barra de herramientas y seleccionando "Ubicación de depuración". Debería ver una lista desplegable etiquetada ''Subproceso'' en la barra de herramientas si está activa.
  4. El elemento seleccionado en la lista desplegable Subproceso debe ser un subproceso que no sea el subproceso principal, ya que será un subproceso en segundo plano que se queja de que el subproceso principal está acaparando toda la atención. Seleccione el hilo principal en la lista desplegable.
  5. Ahora debería ver el código que está bloqueando el cambio de contexto en el editor de código.

Suponiendo que decida no mover la operación de uso intensivo de recursos de su hilo principal - eche un vistazo a algunas de las otras respuestas y comentarios aquí antes de hacerlo - tiene las siguientes opciones para deshabilitar los Asistentes de depuración gestionados.

Dentro del Visual Studio Debugger

  1. Puede deshabilitar una MDA directamente en el cuadro de diálogo MDA que se muestra cuando se produce el error desactivando ''Romper cuando se lanza este tipo de excepción''.
  2. Con el cuadro de diálogo Configuración de excepciones usando las instrucciones a continuación de MSDN .

... en el menú Depurar, haga clic en Excepciones. (Si el menú Depurar no contiene un comando de Excepciones, haga clic en Personalizar en el menú Herramientas para agregarlo). En el cuadro de diálogo Excepciones, expanda la lista Asistentes de depuración administrados y luego desactive la casilla de verificación Ejecutado para la MDA individual.

Fuera del depurador de Visual Studio

  1. MSDN (a escala de máquina, todos los MDA afectados)
  2. Variable de entorno (en toda la máquina, se pueden especificar MDA)
  3. Configuración de configuración de la aplicación (Ámbito de aplicación, MDA pueden ser especificados)

Nota: Una de las dos primeras opciones debe establecerse en 1 para que la tercera tenga algún efecto.

En mi caso, el problema fue una llamada a ObjectContext.SaveChanges() en Entity Framework dentro de una aplicación de consola. Con MTAThreadAttribute aplicado al método Main() , la excepción ContextSwitchDeadlock ya no se generó . Desafortunadamente no estoy seguro de los efectos de este cambio.


Simplemente seleccione Excepciones del menú Depurar en la ventana de visual studio 2005, aparecerá el cuadro de diálogo Edxception wil popup, seleccione el Nodo de excepciones de los asistentes de depuración administrados, luego seleccione ContextSwitchDeadlock y elimine la selección de la columna lanzada. esto evitará que el vs arroje la excepción ContextSwitchDeadlock.

Espero que esto ayude..