Qué es realmente «No responde» — Cómo decide Windows que una aplicación se ha colgado, y cómo diseñar aplicaciones que no lo hagan

«Durante el procesamiento, la pantalla se pone blanca y la barra de título dice “No responde”.» «Los usuarios dicen que se cuelga de vez en cuando, pero nunca se reproduce en una máquina de desarrollo.» Son quejas habituales sobre las aplicaciones empresariales de Windows.

Lo primero que hay que retener es que quien muestra «No responde» no es la propia aplicación, sino Windows. Windows detecta que el procesamiento de mensajes de la ventana se ha detenido y sustituye la pantalla original por una ventana de reemplazo. La clave para rastrear la causa es qué está haciendo el hilo de IU que posee esa ventana, de modo que no puede procesar el siguiente mensaje.¹²

Este artículo se dirige a desarrolladores que crean aplicaciones empresariales en Windows y al personal de TI que recibe consultas sobre aplicaciones que se cuelgan. Procede en el orden juicio del sistema operativo → bucle de mensajes → acotar la causa por categoría → diseños que no se cuelgan → procedimiento de investigación. Si necesita investigar una aplicación que está colgada ahora mismo, lea primero el capítulo 7.

1. La conclusión primero: no ocultar la visualización, dejar libre el hilo de IU

El mecanismo de «No responde», cómo corregirlo y cómo investigarlo se ven con más claridad si se separan así.

El principio de la contramedida es no esperar mucho ni calcular de forma pesada en el hilo de IU. El hilo de IU se encarga de la entrada, el dibujo, la visualización de progreso y la aceptación de la cancelación, y se separa del trabajo que lleva tiempo.³

Además, el tiempo hasta que aparece «No responde» y el tiempo de respuesta cómodo de usar son cosas distintas. Quedarse por debajo de 5 segundos no basta. La sección 4.5 explica esta diferencia.

2. «No responde» es el juicio del sistema operativo: la regla de 5 segundos y la pantalla de reemplazo

2.1 La unidad de juicio no es el proceso entero, sino la ventana y el hilo propietario

En la descripción de Microsoft de IsHungAppWindow, una ventana se considera que no responde cuando cumple las condiciones siguientes.¹

El sistema operativo no mira qué está calculando la aplicación, sino si el bucle de mensajes está girando. El bucle de mensajes es el mecanismo que recupera en orden las peticiones de entrada y de repintado y las procesa. El capítulo 3 explica el funcionamiento concreto.

La misma documentación indica también que el valor de 5 segundos puede cambiar en el futuro. Es el tiempo de espera interno del juicio de no respuesta, no un criterio de diseño que diga «puede detener la IU hasta 5 segundos».¹

El juicio no es por proceso. En una aplicación con varios hilos de IU, una ventana puede estar colgada mientras las ventanas que pertenecen a otros hilos siguen funcionando. En la investigación también hay que ir más allá del proceso y identificar el hilo que posee la ventana colgada.

2.2 La pantalla blanca esmerilada es una «ventana fantasma»

Cuando una ventana de nivel superior se juzga que no responde, Windows oculta la ventana original y la sustituye por una ventana fantasma con el mismo orden Z, posición, tamaño y aspecto. El «(No responde)» del título y el aspecto blanco esmerilado bajo el tema Aero vienen de esta pantalla de reemplazo, no de la aplicación colgada.²

Poder mover la ventana de reemplazo no significa que el contenido de la aplicación haya vuelto a funcionar. El sistema operativo solo asume las operaciones mínimas.²⁴

Una queja de que «la visualización aparece demasiado pronto» también se trata primero como un problema de que el hilo de IU no vuelve al procesamiento de mensajes durante mucho tiempo. Investigar el procesamiento detenido va antes de suprimir la visualización.

2.3 Que no aparezca bajo el depurador no significa que no esté colgada

Mientras hay un depurador acoplado, el sistema operativo no crea ventanas fantasma. Por eso, una diferencia del tipo «no aparece al depurar, pero pasa a No responde en la ejecución normal» puede significar que el hilo de IU está bloqueado exactamente igual y solo cambia la visualización.²

También hay una API que deshabilita el intercambio por ventana fantasma a escala de proceso, pero no es una API que corrija el cuelgue en sí. La sección 6.2 separa el uso previsto.

3. Por qué se detiene la pantalla: el hilo de IU y el bucle de mensajes

