LiveKernelEvent 141 es un registro que escribe Windows cuando la tarjeta gráfica deja de responder y el sistema reinicia su controlador por su cuenta. Detrás del código hay casi siempre un TDR (Timeout Detection and Recovery): el driver gráfico tarda más de dos segundos en contestar y Windows lo reinicia sin apagar el equipo.
¿Dónde se ve el código 141 en Windows?
El sitio más cómodo para leerlo es el Historial de confiabilidad. Lo abres escribiendo «confiabilidad» en el menú de inicio y entrando en «Ver historial de confiabilidad». Los eventos salen por día con una descripción legible, y al pinchar uno ves la firma completa.
También puedes verlo en el Visor de eventos (Win + R y eventvwr.msc). El registro se guarda dentro de Aplicación, no en Sistema, y aparece como información de Windows Error Reporting, no como error en rojo. Para encontrarlo sin recorrer miles de líneas, usa «Filtrar registro actual» en el panel derecho y filtra por el origen Windows Error Reporting.
Antes de seguir, descarta los falsos positivos. En algunos equipos salen varios 141 agrupados siempre en el arranque, a la misma hora y sin ningún tirón perceptible.
Suele ser Windows reescribiendo volcados antiguos, no un fallo activo: un usuario de Tom’s Hardware describió tres avisos que volvían en cada inicio hasta que borró los .dmp viejos de la carpeta C:\Windows\LiveKernelReports (Tom’s Hardware). El evento 141 en el que debes fijarte es el que coincide con un cuelgue real, no el que se repite idéntico al encender.
¿Cómo se interpreta la firma del evento?
Al abrir el evento verás un campo llamado «Id. de depósito» (en inglés Bucket ID), el resumen que Windows genera para clasificar el fallo. Es un texto del tipo LKD_0x141_Tdr:6_IMAGE_nvlddmkm.sys_Ampere_3D y, aunque parezca un galimatías, cada parte significa algo.
El fragmento Tdr confirma que fue un timeout del controlador y no un fallo de memoria. El nombre del archivo dice el fabricante de la tarjeta gráfica: nvlddmkm.sys es Nvidia, amdkmdag.sys es AMD e igdkmd64.sys es gráfica Intel.
Saber el fabricante cambia por dónde empiezas. Si apunta a la gráfica dedicada, el primer sospechoso es su driver. Si apunta a la integrada en un portátil híbrido, el conflicto suele estar en cómo Windows reparte el trabajo entre las dos gráficas..
¿Cuándo es un problema de software?
La causa más probable es el controlador gráfico. Un driver recién actualizado con un bug, o uno viejo que no se lleva bien con la última versión de Windows, provoca el timeout en cuanto la tarjeta recibe carga. Si el error 141 aparece siempre en el mismo juego o programa y nunca con el equipo en reposo, el driver es el primer sitio donde debes mirar.
La reinstalación limpia del driver resuelve la mayoría de estos casos. No basta con desinstalar desde Configuración, porque quedan restos. Usa DDU (Display Driver Uninstaller) en modo seguro, deja que borre todo rastro e instala la última versión desde la web de Nvidia, AMD o Intel, nunca la genérica de Windows. Microsoft recomienda este procedimiento para el evento141 (Microsoft Q&A).
El overclock es el segundo factor de software. Si tienes MSI Afterburner u otra utilidad subiendo frecuencias o bajando voltajes, una curva inestable cuelga la GPU bajo carga y dispara el evento 141. Vuelve a valores de fábrica y comprueba si el evento desaparece.
En portátiles con dos gráficas, prueba a desactivar la programación de GPU acelerada por hardware (Configuración, Pantalla, Gráficos). No siempre está disponible, pero cuando lo está, apagarla estabiliza bastantes timeouts en sistemas híbridos. En esa misma pantalla puedes asignar la GPU dedicada a las aplicaciones exigentes para que no recaigan en la integrada.
¿Cuándo apunta a un fallo de hardware?
Si has limpiado el driver, quitado el overclock y el evento 141 sigue apareciendo, el fallo es de un componente de tu PC. Fijarte en cuándo se cuelga ahorra mucho tiempo a la hora de dar con el componente.
Si aparece justo cuando la tarjeta gráfica dispara su consumo (al cargar una escena pesada, al arrancar un test) y no en mitad de una carga estable, lo más probable es la fuente de alimentación. Una fuente justa o de mala calidad no entrega ese pico y la gráfica se reinicia.
Si los cuelgues son más caprichosos y también aparecen en reposo o con tareas ligeras, mira la memoria RAM. El Diagnóstico de memoria de Windows da una primera pista, aunque para quedarte tranquilo conviene pasar MemTest86 a cada módulo por separado.
Y luego está la temperatura. Una gráfica que toca su límite térmico se protege bajando la frecuencia de golpe o apagándose, y Windows lo anota como timeout. Abre HWiNFO mientras provocas el cuelgue, limpia el polvo de los disipadores y comprueba que los ventiladores giran. Si la tarjeta supera sus máximos justo antes de cada evento, el evento 141 es solo el aviso de algo que se está calentando de más.
¿Y el ajuste TdrDelay del registro?
Si haces una búsqueda en google encontrarás que para solucionar este problema del TdrDelay se apunta a la creación de un valor en HKLM\System\CurrentControlSet\Control\GraphicsDrivers para subir a 8 segundos el tiempo que Windows espera antes de dar el driver por perdido. Microsoft lo menciona, pero deja claro que solo tapa el síntoma (Microsoft Q&A).
Si tras aplicarlo los cuelgues se espacian pero no se van, el problema sigue ahí con más margen de espera. Te sirve para salir del paso mientras pides una fuente o cambias un módulo, no como arreglo permanente. Crea un punto de restauración antes de tocar el registro.
¿En qué orden conviene revisar el LiveKernelEvent 141?
Lee primero el Id. de depósito como hemos visto anteriormente y que en treinta segundos te confirma si es un TDR y de qué fabricante es la gráfica.
Después actualiza Windows y haz la limpieza del driver con DDU en modo seguro, el paso que soluciona la mayoría de los casos. Si has hecho overclock, suprímelo antes de seguir y mira las temperaturas mientras fuerzas el cuelgue. La fuente y la RAM van al final pues son lo más trabajoso de comprobar y casi nunca son las culpables.
Mucha gente formatea antes de leer el Id. de depósito y se lleva la sorpresa de que el 141 vuelve, porque la fuente o el módulo de RAM que lo causaban siguen ahí después del formateo
Preguntas frecuentes
¿LiveKernelEvent 141 es lo mismo que un pantallazo azul? No. El pantallazo azul reinicia el equipo entero por un fallo crítico. El 141 es un evento que Windows registra cuando un componente, casi siempre la tarjeta gráfica, dejó de responder pero el sistema logró recuperarse sin reiniciar del todo.
¿Puede ser la RAM la causa del 141? Sí. Una memoria defectuosa genera este evento, sobre todo cuando los cuelgues son erráticos y no aparecen solo bajo carga gráfica. Conviene pasar el Diagnóstico de memoria de Windows y, para confirmar, MemTest86 módulo a módulo.
¿Reinstalar el driver de la gráfica basta para solucionarlo? En la mayoría de casos de software, sí, siempre que lo hagas con DDU en modo seguro y luego instales la versión oficial del fabricante. Si el 141 persiste tras esa limpieza, el problema casi seguro está en el hardware.
¿Es peligroso editar el TdrDelay en el registro? Tocar el registro siempre exige cuidado, pero el riesgo de ese valor concreto es bajo. El problema no es el riesgo, es que solo amplía el margen de espera y enmascara el fallo real, así que no sirve como solución definitiva.
¿Por qué veo el evento 141 si no he notado ningún cuelgue? Puede ser un microcuelgue de un segundo que ni percibiste, o registros antiguos que Windows reescribe en cada arranque. Si no hay tirones ni reinicios y son siempre los mismos eventos repetidos, suele ser ruido de volcados viejos.
