Cuando el controlador de tu GPU entra en un bucle de fallos, la máquina deja de comportarse como un ordenador y empieza a comportarse como una máquina tragaperras. Arrancas, aparece el escritorio, la pantalla parpadea y luego—pantalla negra, reinicio del controlador, repetir. A veces ni siquiera puedes iniciar sesión el tiempo suficiente para hacer clic en “desinstalar”.
Este es uno de esos problemas donde “simplemente reinstala el controlador” suena razonable y falla de forma espectacular. Una instalación limpia no es una sola acción. Es una secuencia controlada: recopilar pruebas, sacar a Windows Update del bucle, usar el Modo seguro para que el controlador no esté luchando activamente, eliminar los artefactos correctos (no elementos aleatorios) y luego reinstalar con verificación. Hazlo una vez, hazlo bien, y normalmente no volverás a ver el problema—salvo que el hardware esté realmente fallando, lo cual es otro tipo de emoción.
Cómo se manifiesta un bucle de fallos de controlador (y qué no es)
Un “bucle de fallos de controlador” suele ser la pila gráfica de Windows reiniciando repetidamente el controlador de pantalla. Verás:
- Parpadeos de la pantalla a negro y de vuelta, a menudo justo después de iniciar sesión.
- Aplicaciones que se cierran con errores “device removed”/“device hung” (DirectX/Vulkan).
- Registros en el Visor de Eventos como “Display driver nvlddmkm stopped responding and has successfully recovered” o equivalentes de AMD.
- Quedarse en pantalla negra con cursor, o el escritorio carga pero es inutilizable.
- Ventiladores que se aceleran brevemente, luego silencio, y otra vez aceleración.
Qué no es normalmente:
- Un fallo aleatorio de un juego con escritorio estable después. Eso suele ser el juego, una superposición o un undervolt.
- Un apagado completo del sistema bajo carga. Eso suele ser PSU, cableado de alimentación, VRM o apagado térmico.
- Artefactos consistentes en la pantalla del BIOS. Eso suele ser daño físico en la memoria o el núcleo de la GPU.
Si estás obteniendo un bucle específicamente después de una actualización de controlador, una actualización de Windows o un intercambio de GPU, trátalo como un problema de integridad de instalación hasta que se demuestre lo contrario. El objetivo es devolverte a una versión estable del controlador con la mínima superstición.
Broma #1 (corta, relevante): Un bucle de fallos de controlador de GPU es la única cinta de correr donde la computadora corre y tú aún pierdes progreso.
Guía de diagnóstico rápido (primera/segunda/tercera)
Primero: confirma que es un bucle de reinicios del controlador, no un colapso de energía/hardware
- Revisa el Visor de Eventos en busca de reinicios del controlador de pantalla y eventos TDR.
- Revisa el Monitor de confiabilidad en busca de entradas recurrentes “Windows Hardware Error Architecture” o “LiveKernelEvent”.
- Chequea temperaturas si puedes permanecer en Windows durante 60 segundos: si la GPU alcanza límites térmicos al instante, tienes un problema de refrigeración o de pasta térmica.
Decisión: Si el sistema se apaga de forma abrupta, se reinicia sin registros o muestra artefactos en el BIOS, para la danza del controlador e investiga PSU/cables/hardware de la GPU. Si son reinicios recuperables y parpadeos negros, procede con un flujo de trabajo de instalación limpia del controlador.
Segundo: evita que Windows “ayude”
- Desconéctate de la red o desactiva temporalmente las actualizaciones automáticas de controladores de Windows.
- Identifica si Windows sigue inyectando un controlador anterior justo después de desinstalar.
Decisión: Si desinstalas y el controlador reaparece en el reinicio sin que lo instales, Windows Update o DriverStore está reinfectando el sistema. Debes aislar y controlar eso.
Tercero: aisla la pila de controladores y las superposiciones
- Arranca en Modo seguro para eliminar el controlador del proveedor activo.
- Elimina capas de conflicto conocidas (grabadores de pantalla, controladores de kernel RGB, herramientas de monitorización) solo después de haber capturado los registros.
Decisión: Si el Modo seguro es estable y el modo normal no lo es, estás ante un problema de controlador/pila, no “Windows está roto”. Puedes arreglarlo con disciplina.
Hechos y contexto interesantes (para que el comportamiento tenga sentido)
- TDR existe para mantener tu escritorio vivo. Timeout Detection and Recovery (TDR) de Windows reinicia el controlador de la GPU cuando ésta parece colgarse, en lugar de forzar un reinicio. Excelente para tiempo de actividad, confuso durante fallos.
- WDDM cambió todo. Desde Windows Vista, el Windows Display Driver Model movió la planificación y gestión de memoria de la GPU a un modelo más estructurado. Mejoró la estabilidad en general, pero dejó restos parciales de controladores más “interesantes”.
- Windows mantiene un almacén de controladores. DriverStore almacena paquetes de controladores para que Windows pueda reubicarlos. Esto es fantástico cuando desaparece el controlador de tu NIC—menos fantástico cuando revive un paquete de pantalla defectuoso.
- DDU se hizo popular porque los desinstaladores no son cirujanos. Los desinstaladores de los proveedores a menudo dejan claves de registro, servicios, paquetes de controladores y configuraciones pensadas para “actualizaciones suaves”. Las actualizaciones suaves son precisamente lo que no quieres en un bucle de fallos.
- “Instalación limpia” dentro del instalador de NVIDIA no es DDU. Restaura algunas configuraciones y perfiles, pero no desinfecta completamente el DriverStore ni elimina todos los artefactos.
- Las gráficas híbridas añaden complejidad. Los portátiles con iGPU + dGPU (Optimus, Advanced Optimus, AMD Switchable Graphics) pueden fallar de formas que los sobremesas nunca lo harán—dispositivo equivocado consigue la ruta primaria, estado de energía incorrecto, modo de multiplexor erróneo.
- La programación de GPU acelerada por hardware (HAGS) es relativamente nueva. Puede ser beneficiosa, pero añade una pieza más en movimiento en la tubería. Cuando las cosas son inestables, menos piezas móviles es una estrategia válida.
- “Studio” vs “Game Ready” es principalmente empaquetado y cadencia de validación. No es magia. Pero cambiar de rama puede evitar una regresión mala cuando una pista envía un bug primero.
Puntos de decisión: ¿software, configuración o hardware?
No quieres pasar tres horas haciendo una limpieza perfecta con DDU si la GPU está fallando físicamente. A la inversa, no quieres RMA una GPU porque Windows Update reinstaló un controlador incompatibile.
Señales de que probablemente es software/configuración
- El Modo seguro es estable; el modo normal parpadea y reinicia.
- El problema comenzó inmediatamente después de una actualización de controlador o de Windows.
- El Visor de Eventos muestra reinicios repetidos del controlador de pantalla (TDR) sin reinicios duros.
- Cambiar al Microsoft Basic Display Adapter detiene el bucle.
- Diferentes versiones del controlador se comportan de forma distinta (incluso si ambas son imperfectas).
Señales de que probablemente es hardware/energía
- Artefactos en BIOS/UEFI o antes de cargar Windows.
- El sistema pierde energía bajo carga (apagado instantáneo) sin registros útiles.
- El bucle de controladores persiste tras una instalación limpia del sistema operativo.
- Temperaturas de GPU o hotspots que se disparan de forma anormal en reposo, o fallos en ventiladores.
- Cambiar la PSU/cables/zócalo cambia los síntomas más que cambiar controladores.
También existe la zona gris: undervolts/overclocks inestables, RAM defectuosa o una PSU al límite pueden manifestarse como “fallos de controlador” porque el controlador es el componente obligado a lidiar con la falla. Se culpan los controladores porque están en la escena del crimen.
Una idea para pegar en un post-it: paraphrased idea
— Werner Vogels (mentalidad de fiabilidad: todo falla, así que diseña y opera en consecuencia). Eso es exactamente cómo deberías tratar los controladores de GPU en una estación de trabajo de producción: asume que pueden fallar y crea una ruta de recuperación.
Tareas prácticas con comandos (12+), salidas y decisiones
Estas tareas están diseñadas para Windows 10/11. Los comandos se pueden ejecutar en un símbolo del sistema o PowerShell elevados. Estoy usando un prompt estilo Linux en los bloques de código por restricciones de formato; los comandos en sí son nativos de Windows.
Tarea 1: Confirma la GPU y la versión actual del controlador (equivalente del Administrador de dispositivos vía PowerShell)
cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_VideoController | Select-Object Name,DriverVersion,DriverDate | Format-List"
Name : NVIDIA GeForce RTX 3080
DriverVersion : 31.0.15.5161
DriverDate : 12/01/2023 00:00:00
Qué significa: Estás viendo el controlador activo que Windows cree que está cargado.
Decisión: Si la versión no coincide con la que instalaste (o cambia tras reiniciar), Windows Update u otro paquete lo está sobrescribiendo.
Tarea 2: Busca reinicios del controlador de pantalla (Visor de Eventos vía wevtutil)
cr0x@server:~$ wevtutil qe System /q:"*[System[(EventID=4101)]]" /c:5 /f:text
Event[0]:
Log Name: System
Source: Display
Event ID: 4101
Level: Warning
Description:
Display driver nvlddmkm stopped responding and has successfully recovered.
Qué significa: El Evento ID 4101 es el síntoma clásico de recuperación TDR para controladores de pantalla.
Decisión: Si 4101 se repite en intervalos cortos después del arranque/inicio de sesión, estás tratando con un bucle de fallos, no con un fallo puntual de una aplicación.
Tarea 3: Comprueba pistas LiveKernelEvent / WHEA (datos del Monitor de confiabilidad vía WMI)
cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_ReliabilityRecords | Where-Object { $_.SourceName -match 'Windows' -or $_.SourceName -match 'Hardware' } | Select-Object -First 5 TimeGenerated,SourceName,ProductName,Message | Format-List"
TimeGenerated : 2/4/2026 9:12:10 AM
SourceName : Windows
ProductName : Windows
Message : The Desktop Window Manager process has exited.
Qué significa: DWM saliendo repetidamente suele correlacionar con inestabilidad del controlador de GPU.
Decisión: Si ves errores WHEA corregidos junto con reinicios de GPU, considera la PSU/RAM/estabilidad PCIe como contribuyentes.
Tarea 4: Identifica paquetes de controladores en DriverStore (pnputil)
cr0x@server:~$ pnputil /enum-drivers | findstr /i "nvidia amd display"
Published Name : oem42.inf
Original Name : nv_dispi.inf
Provider Name : NVIDIA
Class Name : Display adapters
Published Name : oem17.inf
Original Name : u0397489.inf
Provider Name : Advanced Micro Devices, Inc.
Class Name : Display adapters
Qué significa: DriverStore contiene uno o más paquetes de controladores de pantalla—a veces de varios proveedores si cambiaste de GPU.
Decisión: Si existen paquetes obsoletos del proveedor equivocado, planifica eliminarlos durante la limpieza para evitar la “resurrección” del controlador.
Tarea 5: Eliminar un paquete de controlador específico (con cuidado)
cr0x@server:~$ pnputil /delete-driver oem42.inf /uninstall /force
Driver package deleted successfully.
Qué significa: Esto elimina el paquete de DriverStore y desinstala los dispositivos que lo usan.
Decisión: Si la eliminación falla por “en uso”, no te has desvinculado limpiamente—usa Modo seguro o desactiva primero el dispositivo.
Tarea 6: Confirma que Windows no está instalando controladores automáticamente (Configuración de instalación de dispositivos vía registro)
cr0x@server:~$ reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching" /v SearchOrderConfig
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching
SearchOrderConfig REG_DWORD 0x1
Qué significa: 1 normalmente indica que Windows puede buscar controladores en Windows Update.
Decisión: Para una reconstrucción controlada, configura esto temporalmente a 0 y/o desconéctate de la red antes de reinstalar.
Tarea 7: Desactivar actualizaciones automáticas de controladores vía registro (control temporal)
cr0x@server:~$ reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DriverSearching" /v SearchOrderConfig /t REG_DWORD /d 0 /f
The operation completed successfully.
Qué significa: Windows debería dejar de buscar controladores automáticamente en Windows Update.
Decisión: Haz esto antes de la limpieza/reinstalación y luego revierte si tu entorno lo requiere.
Tarea 8: Verificar la configuración de arranque en Modo seguro (bcdedit)
cr0x@server:~$ bcdedit /enum | findstr /i safeboot
safeboot Minimal
Qué significa: El sistema está configurado para arrancar en Modo seguro (Minimal).
Decisión: Usa esto cuando no puedas acceder de forma fiable a las opciones avanzadas de arranque.
Tarea 9: Establecer Modo seguro para el siguiente arranque (luego reiniciar)
cr0x@server:~$ bcdedit /set {current} safeboot minimal
The operation completed successfully.
Qué significa: El próximo arranque irá a Modo seguro.
Decisión: Después de la limpieza, elimina la bandera safeboot o seguirás arrancando en Modo seguro y te preguntarás por qué falta el audio.
Tarea 10: Eliminar la bandera de arranque en Modo seguro (volver a arranque normal)
cr0x@server:~$ bcdedit /deletevalue {current} safeboot
The operation completed successfully.
Qué significa: Restaura el comportamiento de arranque normal.
Decisión: Ejecuta esto después de DDU y cuando estés listo para instalar el nuevo controlador.
Tarea 11: Comprobar si Windows usa Microsoft Basic Display Adapter (buena línea base)
cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Display | Format-Table -AutoSize Status,Class,FriendlyName,InstanceId"
OK Display Microsoft Basic Display Adapter PCI\VEN_10DE&DEV_2206&SUBSYS...
Qué significa: Estás con el controlador genérico. Resolución pobre, pero estable para trabajar.
Decisión: Si Basic Display Adapter es estable, tu bucle de fallos casi seguro está en el controlador del proveedor o en la capa de ajustes.
Tarea 12: Capturar software instalado relacionado con GPU que puede enganchar la pila
cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*,HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object { $_.DisplayName -match 'NVIDIA|AMD|Radeon|GeForce|Afterburner|Rivatuner|Overlay' } | Select-Object DisplayName,DisplayVersion | Sort-Object DisplayName | Format-Table -AutoSize"
AMD Software 24.1.1
MSI Afterburner 4.6.5
RivaTuner Statistics Server 7.3.5
Qué significa: Tienes herramientas instaladas que pueden engancharse/superponerse a la pila gráfica.
Decisión: No desinstales todo a ciegas. Pero si una instalación limpia del controlador sigue en bucle, elimina superposiciones y herramientas de monitorización a continuación.
Tarea 13: Comprobar integridad de archivos del sistema (porque los fallos pueden corromper cosas)
cr0x@server:~$ sfc /scannow
Beginning system scan. This process will take some time.
Windows Resource Protection found corrupt files and successfully repaired them.
Qué significa: Windows encontró archivos del sistema dañados y los reparó con éxito.
Decisión: Si SFC repara archivos, sigue con DISM; los controladores inestables pueden dejar el sistema operativo en un estado a medio romper.
Tarea 14: Reparar el almacén de componentes de Windows (DISM)
cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1
The restore operation completed successfully.
Qué significa: El almacén de componentes está sano otra vez.
Decisión: Si DISM falla repetidamente, podrías tener una corrupción más profunda del SO—arregla eso antes de culpar a la GPU.
Tarea 15: Comprobar si la GPU lanza errores WHEA PCIe (señal de hardware)
cr0x@server:~$ wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-WHEA-Logger'] and (EventID=17 or EventID=18)]]" /c:5 /f:text
Event[0]:
Provider Name: Microsoft-Windows-WHEA-Logger
Event ID: 17
Level: Warning
Description:
A corrected hardware error has occurred.
Qué significa: Los errores de hardware corregidos pueden correlacionar con inestabilidad PCIe, PSU marginal, cables riser o overclocks agresivos.
Decisión: Si los eventos WHEA se disparan durante los reinicios del controlador, considera quitar risers, volver a asentar la tarjeta, actualizar BIOS/chipset y reducir overclocks/undervolt.
Listas de verificación / plan paso a paso (DDU + Modo seguro)
Principios (las reglas que evitan rehacer trabajo)
- Controla el entorno: nada de instalaciones sorpresa de Windows Update durante la limpieza.
- Elimina controladores cuando no estén activos: el Modo seguro reduce bloqueos de archivos y servicios en ejecución.
- Reinicia en los momentos adecuados: no constantemente, ni nunca.
- Cambia una variable a la vez: no “también ajustar TdrDelay y undervolt” en la misma pasada.
Lista previa al vuelo (5 minutos, ahorra horas)
- Descarga el instalador correcto del controlador para tu GPU y SO de antemano. Colócalo en el escritorio. Irás sin conexión más tarde.
- Descarga DDU (Display Driver Uninstaller) con antelación y extrae a una carpeta conocida (p. ej.,
C:\Tools\DDU). - Anota tus ajustes de overclock o perfil de GPU (Afterburner/Adrenalin) y restablece a valores predeterminados si puedes. Si no puedes, no te asustes—aún podemos hacer la instalación limpia.
- Desconéctate de la red (desenchufa Ethernet, desactiva Wi‑Fi) o desactiva la búsqueda de controladores (Tarea 7). Haz ambas si Windows ha sido particularmente “servicial”.
- Crea un punto de restauración si el sistema es lo suficientemente estable. No porque los puntos de restauración sean perfectos, sino porque son un seguro barato.
Paso a paso: el flujo de instalación limpia que realmente funciona
-
Forzar Modo seguro para el siguiente arranque (si no puedes llegar de forma fiable a las Opciones avanzadas).
cr0x@server:~$ bcdedit /set {current} safeboot minimal The operation completed successfully.Decisión: Si esto falla con acceso denegado, tu shell no está elevado. Arregla eso primero.
-
Reinicia en Modo seguro.
En Modo seguro, el sistema debería usar un controlador básico y ser menos propenso a fallos. Si el Modo seguro también falla, desplaza tu sospecha hacia hardware o corrupción severa del SO.
-
Ejecuta DDU como Administrador y elige el tipo de dispositivo correcto (GPU) y el proveedor (NVIDIA o AMD).
Configuraciones que generalmente quieres: evitar descargas de controladores desde Windows Update (DDU puede establecer políticas). Esta es una de esas ocasiones en que una herramienta autoritaria es una ventaja.
Acción: “Clean and restart” es la elección normal. “Clean and shutdown” es útil si vas a intercambiar GPUs.
-
Después de que DDU reinicie, elimina la bandera de Modo seguro para que puedas arrancar normalmente.
cr0x@server:~$ bcdedit /deletevalue {current} safeboot The operation completed successfully.Decisión: Si olvidas esto, seguirás arrancando en Modo seguro y diagnosticarás mal “el controlador no se instaló”. Se instaló; simplemente estás en Modo seguro.
-
Permanecer fuera de línea y arrancar en modo normal.
En este punto, Windows debería estar usando Microsoft Basic Display Adapter. La resolución puede ser incorrecta. Está bien. La estabilidad es el objetivo.
Verifica:
cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Display | Select-Object -ExpandProperty FriendlyName" Microsoft Basic Display Adapter -
Instala el controlador que descargaste, no el que Windows quiera buscar.
- NVIDIA: considera “Driver only” si estás depurando, y omite GeForce Experience hasta que sea estable.
- AMD: elige una opción de “Factory Reset” solo si no usaste DDU (DDU ya hizo el trabajo pesado). Si usaste DDU, normalmente no necesitas ambos.
Decisión: Si el bucle de fallos vuelve durante la instalación, cancela y reinicia; luego prueba una versión conocida y buena diferente del controlador (a menudo una rama anterior). Aquí es donde “último” no es una virtud.
-
Reinicia una vez tras la instalación.
No apiles cambios adicionales todavía. Primero, confirma la estabilidad y la versión del controlador correcta:
cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_VideoController | Select-Object Name,DriverVersion | Format-Table -AutoSize" Name DriverVersion ---- ------------- NVIDIA GeForce RTX 3080 31.0.15.5161 -
Vuelve a habilitar la red y confirma que Windows no sobrescribe el controlador.
Espera unos minutos. Reinicia una vez más. Vuelve a comprobar la versión del controlador. Si cambió, tienes un problema de política de actualización de controladores (ver Errores comunes).
-
Sólo después de confirmar estabilidad: vuelve a añadir capas de software.
Superposiciones, monitorización, controladores RGB, herramientas de captura—vuelve a añadirlos uno por uno. Sí, es tedioso. Por eso funciona.
Broma #2 (corta, relevante): El Modo seguro es como un simulacro de incendio para tu PC—todo se ve peor, pero finalmente puedes ver quién está provocando el humo.
Tres mini-historias corporativas desde el terreno
Mini-historia 1: El incidente causado por una suposición equivocada
Un equipo de medios tenía un par de estaciones Windows de alto rendimiento para etalonaje de color y codificación acelerada por GPU. Una actualización de controladores se desplegó como parte del “parche rutinario”. A la mañana siguiente, una máquina empezó a parpadear a negro cada pocos segundos. El operador hizo lo que todos hacen: reinstaló el controlador más reciente otra vez, porque “quizá se corrompió”. Empeoró.
La suposición equivocada: el instalador es autoritativo. Asumieron que si el instalador terminó, el sistema estaba ejecutando esa versión. En realidad, Windows Update tenía un controlador de pantalla en su cola y seguía compitiendo con el instalador del proveedor. Tras cada reinicio, el sistema terminaba con una compilación de controlador distinta con componentes diferentes. El usuario lo experimentó como aleatoriedad. Operaciones lo vivió como un ticket de soporte que se reproducía solo cuando nadie miraba.
Recopilamos un conjunto corto de registros: ráfagas del Evento ID 4101 después del inicio de sesión, versión del controlador que cambiaba entre arranques y múltiples paquetes OEM INF en DriverStore para NVIDIA y una vieja AMD que se había usado seis meses antes. Nadie recordaba ese intercambio antiguo. La caja sí.
La solución no fue heroica: aislar la estación de la red, arrancar en Modo seguro, ejecutar DDU, quitar paquetes obsoletos, instalar un controlador de rama conocida y estable, y reintroducir la conectividad de red sólo tras confirmar que la versión del controlador permanecía. El bucle desapareció. El paso más valioso fue el menos glamuroso: impedir que Windows “ayudara”.
La lección del postmortem fue directa: no tienes una versión de controlador hasta que puedas probar que persiste tras un reinicio con Windows Update habilitado. Cualquier otra cosa son sensaciones.
Mini-historia 2: La optimización que salió mal
Un departamento financiero tenía gráficos acelerados por GPU en escritorios de trading. Alguien leyó que “desactivar TDR mejora el rendimiento” para tareas largas de cómputo GPU y decidió estandarizar un cambio de registro para aumentar el tiempo de espera de TDR. No fue malintencionado. Fue el clásico “haz que el error desaparezca ocultándolo”.
Funcionó exactamente una semana. Luego, un subconjunto de máquinas empezó a congelarse en lugar de recuperarse. Antes del cambio, un colgado de GPU desencadenaba un reinicio del controlador, la aplicación se cerraba y el usuario la volvía a abrir. Molesto, pero tolerable. Tras el cambio, el SO esperaba más tiempo antes de decidir que la GPU estaba colgada. Eso significó que todo el escritorio permanecía sin respuesta durante tramos más largos. La gente interpretó que “el PC está muerto” y lo apagaba—a menudo en medio de escrituras en disco.
El efecto secundario fue peor: los apagados forzados llevaron a reparaciones ocasionales del sistema de archivos al arrancar, corrupción de perfiles y una máquina que quedó atascada en un bucle de reparación automática. La “optimización” convirtió una falla recuperable a nivel de aplicación en un problema de fiabilidad del sistema.
Revertimos el ajuste de TDR, volvimos a los tiempos de espera por defecto y luego arreglamos la causa real: una versión específica del controlador + combinación de superposición que provocaba colgados durante cambios rápidos de modo multi-monitor. Las estaciones volvieron a un comportamiento predecible: si ocurría un colgado, se recuperaba rápido, se registraba claramente y no invitaba a los usuarios a desconectar la alimentación.
Lección: no afines mecanismos de detección de fallos hasta entender qué están detectando. TDR no es tu enemigo; es tu paracaídas.
Mini-historia 3: La práctica aburrida que salvó el día
Un equipo de ingeniería mantenía un laboratorio de máquinas Windows para validar compilaciones aceleradas por GPU. Nada glamuroso. Solo un conjunto de cajas que debían ser estables y repetibles. El equipo tenía un hábito que parecía burocrático: cada máquina tenía una “hoja base de controladores” que listaba modelo de GPU, rama del controlador, nombre exacto del archivo instalador y la fecha en que fue certificada para el laboratorio.
Una tarde, varias máquinas empezaron a mostrar reinicios de controladores después de una actualización acumulativa rutinaria de Windows. El pánico intentó aparecer. Pero la hoja base hizo todo aburrido. Compararon versiones de controladores, vieron que dos máquinas habían derivado a una compilación distinta y pronto identificaron que Windows Update había empujado un nuevo controlador de pantalla solo a esas dos.
La respuesta fue simple y rápida: aislar la red, Modo seguro, DDU, reinstalar el controlador base y aplicar una política para bloquear actualizaciones automáticas de controladores para esa clase de dispositivo. La “solución” llevó menos de una hora porque el equipo no debatía qué era “bueno”. Ya tenían un estado conocido y cómo volver a él.
Esta es la verdad poco sexy de la fiabilidad: una vía de reversión limpia vale más que mil ajustes ingeniosos. La hoja base no evitó el problema, pero evitó el thrash. En producción, eso es una victoria.
Errores comunes: síntoma → causa raíz → solución
1) Síntoma: el controlador se reinstala después de que lo desinstalas
Causa raíz: Windows Update y/o DriverStore contiene un paquete de controlador de pantalla que se aplica automáticamente al arrancar.
Solución: Desconéctate de la red; configura SearchOrderConfig a 0; usa DDU en Modo seguro; elimina paquetes obsoletos con pnputil. Verifica que la versión del controlador persista tras reiniciar con la red habilitada.
2) Síntoma: Modo seguro es estable, modo normal en bucle
Causa raíz: La pila del controlador del proveedor, ajustes o software que engancha (superposición/monitorización/RGB) provoca reinicios.
Solución: DDU en Modo seguro; instalación limpia del controlador; retrasar la instalación de superposiciones; probar estabilidad entre cambios.
3) Síntoma: pantalla negra tras la instalación, pero el sistema “está vivo” (RDP funciona)
Causa raíz: Problema con la ruta/modo de salida de pantalla (EDID multi-monitor, tasa de refresco, HDR, negociación de cable/puerto) o mala resolución por defecto al reiniciar.
Solución: Arranca en Modo seguro y elimina el controlador; arranca normal con Basic Display Adapter; reconecta un monitor en un puerto/cable conocido bueno; instala el controlador; luego añade los monitores de nuevo.
4) Síntoma: “nvlddmkm” o reinicios del controlador AMD sólo al lanzar juegos
Causa raíz: OC/UV inestable, estado de caché de shaders malo, conflicto de superposición o regresión del controlador con una ruta API específica.
Solución: restablece la GPU a stock; limpia cachés de shaders vía la UI del controlador; reinstala el controlador; desactiva superposiciones; si persiste, vuelve una rama de controlador hacia atrás.
5) Síntoma: parpadeo aleatorio + reinicios tras actualización de Windows, especialmente con varios monitores
Causa raíz: la actualización cambió el comportamiento del subsistema gráfico; interacciones HAGS/VRR/HDR; peculiaridades de firmware del monitor.
Solución: desactiva HAGS y VRR temporalmente; prueba con un solo monitor; reinstala un controlador estable; actualiza el firmware del monitor si procede.
6) Síntoma: el bucle persiste incluso después de DDU y reinstalación
Causa raíz: corrupción más profunda del SO, controladores de kernel en conflicto o inestabilidad real del hardware (PCIe, PSU, GPU).
Solución: ejecuta SFC/DISM; revisa eventos WHEA; vuelve a asentar la GPU; quita risers; prueba otra PSU/cables; ejecuta prueba de memoria; considera una instalación limpia del SO o RMA del hardware si aparecen artefactos en BIOS.
7) Síntoma: el sistema se reinicia o se apaga bajo carga de GPU
Causa raíz: problema de alimentación, manejo de transitorios de PSU, problema de cable/conector o protección térmica/VRM.
Solución: separa cables de alimentación PCIe (sin cadena para tarjetas de alta gama), verifica conectores asentados, reduce límite de potencia para probar, comprueba capacidad/calidad de la PSU, inspecciona temperaturas y hotspots.
8) Síntoma: usaste la opción “instalación limpia”, pero los problemas permanecen
Causa raíz: la “instalación limpia” del proveedor no es una eliminación completa; quedan restos en DriverStore/servicios/configuraciones.
Solución: Usa DDU en Modo seguro y controla Windows Update. Trata la “instalación limpia” del proveedor como conveniencia, no como herramienta de remediación.
Mentalidad operativa: por qué DDU + Modo seguro es el valor por defecto correcto
En términos SRE, un bucle de fallos de controlador es una dependencia que va y viene. El controlador de pantalla falla repetidamente, Windows lo recupera repetidamente y tu estación de trabajo queda en un estado de interrupción parcial. El instinto es “hacer algo” repetidamente—reinstalar, reiniciar, reinstalar otra vez—hasta que mágicamente se estabilice.
Esa aproximación falla porque el sistema no es determinista durante el bucle. Los archivos están bloqueados. Los servicios están a medio iniciar. Windows Update compite contigo. Las configuraciones están a medio aplicar. Es como intentar sustituir un disco mientras el controlador RAID sigue añadiendo el mismo miembro defectuoso desde un armario.
El Modo seguro reduce el número de componentes activos. DDU reduce el número de artefactos residuales. Combinados, crean una ventana de mantenimiento predecible donde realmente puedes hacer que el sistema converja a un estado conocido.
Detalles del flujo DDU que importan (y las partes que la gente se salta)
Estar sin conexión no es opcional (si has visto la “resurrección” del controlador)
Si Windows puede acceder a Windows Update, puede descargar un controlador en el momento exacto equivocado—entre tu desinstalación y tu reinstalación. Eso puede dejarte con componentes incompatibles: panel de control de una versión, núcleo del controlador de otra y controlador de audio de una tercera. Así obtienes cosas raras como audio HDMI que falta, o el panel de control que se niega a abrir, o el controlador que se reinicia al abrir la interfaz de configuración.
Guía práctica: desenchufa Ethernet. Desactiva Wi‑Fi. Luego haz el trabajo. Si estás en un entorno corporativo donde eso es difícil, utiliza una política para bloquear actualizaciones de controladores y valídala.
Elimina sólo lo que pretendes eliminar
DDU es potente. Igual que pnputil /delete-driver. Poder no es lo mismo que sabiduría.
- Si estás en NVIDIA, no vayas borrando controladores de chipset porque “también decía NVIDIA.” NVIDIA fabrica paquetes de chipset para algunas plataformas; borrar lo incorrecto puede romper almacenamiento o redes.
- Si estás en AMD, recuerda que AMD toca ecosistemas de GPU y chipset. Sé preciso sobre lo que eliminas.
El objetivo son los paquetes de controladores de pantalla y sus servicios/configuraciones—nada más. Estamos desinfectando la pila gráfica, no exorcizando el sistema.
Los reinicios son parte de la convergencia de estado
La gente o reinicia tras cada clic o evita reinicios como si costaran dinero. El número correcto es: reinicia cuando la herramienta de limpieza te diga que lo hagas, y reinicia una vez después de la instalación. Añade un reinicio más si estás validando “¿persiste el controlador tras arrancar con la red habilitada?” Eso es todo.
Mantén a mano un controlador conocido y bueno
“Último” es genial para características y parches de juegos. “Conocido y bueno” es genial para trabajo. Si estás depurando, prioriza estabilidad. Usa una versión de controlador que hayas usado antes sin problemas, o una que tu organización haya validado.
Preguntas frecuentes
1) ¿Realmente necesito DDU? ¿No puedo desinstalar desde Aplicaciones y características?
Si estás en un bucle de fallos, sí, realmente necesitas DDU más a menudo de lo que parece. Los desinstaladores de aplicaciones no eliminan de forma fiable paquetes de DriverStore, servicios y configuraciones de una forma que impida la re-aplicación. DDU en Modo seguro te da una línea base limpia.
2) ¿La casilla “Instalación limpia” de NVIDIA es suficiente?
No. Restaura algunas configuraciones y perfiles, pero no es lo mismo que eliminar paquetes de controladores y prevenir que Windows reinstale otra cosa. Úsalo como una función de conveniencia una vez que estés estable, no como tu herramienta principal de remediación.
3) ¿Debería instalar GeForce Experience / las herramientas de superposición de AMD mientras depuro?
No al principio. Estabiliza el controlador con los mínimos extras. Luego vuelve a añadir las herramientas de gestión si las necesitas. Cada superposición y grabador es otro gancho en la tubería gráfica.
4) ¿Qué pasa si el Modo seguro también entra en bucle?
Eso es una señal roja. Causas posibles: corrupción severa del SO, almacenamiento fallando o inestabilidad de hardware suficientemente grave como para que incluso las rutas de visualización básicas desencadenen problemas. Ejecuta SFC/DISM, comprueba registros WHEA y considera pruebas de hardware (volver a asentar la GPU, PSU/cableado, prueba de RAM).
5) ¿Necesito cambiar claves de registro TDR como TdrDelay?
Normalmente no. Los ajustes de TDR son el último recurso para cargas de trabajo específicas (p. ej., kernels largos de cómputo GPU) y pueden convertir colgados recuperables en bloqueos largos. Arregla la causa raíz primero: versión del controlador, superposiciones, alimentación/temperaturas o integridad del SO.
6) ¿Por qué el bucle ocurre justo después de iniciar sesión?
El inicio de sesión desencadena mucha actividad acelerada por GPU: composición DWM, aplicaciones de inicio, superposiciones, configuración multi-monitor, negociación HDR/VRR y cambios de estado de energía. Si el controlador es frágil, ese pico es donde se manifiesta.
7) Cambié de AMD a NVIDIA (o viceversa). ¿Es especial?
Sí. Los intercambios entre proveedores suelen dejar paquetes de controladores y servicios atrás. Windows también puede mantener paquetes antiguos en DriverStore. DDU más limpieza del DriverStore es el movimiento correcto, y “clean and shutdown” en DDU es útil si vas a cambiar la tarjeta físicamente.
8) ¿Cómo sé si Windows Update está sobrescribiendo mi controlador?
Comprueba tu versión de controlador (Tarea 1), reinicia con la red habilitada y comprueba otra vez. Si cambia sin que instales nada, Windows Update o la política de instalación de dispositivos lo está haciendo. Arregla eso antes de seguir probando versiones de controladores, o estarás midiendo caos.
9) ¿Un mal cable HDMI/DisplayPort puede causar algo que parezca un bucle de fallos del controlador?
Un cable defectuoso suele provocar parpadeos, pérdidas de señal o ausencia de señal—no eventos repetidos de reinicio del controlador. Pero problemas de negociación multi-monitor pueden parecer similares. Si los registros muestran reinicios TDR, es más que un cable; aun así, simplificar a un monitor en un cable conocido bueno es un buen paso de aislamiento.
10) ¿Debería reinstalar Windows por completo?
Sólo después de haber completado el flujo controlado con DDU y verificado que Windows no está reintroduciendo controladores. Si sigues en bucle con un controlador limpio, sin superposiciones y las comprobaciones de integridad del SO pasan, una instalación limpia del SO puede separar la podredumbre del software de la realidad del hardware.
Conclusión: próximos pasos que realmente funcionan
Si tu sistema está atascado en un bucle de controladores NVIDIA/AMD, deja de improvisar. La ruta fiable es:
- Prueba que es un bucle de reinicios del controlador (Evento ID 4101, salidas de DWM, Monitor de confiabilidad).
- Corta la reinfección de controladores (sin conexión + desactivar la búsqueda automática de controladores temporalmente).
- Arranca en Modo seguro y ejecuta DDU para eliminar la pila del proveedor de forma limpia.
- Arranca normal con Basic Display Adapter, instala un controlador conocido y bueno que ya descargaste, y reinicia una vez.
- Vuelve a habilitar la red y verifica que la versión del controlador persista tras reiniciar.
- Añade superposiciones/herramientas de ajuste una por una. Si vuelve la inestabilidad, acabas de encontrar al culpable.
Cuando lo haces así, el sistema converge. Cuando no lo haces, acabas “probando” diferentes versiones de controladores mientras Windows Update las cambia por debajo y una superposición se inyecta en cada llamada de la API gráfica. Eso no es solución de problemas; es arte performativo.
Si, tras una instalación limpia disciplinada, el bucle persiste—y especialmente si ves errores WHEA o artefactos en BIOS—trátalo como un problema de estabilidad de hardware. Vuelve a asentar la GPU, comprueba el cableado, prueba la PSU y reduce cualquier OC/UV. Los controladores pueden tener bugs. El hardware puede estar cansado. Tu trabajo es averiguar cuál te está mintiendo hoy.