3.1 La entrada y el repintado los procesa el mismo hilo

Las aplicaciones GUI de Windows están dirigidas por eventos. Reciben mensajes del ratón, el teclado, peticiones de repintado, temporizadores, etc., y ejecutan el procesamiento correspondiente a cada uno. Cada hilo que crea una ventana tiene una cola de mensajes y ejecuta un bucle como el siguiente.⁵

MSG msg;
while (GetMessage(&msg, NULL, 0, 0) > 0) {
    TranslateMessage(&msg);
    DispatchMessage(&msg);   // se llama al procedimiento de ventana
}

GetMessage recupera un mensaje de la cola, y DispatchMessage llama al procedimiento de ventana de la ventana. El procedimiento de ventana es la función que ejecuta el procesamiento correspondiente a un mensaje. El manejo del clic de un botón, el repintado y los controladores de eventos de WinForms y WPF se conectan todos a este procesamiento de mensajes en el hilo de IU.⁶

flowchart TB
    accTitle: Estructura básica del bucle de mensajes
    accDescr: El sistema operativo coloca la entrada de ratón, teclado y demás en la cola de mensajes del hilo; el bucle del hilo de IU la recupera con GetMessage, llama al procedimiento de ventana con DispatchMessage y vuelve al principio del bucle cuando termina el procesamiento
    os["SO (entrada, peticiones de repintado, temporizadores)"] --> q["Cola de mensajes del hilo"]
    q --> gm["Recuperar con GetMessage"]
    gm --> dm["DispatchMessage"]
    dm --> wp["Procesar en el procedimiento de ventana"]
    wp --> gm

Figura 1: Recuperar un mensaje, procesarlo en el procedimiento de ventana y volver al bucle. Este ciclo sostiene la entrada y el dibujo.

¿Qué ocurre entonces si desde un controlador de clic se llama a un procesamiento largo? Hasta que ese procesamiento no vuelva, el hilo de IU no puede recuperar el siguiente mensaje. Los clics y las peticiones de repintado que llegan después ya no se pueden procesar. Esa es la estructura básica de una «pantalla congelada».

3.2 PostMessage y SendMessage vuelven en momentos distintos

La entrega de mensajes tiene dos caminos: uno que coloca el mensaje en la cola y otro que espera a que termine el procesamiento.⁵⁷

En particular, cuando se envía SendMessage a una ventana de otro hilo, el emisor también queda a la espera hasta que el receptor pueda procesar el mensaje. Esta diferencia conduce de forma directa al interbloqueo de la sección 4.3.⁷

4. Causas por categoría: cinco patrones que taponan el hilo de IU

El aspecto de «No responde» es el mismo, pero lo que taponan es distinto. Separe primero los candidatos y confírmelos al final con los volcados y trazas del capítulo 7.

4.1 E/S síncrona y llamadas de red

El patrón más habitual es, en el controlador de clic de un botón, hacer de forma síncrona la lectura o escritura de un archivo grande, una consulta a base de datos, una API web o el acceso a una unidad de red.

Lo que termina en una fracción de segundo en la máquina de desarrollo puede convertirse en una espera de varias decenas de segundos con la latencia de red de producción o un problema del servidor de archivos. Las unidades de red tienen tiempos de espera largos cuando se corta la conexión, lo que agrava el síntoma. «En la máquina de desarrollo era rápido» no es motivo para esperar en el hilo de IU.

4.2 El hilo de IU espera un bloqueo que sostiene un trabajador

Los bloqueos que protegen datos compartidos también pueden detener la IU. Si un trabajador sostiene un bloqueo durante mucho tiempo y el hilo de IU también intenta tomarlo, el hilo de IU espera hasta poder adquirirlo.

Aunque mueva el trabajo a un trabajador, la pantalla no se libera si el hilo de IU espera a que termine ese trabajo o a que se libere el bloqueo. La disciplina de los bloqueos se trata con detalle en la serie práctica de multithreading.

4.3 Esperar mutuamente la finalización con SendMessage

El interbloqueo clásico es la combinación en la que el hilo de IU espera a que termine un trabajador, y ese trabajador envía SendMessage a la IU y espera. La IU está en espera y no puede procesar mensajes, y el trabajador no puede volver de SendMessage, así que ninguno de los dos avanza.⁷⁵

sequenceDiagram
    accTitle: Interbloqueo por SendMessage entre hilos
    accDescr: Cuando un hilo trabajador envía SendMessage a la ventana del hilo de IU mientras este está bloqueado esperando el resultado del trabajador, cada uno espera a que el otro termine y el resultado es un interbloqueo
    participant U as Hilo de IU
    participant W as Hilo trabajador
    U->>U: Esperar a que termine el trabajador (bloqueado)
    W->>U: SendMessage (no vuelve hasta que se procese)
    Note over U: No puede procesar mensajes (está esperando)
    Note over W: No puede volver de SendMessage
    Note over U,W: Espera mutua: interbloqueo

Figura 2: Separar el trabajo hacia un trabajador no basta. Si la IU y el trabajador esperan cada uno a que el otro termine, se produce un interbloqueo.

El envío a HWND_BROADCAST también exige cuidado. Basta una sola ventana que no responda para arrastrar al emisor. Cuando no puede seguir esperando, considere SendMessageTimeout, que pone un tiempo de espera, o PostMessage, que no espera a que termine el procesamiento.⁸

4.4 Un STA de COM se detiene y arrastra a otros hilos

Las llamadas desde otros hilos a un objeto STA se entregan como mensajes de ventana. Por eso, cuando el hilo de IU (un STA) está taponado, las llamadas COM hacia él también se bloquean. Es una estructura en la que no solo la IU, sino también los llamadores, quedan en espera.

La relación entre apartamentos y procesamiento de mensajes se explica en el artículo de COM STA/MTA.

4.5 Repetir «una vez es un instante» 100 veces

Aunque un procesamiento síncrono de 50 ms, repetido 100 veces, suma 5 segundos. No juzgue midiendo cada función por separado y declarándola corta; piense en el tiempo total hasta que el hilo de IU vuelve al bucle de mensajes.

La sensación de lentitud empieza hacia los 100 ms. No tome como objetivo los 5 segundos del juicio de no respuesta; diseñe asumiendo que el hilo de IU solo puede taponarse en milisegundos.

5. Diseños que no se cuelgan: separar la ejecución del trabajo y la actualización de la pantalla

5.1 Separar el cálculo y las API síncronas de la E/S asíncrona

El principio de la contramedida es sacar del hilo de IU el trabajo que lleva tiempo. No todo se mueve, sin embargo, del mismo modo.

Con E/S asíncrona no hace falta ocupar un hilo solo para esperar. El ejemplo de código de más abajo también distingue: Task.Run para el cálculo y la API asíncrona nativa para la comunicación HTTP.³

5.2 En C#, volver a la IU con async/await y actualizarla

El ejemplo siguiente separa, en un controlador de clic de WinForms, el trabajo pesado y la actualización de la IU. Como este ejemplo parte de un controlador de eventos de IU y conserva el contexto de ejecución de la IU, la continuación después de await vuelve al hilo de IU y puede actualizar los controles.³

private async void RunButton_Click(object sender, EventArgs e)
{
    runButton.Enabled = false;
    try
    {
        // Cálculo con mucha carga de CPU y API solo síncronas: al trabajador con Task.Run
        var result = await Task.Run(() => HeavyCalculation(input));

        // Para E/S, usar una API nativamente asíncrona (tampoco consume un hilo)
        var data = await httpClient.GetStringAsync(url);

        // Tras await estamos de vuelta en el hilo de IU, se puede tocar los controles de forma directa
        resultLabel.Text = result + data.Length.ToString();
    }
    catch (Exception ex)
    {
        // Una excepción que se escapa de un controlador async void tumba la aplicación. Capturarla aquí
        MessageBox.Show($"El procesamiento ha fallado: {ex.Message}");
    }
    finally
    {
        runButton.Enabled = true;
    }
}

Hay cuatro puntos que retener.

Es un ejemplo de código que muestra el reparto de papeles; la implementación de HeavyCalculation y similares, el trato al cierre del formulario, y el progreso y la cancelación se omiten. El progreso y la interrupción que necesita un trabajo largo se incorporan aparte, como en la sección 5.4.

Los controles de WinForms y los elementos de WPF se tratan desde el hilo que los creó. Tocarlos de forma directa desde un trabajador lleva a excepciones o a comportamiento indefinido. Para volver de forma explícita al hilo de IU, use Control.Invoke / BeginInvoke en WinForms y Dispatcher.InvokeAsync en WPF.³

5.3 En Win32, notificar la finalización con PostMessage

El reparto de papeles es el mismo en Win32 nativo. Pase el trabajo a un trabajador y, al terminar, envíe con PostMessage un mensaje de finalización personalizado y actualice la pantalla en el procedimiento de ventana del hilo de IU. Como PostMessage vuelve una vez encolado el mensaje, el trabajador no espera a que termine el procesamiento de la IU.⁷

flowchart TB
    accTitle: Reparto de papeles de una aplicación que no se cuelga
    accDescr: El hilo de IU solo se encarga de la entrada, la visualización de progreso y la aceptación de la cancelación; un hilo trabajador ejecuta el trabajo pesado y devuelve la finalización al hilo de IU mediante PostMessage o una continuación await
    ui["Hilo de IU: entrada, progreso, cancelación"] -->|"pasar el trabajo"| w["Hilo trabajador: trabajo pesado"]
    w -->|"PostMessage / continuación await"| ui
    ui -.-> ng["Prohibido E/S síncrona o cálculo largo en el hilo de IU"]

Figura 3: Pasar el cálculo pesado y el procesamiento síncrono al trabajador, y devolver las actualizaciones de pantalla al hilo de IU. La E/S asíncrona se espera con una API asíncrona, como en la sección 5.1.

La espera del trabajador en sí se escribe según la disciplina tratada en el artículo de variables de condición. También es importante que el hilo de IU no vuelva a esperar al trabajador de forma síncrona.

5.4 Diseñar desde el principio el progreso y la cancelación

Aunque la pantalla no se congele, si no cambia nada durante mucho tiempo el usuario no puede saber si sigue trabajando. Por eso diseñe la visualización de progreso y la aceptación de la cancelación como parte del procesamiento.

El trabajador se interrumpe en un punto de corte razonable y limpia. Disponer de medios de progreso y de cancelación reduce las situaciones en las que el usuario recurre a un cierre forzado. El cierre forzado puede provocar corrupción de datos.

6. Dos métodos que parecen atajos, y sus límites

6.1 DoEvents invita a otros eventos a mitad del procesamiento

Si inserta Application.DoEvents() o un bucle PeekMessage durante un trabajo pesado, se procesan mensajes y se evita la visualización de «No responde». Sin embargo, otro controlador de eventos se ejecuta entonces mientras el procesamiento original aún no ha terminado. Eso es reentrada.

Por ejemplo, se llama a DoEvents a mitad de transformar datos y se procesa un segundo clic del botón que estaba en cola. Ese controlador reescribe los mismos datos y luego el procesamiento original se reanuda. En ese orden, el estado que el procesamiento original daba por supuesto ya se ha perdido.

No solo reentran los botones. También entran el cierre del formulario y los temporizadores. Errores como datos en vuelo rotos o una excepción al tocar un formulario cerrado dependen del momento, se reproducen mal y suelen ser más difíciles de investigar que «No responde».

El principio es separar el trabajo, no bombear el bucle a mano. El procesamiento manual de mensajes se limita a estructuras acotadas, como un cuadro de diálogo de progreso modal. Para un trabajo largo habitual, use la separación y la prevención de reentrada del capítulo 5.

6.2 Deshabilitar las ventanas fantasma no devuelve el control

DisableProcessWindowsGhosting es una API que deshabilita el intercambio por ventana fantasma para el proceso que llama. La deshabilitación dura durante la vida del proceso.⁴

Existe para usos especiales, como un terminal quiosco, donde se quiere evitar que el sistema operativo ponga una ventana de reemplazo operable. El hecho de que el procesamiento de mensajes se haya detenido no cambia, y el usuario pierde también el medio de mover o salir que ofrecía la ventana fantasma. No es algo que se use como contramedida de «No responde» en una aplicación ordinaria.

7. Procedimiento de investigación: conservar el momento del cuelgue antes de cerrar

7.1 Tomar primero un volcado

En la investigación de «se cuelga de vez en cuando», lo más valioso es el estado de los hilos en el momento mismo del cuelgue. En cuanto se sale o se reinicia, ese estado se pierde.

En la pestaña «Detalles» del Administrador de tareas, haga clic con el botón derecho en el proceso de destino y elija «Crear archivo de volcado». Obtiene un volcado completo que incluye las pilas de todos los hilos. Comparta también el procedimiento con quienes reciben las consultas: «si se cuelga, tome un volcado antes de cerrar».

Para construir el mecanismo de recolección, consulte el artículo de recolección de volcados de memoria.

7.2 Mirar el hilo que posee la ventana colgada

Abra el volcado en WinDbg y compruebe la pila del hilo de IU. El hilo que hace girar el bucle de mensajes suele ser el hilo 0, pero hay aplicaciones con varios hilos de IU, así que no decida solo por el número; mire el hilo que posee la ventana colgada.

En la pila del hilo de IU aparece en qué está esperando. Si se sospecha un interbloqueo, empareje los destinos de espera de ambos hilos, no de uno solo. Cómo leerlas se explica en el artículo introductorio de WinDbg.

flowchart TB
    accTitle: Procedimiento básico para investigar No responde
    accDescr: Tomar un volcado en el momento del cuelgue, mirar la pila del hilo de IU, identificar si está detenido en E/S síncrona, una espera de bloqueo o SendMessage entre hilos, y conectar eso con la corrección de diseño correspondiente
    hang["El momento del cuelgue"] --> dump["Tomar un volcado (antes de cerrar)"]
    dump --> stack["Mirar la pila del hilo de IU"]
    stack --> io["E/S síncrona o espera de red"]
    stack --> lock["Espera de bloqueo"]
    stack --> sm["SendMessage entre hilos"]
    io -.-> fix["Separar el punto afectado hacia un trabajador"]
    lock -.-> fix
    sm -.-> fix

Figura 4: Desde el volcado del momento del cuelgue, seguir a qué espera el hilo de IU. Si es E/S, asincronizarla o separarla; si es un bloqueo o SendMessage, comprobar también la estructura de espera.

7.3 Distinguir la inspección en vivo y el análisis en el tiempo

Además de los volcados, hay una forma de mirar un proceso en ejecución en el momento y una forma de registrar el transcurso del tiempo.

Cómo tomar una serie temporal se trata en WPR/WPA en la práctica.

7.4 Acotar candidatos a partir del síntoma y confirmarlos con pruebas

Las condiciones de reproducción también son una entrada a la investigación. No decida la causa solo por el síntoma; crúcela con volcados y trazas.

8. Resumen

«No responde» es un mecanismo en el que Windows juzga que el procesamiento de mensajes de una ventana se ha detenido y pone una pantalla de reemplazo. La unidad de juicio es la ventana y el hilo GUI que la posee, no el proceso entero. El tiempo de espera interno de 5 segundos es un valor que puede cambiar en el futuro y se distingue del tiempo de respuesta cómodo de una IU.¹²

Lo que hay que corregir no es la visualización, sino el cálculo o la espera que ocupa el hilo de IU durante mucho tiempo. El trabajo de CPU y las API solo síncronas van al trabajador, la E/S asíncrona a API asíncronas, y las actualizaciones de pantalla vuelven al hilo de IU. Diseñe juntos el progreso, la cancelación y la prevención de reentrada. Evadirlo con DoEvents o deshabilitar las ventanas fantasma no es un sustituto.

Cuando la causa es desconocida, empiece por tomar un volcado antes de salir y mirar a qué espera el hilo que posee la ventana colgada. Sustituya «parece roto» por «el hilo de IU no puede volver al procesamiento de mensajes», y los lugares que investigar y las correcciones de diseño se conectan.

Artículos relacionados

• Despertares espurios — Por qué las variables de condición despiertan «sin haber sido notificadas» y cómo esperar correctamente en Windows
• Buenas prácticas de multithreading en la práctica — Edición .NET: qué decidir antes de aumentar los hilos
• Conocimientos básicos de STA/MTA en COM - El modelo de subprocesos y cómo evitar los bloqueos
• WinDbg + SOS para leer volcados de memoria — introducción práctica al análisis tras la recolección
• Process Explorer / Handle / VMMap en la práctica ── cómo rastrear cuelgues, fugas y «archivo en uso» desde el estado actual
• El apagado de Windows visto desde la aplicación ── cómo sobrevivir correctamente a la notificación de cierre, el reinicio y el corte de energía

Áreas de consultoría relacionadas

En KomuraSoft LLC nos encargamos de investigaciones de causa (análisis de volcados y análisis de trazas) de aplicaciones empresariales que «se cuelgan de vez en cuando» o pasan a «No responde», de refactorizar código de IU legado lleno de procesamiento síncrono hacia async/await y la separación en hilos trabajadores, y de revisiones de diseños de IU que no se congelan. Incluso cuando el procedimiento de reproducción aún no se conoce, podemos ayudar empezando por el diseño de cómo recoger las pruebas.

• Investigación de fallos y análisis de causas
• Consultoría técnica y revisión de diseño
• Desarrollo de aplicaciones Windows
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Bajo qué condiciones aparece «No responde»?

El sistema operativo juzga que una ventana no responde cuando una aplicación con ventana no está esperando entrada, no está en su procesamiento de arranque y no ha recuperado un mensaje (PeekMessage) durante 5 segundos. La ventana de nivel superior así juzgada se oculta y se sustituye por una «ventana fantasma» de la misma posición, tamaño y aspecto. El texto «(No responde)» de la barra de título y el aspecto blanco esmerilado pertenecen a esta ventana fantasma, que solo permite mover, minimizar o cerrar. En otras palabras, «No responde» no es algo que muestre la propia aplicación: es una pantalla que el sistema operativo pone en su lugar.

¿Hay un ajuste para que «No responde» no aparezca mientras el trabajo está en curso?

Llamar a DisableProcessWindowsGhosting deshabilita el intercambio por una ventana fantasma para ese proceso. Eso solo hace el cuelgue menos visible para el usuario: la ventana sigue sin reaccionar a la entrada y, desde el punto de vista del usuario, es una congelación completa, sin forma de moverla o cerrarla. La corrección real no es suprimir la visualización, sino mover el trabajo pesado a un hilo trabajador para que el hilo de IU no quede bloqueado ni una décima de segundo, y mucho menos cinco. Tenga en cuenta también que el sistema operativo no crea una ventana fantasma mientras hay un depurador acoplado, así que puede parecer que «No responde nunca ocurre durante la depuración».

¿Es aceptable evitar «No responde» con DoEvents (bombeando el bucle de mensajes a mano)?

No se recomienda. Hacer girar DoEvents o un bucle PeekMessage en medio de un trabajo pesado esquivará el juicio de no respuesta, pero entonces cualquier controlador de eventos puede reentrar: un segundo clic del botón, cerrar la ventana, un temporizador, etc. Que otro controlador reescriba datos que aún se están procesando, o toque un formulario que ya debería estar cerrado y lance una excepción, produce errores de reentrada que dependen del momento y son difíciles de reproducir, más molestos que el propio «No responde». El enfoque adecuado es mover el propio trabajo a un hilo trabajador con Task.Run o similar, y dejar que el hilo de IU se encargue solo de mostrar el progreso y aceptar la cancelación.

¿Cómo actualizo la pantalla (los controles) desde un hilo trabajador?

Los controles de WinForms y los elementos de WPF solo pueden tocarse desde el hilo que los creó (normalmente el hilo de IU). Tocarlos de forma directa desde un hilo trabajador provoca excepciones o comportamiento indefinido. En C#, async/await es el camino más fácil: la continuación después de await regresa al hilo de IU que llamó, así que puede actualizar los controles con normalidad después del await. Para cambiar de forma explícita, use Control.Invoke/BeginInvoke en WinForms y Dispatcher.InvokeAsync en WPF. En Win32 nativo, el patrón establecido es que el hilo trabajador envíe con PostMessage un mensaje de finalización personalizado al hilo de IU, y que el procedimiento de ventana actualice la pantalla.

¿Cómo investigo la causa de una aplicación que muestra «No responde»?

Lo importante es capturar el estado en el momento mismo del cuelgue. Primero tome un volcado completo desde la pestaña Detalles del Administrador de tareas con «Crear archivo de volcado» y luego, en WinDbg, mire la pila del hilo de IU (el hilo que ejecuta el bucle de mensajes). Si está atascado en E/S síncrona, una espera de red, una espera de bloqueo o esperando a otro hilo a través de SendMessage, aparece en la pila tal cual. Para mirar un proceso en vivo, use la lista de hilos y la vista de pila de Process Explorer; para seguirlo a lo largo del tiempo, capture una traza con WPR. Véase también el artículo introductorio de WinDbg de este sitio, Process Explorer en la práctica y WPR/WPA en la práctica.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.