Windows sigue reinstalando controladores defectuosos: deténlo para siempre

febrero 6, 2026 • febrero 6, 2026 • Lectura: 25 min • Views: 0

¿Te fue útil?

No hay nada que diga “día productivo” como Windows reemplazando educadamente tu controlador estable por justo el que acaba de colapsar la pila gráfica, dejar sin Wi‑Fi o romper el controlador de almacenamiento. Haces retroceso, reinicias, respiras. Y luego vuelve. Como un boomerang con privilegios administrativos.

Esto no es misterioso. Son políticas, ordenación por prioridad, paquetes de controladores en el Driver Store y Windows Update haciendo lo que cree que es mejor—basado en reglas que puedes anular si estás dispuesto a ser específico y un poco terco.

Cómo Windows decide “ayudarte” (y por qué sigue reinstalando)

Windows no “instala un controlador” de forma mágica. Selecciona un paquete de controlador que coincida con tus identificadores de hardware, luego lo coloca en el Driver Store y lo asigna al dispositivo. La selección se basa en una ordenación por prioridad. La ordenación considera la especificidad de la coincidencia del hardware ID, la confianza de la firma, la fecha, la versión y, a veces, metadatos proporcionados por el proveedor. El sistema intenta converger en el “mejor” controlador, no en preservar tus sentimientos.

Cuando Windows sigue reinstalando un controlador defectuoso, casi nunca es una sola causa. Normalmente es uno de estos patrones:

Windows Update está entregando un controlador y tiene una prioridad mayor que el que prefieres.
El paquete defectuoso permanece en el Driver Store por lo que Plug and Play puede volver a vincularlo durante reexaminaciones o reenumeraciones del dispositivo.
Utilidades OEM (Lenovo Vantage, Dell Command Update, HP Support Assistant, suites GPU del proveedor) “ayudan” en su propio horario.
MDM/Intune/WSUS está aprobando o aplicando controladores de forma centralizada.
Actualizaciones de características u operaciones de reparación vuelven a colocar controladores “inbox” o “mejor priorizados”.

La solución no es “hacer rollback otra vez”. La solución es: identificar la ruta de entrega, eliminar o degradar el paquete que odias y aplicar una política que impida que vuelva.

Una cita de operaciones que debería estar en una nota adhesiva cerca del monitor (idea parafraseada): “La esperanza no es una estrategia.” — a menudo atribuida a círculos de liderazgo de ingeniería; parafraseada

Guía rápida de diagnóstico

Cuando estás de guardia (por ti o por una flota) no empiezas por la filosofía. Empiezas por “¿qué cambió, qué se instaló, cuál es la fuente, qué paquete?”. Aquí está la vía rápida que encuentra el cuello de botella rápidamente.

Primero: confirma qué controlador está activo ahora

Administrador de dispositivos → dispositivo → Propiedades → pestaña Controlador (versión, proveedor, fecha).
Luego verifica en la CLI (porque las interfaces gráficas mienten por omisión): usa pnputil y dism (ver tareas más abajo).

Segundo: identifica el canal de entrega

¿Se instaló mediante Windows Update? Revisa el historial de Windows Update y los registros del Visor de eventos (SetupAPI, WindowsUpdateClient).
¿Se instaló por un agente OEM? Revisa programas instalados/servicios/tareas programadas.
¿Empresa? Revisa la Política de Grupo / políticas MDM y si los controladores vienen de WSUS/Microsoft Update.

Tercero: decide tu nivel de contención

Equipo de trabajo / dispositivo único: ocultar la actualización específica + eliminar el paquete del Driver Store + detener las actualizaciones automáticas de controladores.
Pequeña oficina: Política de Grupo para bloquear actualizaciones de controladores, o restricciones de instalación de dispositivos por hardware ID.
Empresa: dejar de aprobar controladores en WSUS, bloquear la política en Intune y usar un anillo controlado de distribución de controladores con paquetes conocidos y validados.

Cuarto: valida que se mantenga fijo tras reenumeración

Reiniciar.
Deshabilitar/habilitar el dispositivo.
Buscar cambios de hardware.
Revisar el Driver Store otra vez. Si el paquete defectuoso sigue presente y bien ordenado, volverá.

Datos interesantes y contexto histórico

Un poco de contexto ayuda porque el comportamiento de los controladores es el resultado de décadas de “enviar hardware a escala sin incendiar el servicio de soporte”. Algunos puntos concretos:

Driver Store de Windows se volvió central en la era de Vista, permitiendo el almacenamiento previo de controladores y una restauración más sencilla, pero también convirtiendo “eliminar el controlador” en un problema de dos pasos (dispositivo vs paquete).
La ordenación de Plug and Play no es aleatoria: un hardware ID más específico puede vencer a una versión más nueva, dependiendo de la segmentación del INF y los cálculos de prioridad.
Firma WHQL (y más tarde la firma de atestación) aumentó masivamente la confianza en los controladores a escala, pero también dio a Windows Update la confianza para empujar controladores ampliamente.
Windows Update comenzó a distribuir más controladores agresivamente en la era de Windows 10, buscando reducir estados de “dispositivo desconocido” y mejorar la experiencia fuera de la caja.
Las actualizaciones de características actúan como actualizaciones en el lugar y pueden re-evaluar controladores, a veces prefiriendo controladores “inbox” conocidos para evitar fallos de actualización.
Los OEM pueden publicar controladores en Windows Update a través del canal de la ecosistema de hardware de Microsoft, por eso a veces aparece “Microsoft” como proveedor de silicon del fabricante.
El rollback de controlador típicamente restaura el controlador anterior para esa instancia de dispositivo, pero no necesariamente expulsa el paquete más nuevo del Driver Store.
Windows tiene políticas separadas para “actualizaciones de calidad” vs “actualizaciones de controladores”, y las empresas a menudo bloquean una pero accidentalmente permiten la otra.
Las restricciones de instalación de dispositivos por hardware ID existen desde hace años y siguen siendo una de las maneras más deterministas de bloquear que un controlador específico cambie.

Broma #1: Los controladores son como becarios con acceso root: por lo general funcionan hasta que descubren “optimización”.

Causas reales (no suposiciones)

1) El controlador defectuoso sigue en el Driver Store

Si el paquete permanece almacenado, Windows puede volver a vincularlo durante:

reenumeración de dispositivos (docking stations, NICs USB, reinicios de GPU)
“buscar cambios de hardware”
ciclos de detección de Windows Update
migración de actualizaciones de características

Eliminar el dispositivo desde el Administrador de dispositivos no es suficiente si marcaste “Eliminar el software de controlador para este dispositivo” y aún así no quitó el paquete (común cuando está en uso o cuando varios dispositivos usan el mismo paquete).

2) Windows Update tiene un controlador que te supera en prioridad

Windows elige según la mejor coincidencia. Si Microsoft Update ofrece un controlador con una coincidencia de hardware ID más ajustada o una mejor prioridad, puede ganar incluso si instalaste manualmente otro—especialmente si tu controlador preferido es un paquete genérico del proveedor y el ofrecido está específicamente dirigido a tu subsystem ID.

3) Estás luchando contra la fuente de actualización equivocada

Las empresas a menudo asumen que Windows Update es la única fuente. No lo es. Las herramientas OEM programan empujes de controladores. Las políticas MDM pueden imponer controladores. Las suites de gestión de endpoints pueden “parchear” controladores como si fueran Chrome. Si bloqueas Windows Update pero Dell Command Update sigue empujando, seguirás perdiendo.

4) Conflicto de políticas: “no incluir controladores” no se aplica donde crees

Hay múltiples palancas: Directiva de Grupo local, GPO de dominio, políticas CSP de MDM, aprobaciones en WSUS y anillos de Windows Update for Business. Si configuras una localmente pero la política de dominio la sobrescribe, tu cambio local es decorativo.

5) Actualización de características / in-place upgrade reinicia el tablero

Durante una actualización, Windows prioriza la capacidad de arranque y la compatibilidad. Los controladores de almacenamiento, chipset y pantalla pueden cambiarse a líneas base conocidas y estables. Si tu “conocido-bueno” es más nuevo pero no se considera seguro para la actualización, puede ser reemplazado. Después, Windows Update puede “mejorarlo” otra vez—con la misma versión defectuosa que evitabas.

Tareas prácticas: comandos, salidas, decisiones (12+)

Todas las tareas siguientes están diseñadas para ejecutarse en Windows. Las estoy presentando en un bloque estilo bash como se solicitó, pero los comandos son PowerShell/CMD que puedes ejecutar en un símbolo elevado salvo que se indique lo contrario.

Tarea 1: Identificar el controlador actualmente vinculado a un dispositivo (vista PnP)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -PresentOnly | ? {$_.FriendlyName -like '*Wi-Fi*'} | ft -AutoSize Status,Class,FriendlyName,InstanceId"
Status Class    FriendlyName                     InstanceId
------ -----    ------------                     ----------
OK     Net      Intel(R) Wi-Fi 6 AX201 160MHz    PCI\VEN_8086&DEV_06F0&SUBSYS_00748086&REV_00\3&11583659&0&A3

Qué significa: Tienes el Instance ID del dispositivo. Ese ID es tu ancla para todo lo demás.

Decisión: Si el dispositivo no está presente/OK, no estás depurando “reinstalación”, estás depurando detección o fallo de hardware.

Tarea 2: Obtener la versión/proveedor del controlador vinculado a ese dispositivo

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_PnPSignedDriver | ? {$_.DeviceID -like 'PCI\\VEN_8086&DEV_06F0*'} | select DeviceName,DriverVersion,DriverDate,DriverProviderName,InfName | fl"
DeviceName         : Intel(R) Wi-Fi 6 AX201 160MHz
DriverVersion      : 22.250.1.2
DriverDate         : 2024-03-18T00:00:00.0000000
DriverProviderName : Intel
InfName            : oem42.inf

Qué significa: La vinculación es a través de oem42.inf. Ahora tienes el nombre INF para atacar.

Decisión: Si el proveedor es “Microsoft” pero esperabas Intel/NVIDIA/AMD, puede ser un controlador reempaquetado por Windows Update.

Tarea 3: Listar paquetes del Driver Store y encontrar el INF culpable

cr0x@server:~$ pnputil /enum-drivers | findstr /i "oem42.inf Provider Class Version"
Published Name : oem42.inf
Driver Package Provider : Intel
Class : Net
Driver Version And Date : 22.250.1.2 03/18/2024

Qué significa: El paquete de controlador existe en el Driver Store como oem42.inf.

Decisión: Si varios INF OEM muestran versiones similares, puede que necesites eliminar varios paquetes en competencia para detener la re-vinculación.

Tarea 4: Ver si Windows Update instaló recientemente un controlador (historial de actualizaciones)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsUpdateLog -LogPath $env:TEMP\WindowsUpdate.log; Select-String -Path $env:TEMP\WindowsUpdate.log -Pattern 'Driver' -SimpleMatch | Select-Object -First 5"
2026/02/03 21:14:09.1234567  1234  5678  Agent  * Title = Intel - Net - 22.250.1.2
2026/02/03 21:14:09.1237890  1234  5678  Agent  * UpdateId = {GUID}
2026/02/03 21:14:09.1240000  1234  5678  Agent  * Revision = 201

Qué significa: Windows Update ofreció y probablemente instaló un controlador que coincide con el que ves vinculado.

Decisión: Si el historial muestra esto, bloquea/oculta esa actualización y detén las actualizaciones de controladores vía política. Si no lo muestra, revisa herramientas OEM y MDM.

Tarea 5: Revisar los registros de instalación de SetupAPI para ver quién hizo qué

cr0x@server:~$ powershell -NoProfile -Command "Select-String -Path $env:windir\inf\setupapi.dev.log -Pattern 'oem42.inf' | Select-Object -Last 8"
>>>  [Driver Install (UpdateDriverForPlugAndPlayDevices) - PCI\VEN_8086&DEV_06F0...]
>>>  Section start 2026/02/03 21:15:02.100
     inf:       Opened INF: 'C:\Windows\INF\oem42.inf' ([strings])
     dvi:       {DIF_SELECTBESTCOMPATDRV} 21:15:02.180
     dvi:       Selected driver installs from section [Install.NT]
     dvi:       {DIF_INSTALLDEVICE} 21:15:02.650
<<<  Section end 2026/02/03 21:15:06.900

Qué significa: El controlador se instaló vía una ruta de actualización PnP. Los registros de SetupAPI son lo más cercano que Windows tiene a una pista de auditoría para la vinculación de controladores.

Decisión: Si las marcas de tiempo se alinean con la actividad de Windows Update, céntrate en los controles de WU. Si coinciden con horarios de tareas OEM, desactiva el actualizador OEM.

Tarea 6: Deshabilitar descargas automáticas de controladores (el interruptor amigable)

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: 0x1 es “Sí, hacer esto automáticamente” en muchas compilaciones; 0x0 es “No”.

Decisión: En máquinas gestionadas, esto puede ser ignorado. Trátalo como un ajuste de conveniencia, no como una garantía.

Tarea 7: Aplicar “No incluir controladores con Windows Updates” (respaldo por política)

cr0x@server:~$ reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v ExcludeWUDriversInQualityUpdate
ERROR: The system was unable to find the specified registry value or key.

Qué significa: La política no está establecida (o está configurada en otro sitio vía MDM). Puedes establecerla vía GPO o registro (prefiere GPO/MDM en flotas).

Decisión: Si estás en un dominio, revisa el conjunto resultante de políticas antes de editar el registro local.

Tarea 8: Establecer el valor de política en el registro (prueba local, luego hazlo correctamente)

cr0x@server:~$ reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v ExcludeWUDriversInQualityUpdate /t REG_DWORD /d 1 /f
The operation completed successfully.

Qué significa: Esto instruye a Windows Update a no incluir actualizaciones de controladores en las actualizaciones de calidad.

Decisión: Si un controlador específico es crítico y dependes de WU para actualizarlo, no uses esto globalmente—usa bloqueo por controlador en su lugar.

Tarea 9: Eliminar el paquete defectuoso del Driver Store (la expulsión real)

cr0x@server:~$ pnputil /delete-driver oem42.inf /uninstall /force
Microsoft PnP Utility

Driver package deleted successfully.
Deleted driver package: oem42.inf

Qué significa: El paquete se ha ido, y Windows no puede volver a vincularlo a menos que se reintroduzca.

Decisión: Si la eliminación falla por “en uso”, desconecta el hardware dependiente, arranca en Modo Seguro o elimina dispositivos en competencia que usan ese INF.

Tarea 10: Confirmar que realmente desapareció

cr0x@server:~$ pnputil /enum-drivers | findstr /i "oem42.inf"

Qué significa: Sin salida significa que el INF no está presente en el Driver Store.

Decisión: Si aún aparece, no lo eliminaste. Detente y corrige eso antes de perseguir políticas.

Tarea 11: Instalar un controlador conocido-bueno y validar la vinculación

cr0x@server:~$ pnputil /add-driver "C:\Drivers\WiFi\Netwtw06.inf" /install
Microsoft PnP Utility

Driver package added successfully.
Published name: oem77.inf
Driver package installed on matching devices.

Qué significa: Has almacenado e instalado el controlador conocido-bueno; ahora es oem77.inf.

Decisión: Registra oem77.inf y la versión/fecha. Esto es lo que vas a defender.

Tarea 12: Bloquear actualizaciones de controladores para un dispositivo específico por hardware ID (determinista)

cr0x@server:~$ powershell -NoProfile -Command "$id='PCI\VEN_8086&DEV_06F0&SUBSYS_00748086'; $id"
PCI\VEN_8086&DEV_06F0&SUBSYS_00748086

Qué significa: Capturaste el hardware ID para usar en las Restricciones de Instalación de Dispositivos (GPO) para que Windows no pueda instalar controladores coincidentes salvo los ya presentes/permitidos.

Decisión: Si el dispositivo es crítico para arranque o almacenamiento, ten cuidado: bloquear instalaciones puede complicar la recuperación si luego necesitas un controlador de reemplazo.

Tarea 13: Comprobar qué GPOs se aplican realmente (porque “lo configuré” no es evidencia)

cr0x@server:~$ gpresult /r
COMPUTER SETTINGS
------------------
    Applied Group Policy Objects
    -----------------------------
        Workstation Baseline
        Windows Update Control

Qué significa: Puedes ver si un objeto de política que debería controlar controladores está aplicado.

Decisión: Si tu GPO esperado no aparece, tu arreglo está en Active Directory, no en el registro.

Tarea 14: Inspeccionar valores de política de Windows Update que suelen entrar en conflicto

cr0x@server:~$ reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
    ExcludeWUDriversInQualityUpdate    REG_DWORD    0x1
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
    UseWUServer    REG_DWORD    0x1

Qué significa: Los controladores están excluidos, y la máquina está apuntando a WSUS (UseWUServer=1).

Decisión: Si usas WSUS, corrige las aprobaciones allí; ocultar actualizaciones localmente no ayudará si WSUS sigue forzándolas.

Tarea 15: Listar controladores de terceros instalados vía DISM (útil en revisiones de incidentes)

cr0x@server:~$ dism /online /get-drivers /format:table | more
Published Name   Original Name  Inbox  Class Name  Provider Name  Date       Version
-------------   -------------  -----  ----------  -------------  ---------  -------------
oem77.inf       netwtw06.inf   No     Net         Intel          2023-11-10  22.220.0.4
oem13.inf       nv_dispi.inf   No     Display     NVIDIA         2024-01-05  551.23

Qué significa: Esto te da una vista amigable para flotas: qué es inbox vs tercero, proveedor, fecha, versión.

Decisión: Si ves un salto inesperado de proveedor/fecha después del Patch Tuesday, tienes un problema de deriva de controladores.

Tarea 16: Forzar un reescaneo y observar si el controlador defectuoso vuelve

cr0x@server:~$ pnputil /scan-devices
Microsoft PnP Utility

Scanning devices completed.

Qué significa: La máquina re-evaluó las coincidencias dispositivo-controlador. Esta es una forma segura de probar si tu bloqueo/expulsión se mantiene.

Decisión: Si el controlador defectuoso vuelve inmediatamente, tu bloqueo no está en su lugar o el paquete sigue almacenado en algún sitio.

Estrategias de bloqueo que realmente funcionan

Tienes tres niveles de control. Elige según el radio de impacto y cuánto confíes en tu futuro yo.

Nivel 1: Bloquear actualizaciones de controladores de forma amplia (rápido, contundente)

Usa ExcludeWUDriversInQualityUpdate vía GPO/MDM. Esto detiene que Windows Update empuje controladores como parte de las actualizaciones de calidad. No detiene instalaciones manuales, actualizadores OEM o el comportamiento de actualizaciones de características. Aún vale la pena en entornos donde la estabilidad de controladores supera la novedad.

Cuándo usar: flotas de oficina, endpoints VDI, kioscos, sistemas con stacks de hardware validados, estaciones de audio, dispositivos industriales.

Cuándo no usar: portátiles que dependen de correcciones frecuentes del proveedor (regresiones de Wi‑Fi/BT ocurren), o cuando no tienes un proceso alternativo de distribución de controladores.

Nivel 2: Ocultar/bloquear una actualización de controlador específica (quirúrgico, pero dependiente de la fuente)

Si un controlador en particular se ofrece a través de Windows Update, puedes ocultarlo para que WU no lo reinstale. En entornos de consumidor esto se hace a menudo con el solucionador “mostrar u ocultar actualizaciones”. En entornos gestionados, lo haces con aprobaciones de actualizaciones (WSUS) o controles de targeting de controladores (MDM). El punto es el mismo: detener la entrega en la fuente.

Trampa: Ocultar funciona hasta que la actualización se republica como una nueva revisión o paquete ligeramente diferente. Entonces es una “nueva” actualización y vuelves a estar en el bucle.

Nivel 3: Restricciones de instalación de dispositivos por hardware ID (más determinista)

Esta es la solución adulta cuando debes mantener un dispositivo en una versión de controlador específica. Bloqueas la instalación de controladores para dispositivos que coincidan con ciertos hardware IDs a menos que el controlador ya esté instalado, o permites explícitamente sólo ciertas clases.

En términos sencillos: creas un portero para los cambios de controlador de ese dispositivo.

Trampa: Si bloqueas demasiado en amplio (por ejemplo la clase “Display” en un entorno con muchas GPUs), eventualmente sabotearás actualizaciones y cambios de hardware.

Expulsar el paquete defectuoso del Driver Store (no negociable)

Si quieres “detenerlo para siempre”, elimina el paquete que Windows sigue seleccionando. De lo contrario dependes de la prioridad y del azar. Usa pnputil /delete-driver con /uninstall y /force cuando corresponda. Luego confirma que desapareció.

Además: si existen múltiples versiones, elimina las que no quieres. Windows puede y escogerá otra “mala” si todavía está en el store y tiene buena prioridad.

Trata con los actualizadores OEM (quieren ayudar; aún así rompen cosas)

En portátiles de clase empresarial, las herramientas OEM son culpables comunes. Empujan BIOS, firmware y controladores. Pueden ser útiles—hasta que pelean por tu estado deseado. Si administras una flota, decide quién es dueño de los controladores:

Si TI posee los controladores: elimina/desactiva los actualizadores OEM o configúralos para sólo notificar.
Si OEM posee los controladores: acepta la deriva y construye monitoreo más automatización de rollback.

Broma #2: Windows Update es el compañero de trabajo más confiado del mundo—siempre “arreglando” lo único que finalmente dejaste estable.

Tres mini-historias corporativas desde el terreno

Mini-historia 1: El incidente causado por una suposición equivocada

Manejaban una flota híbrida: estaciones de trabajo de ingeniería en la oficina, portátiles remotos por VPN y unas máquinas de laboratorio compartidas con hardware de medición caro. Alguien notó un controlador inestable de adaptador USB-a-Ethernet en un subconjunto de portátiles—desconexiones aleatorias, especialmente tras dormir.

La suposición era limpia y errónea: “Es Windows Update empujando un controlador malo.” Así que bloquearon controladores de forma amplia vía política, se felicitaron y siguieron.

Dos semanas después las máquinas del laboratorio empezaron a desconectarse de la red durante pruebas de larga duración. No eran portátiles. No eran remotos. Sólo el laboratorio. El proveedor culpó al cableado. El equipo de red culpó al spanning tree. El laboratorio culpó a todos.

La causa raíz resultó ser una utilidad OEM ejecutándose como SYSTEM en la imagen del laboratorio. Se había configurado meses antes para “aplicar automáticamente actualizaciones recomendadas”. No le importó la política de exclusión de controladores de Windows Update porque no usaba Windows Update. Descargó un controlador más nuevo directamente del catálogo OEM e instaló durante una ventana de mantenimiento.

Solución: eliminar el actualizador OEM de la imagen del laboratorio, mover BIOS/firmware a un proceso controlado mensual y usar restricciones de instalación de dispositivos para los hardware IDs específicos del NIC USB. La suposición equivocada no fue maliciosa; simplemente fue un modelado incompleto de amenazas. La entrega de controladores tiene múltiples bocas.

Mini-historia 2: La optimización que se volvió contra ellos

Un grupo de ingeniería de escritorio quería aprovisionamiento más rápido. Construyeron una “imagen dorada” con un Driver Store lleno: chipset, GPU, audio, NIC—todo pre-staged. La idea era válida: primer arranque, cero dispositivos faltantes, mínima fricción para el usuario.

Funcionó maravillosamente, hasta que no lo hizo. Un subconjunto de máquinas empezó a elegir un controlador de GPU más antiguo pero más específico que se había almacenado meses antes para un subsystem ID ligeramente diferente. Tenía buena prioridad, coincidía estrechamente y estaba ahí en el store como una trampa.

Los síntomas eran extraños: ciertas apps CAD se bloqueaban, pero sólo en ciertas revisiones hardware. Hacer rollback ayudaba por un día. Luego, tras un ciclo dock/undock o un escaneo de Windows Update, volvía el controlador antiguo. Su “optimización” creó un conjunto candidato mayor, incrementando la probabilidad de que Windows eligiera algo que no pretendían.

Solución: cambiaron el proceso de imagen para almacenar sólo los controladores requeridos para el SKU de ese modelo, no todo el universo del proveedor. También añadieron un paso de validación post‑provisión que enumeraba paquetes del Driver Store y eliminaba INFs conocidos malos. El aprovisionamiento se volvió un poco más lento. El tiempo medio hasta la cordura mejoró dramáticamente.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un departamento financiero ejecutaba escritorios Windows conectados a un sistema de escaneo de recibos antiguo pero crítico. El escáner dependía de una versión muy específica del controlador del controlador USB—las versiones más nuevas “funcionaban” pero producían corrupción intermitente difícil de detectar hasta las auditorías. A nadie le gustaba ese arreglo, lo que es señal de que era importante.

En lugar de jugar al whack-a-mole, el equipo de endpoints hizo tres cosas nada glamorosas. Primero, documentaron los hardware IDs exactos para el controlador y el escáner. Segundo, crearon un paquete baseline de controladores y lo almacenaron internamente con la tubería de imagen. Tercero, aplicaron restricciones de instalación de dispositivos para que el controlador no pudiera cambiar sin una ventana de cambio explícita.

Luego llegó una actualización de características de Windows a la organización. Predeciblemente, intentó modernizar controladores. En la mayoría de dispositivos eso fue correcto. En estos, no pudo reemplazar el controlador del dispositivo restringido, y los dispositivos siguieron funcionando con la versión aprobada.

No hubo incidente. No hubo correos ejecutivos preguntando “¿alguna novedad???” La práctica aburrida—reglas explícitas de permitir/bloquear y un paquete conocido-bueno—no los hizo populares, pero los hizo correctos. En operaciones, lo correcto gana.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “Hago rollback del controlador, pero vuelve después del reinicio”

Causa raíz: El paquete más nuevo/malo sigue en el Driver Store y tiene mayor prioridad. El rollback cambia la vinculación activa, no el conjunto de candidatos.

Solución: Elimina el INF malo del Driver Store con pnputil /delete-driver ... /uninstall. Luego instala el paquete conocido-bueno y valida con un reescaneo.

2) Síntoma: “Deshabilité actualizaciones de controladores, pero el controlador aún cambia”

Causa raíz: Un actualizador OEM o una política MDM está instalando el controlador fuera de Windows Update, o una actualización de características está intercambiando controladores.

Solución: Identifica la fuente vía registros de SetupAPI + tareas programadas/servicios. Elimina/desactiva el actualizador OEM o ajusta la política MDM/WSUS. Usa restricciones de instalación de dispositivos para control verdadero y persistente.

3) Síntoma: “Administrador de dispositivos dice una versión, pero el comportamiento coincide con la versión rota”

Causa raíz: Componentes múltiples: paquete de controlador vs firmware vs software acompañante; o el dispositivo realmente está usando otra instancia (por ejemplo NIC del dock vs NIC interna).

Solución: Confirma InstanceId y hardware IDs. Enumera Win32_PnPSignedDriver por DeviceID. Verifica cuál dispositivo falla mediante los registros de eventos.

4) Síntoma: “pnputil delete-driver falla: el controlador está en uso”

Causa raíz: El controlador está vinculado a un dispositivo activo, o otro dispositivo usa el mismo paquete.

Solución: Desinstala el/los dispositivo(s), desconecta hardware extraíble, reinicia o usa Modo Seguro. Luego ejecuta delete-driver otra vez. Confirma con pnputil /enum-drivers.

5) Síntoma: “Después de una actualización de características, los controladores volvieron a versiones antiguas”

Causa raíz: El proceso de compatibilidad de la actualización eligió controladores “seguros” para asegurar arranque y pantalla.

Solución: Re-aplica tu paquete conocido-bueno después de la actualización y aplica un límite de política si el sistema sigue derivando. Para flotas, incorpora esto en las secuencias de tareas post-upgrade.

6) Síntoma: “Sólo algunas máquinas se ven afectadas”

Causa raíz: Diferentes subsystem IDs, diferentes imágenes OEM o diferentes candidatos de controlador ya almacenados en el Driver Store.

Solución: Compara hardware IDs y contenido del Driver Store. No asumas que “mismo modelo” significa “mismos IDs”. A menudo no es así.

Listas de verificación / plan paso a paso

Máquina única: detener la hemorragia en 30 minutos

Identificar la instancia del dispositivo (Tarea 1) y el INF actual (Tarea 2).
Confirmar que el INF malo existe en el Driver Store (Tarea 3).
Comprobar si Windows Update lo entregó (Tarea 4) y confirmar vía SetupAPI (Tarea 5).
Expulsar el paquete malo con pnputil /delete-driver (Tarea 9), y luego confirmar (Tarea 10).
Instalar el controlador conocido-bueno (Tarea 11).
Deshabilitar la entrega de controladores vía Windows Update usando política (Tarea 8), al menos temporalmente.
Forzar un reescaneo (Tarea 16) y reiniciar. Volver a comprobar versión/proveedor del controlador.

Pequeña flota: estabilizar sin crear un nuevo problema

Elegir una versión conocida-buena y documentarla (proveedor, versión, INF, hardware IDs).
Detener actualizaciones de controladores vía política de Windows Update (GPO preferido). Validar con gpresult (Tarea 13).
Eliminar el controlador malo del Driver Store vía script (pnputil) durante ventanas de mantenimiento.
Desactivar actualizadores OEM o configurarlos en modo notificar sólo.
Añadir monitoreo: ejecutar periódicamente inventario de controladores con DISM (Tarea 15) y alertar desviaciones en proveedor/fecha/versión.

Empresa: hacerlo aburrido, repetible y auditable

Decidir responsabilidad: Windows Update vs OEM vs controladores empaquetados por TI. La propiedad mixta causa deriva.
Implementar anillos de controladores: grupo piloto primero, luego despliegue amplio tras validación.
Usar controles WSUS/MDM para prevenir despliegues de controladores no deseados. No confíes en ocultar en el endpoint.
Usar restricciones de instalación de dispositivos para periféricos críticos y dispositivos con problemas conocidos.
Construir un playbook de rollback que incluya la expulsión del Driver Store, no sólo el rollback de dispositivo.
Durante actualizaciones de características, programar un paso de remediación post‑upgrade para reaplicar controladores aprobados y eliminar los no permitidos.

Preguntas frecuentes

1) ¿Por qué Windows sigue reinstalando el mismo controlador defectuoso después de que lo revierto?

Porque el rollback cambia la vinculación activa, pero el paquete más nuevo a menudo permanece en el Driver Store y sigue teniendo la prioridad de “mejor” coincidencia. Expulsa el paquete con pnputil /delete-driver y bloquea la entrega.

2) ¿Es suficiente “No incluir controladores con Windows Updates”?

A veces. Bloquea la entrega de controladores vía actualizaciones de calidad, pero no detiene actualizadores OEM, pushes de MDM o cambios por actualizaciones de características. Si necesitas garantías, añade expulsión del Driver Store y restricciones de instalación de dispositivos.

3) ¿Eliminar el dispositivo en Administrador de dispositivos borra el controlador?

No de forma fiable. Puede desinstalar la instancia del dispositivo, pero el paquete del controlador puede quedarse staged. Usa pnputil /enum-drivers para confirmar si el INF sigue existiendo.

4) ¿Cuál es la diferencia entre “proveedor Microsoft” y “proveedor Intel/NVIDIA/AMD”?

“Microsoft” a menudo indica que el controlador se distribuyó por el canal de Microsoft (o es un controlador inbox). Aún puede ser código del proveedor. No infieras calidad solo por la cadena de proveedor—verifica versión, INF y origen.

5) ¿Puedo bloquear sólo una actualización de controlador y permitir las demás?

Sí, pero el mecanismo depende de tu entorno. En redes gestionadas, bloquéalo en WSUS/MDM mediante targeting. En un PC aislado, ocultar la actualización puede funcionar, pero revisiones republicadas pueden evadir ese ocultamiento.

6) ¿Es seguro forzar la eliminación de controladores con pnputil?

Puedes hacerlo si entiendes las dependencias. No elimines por la fuerza controladores críticos de almacenamiento, chipset o arranque a menos que tengas medios de recuperación y un plan probado de rollback. Para GPUs y NICs suele ser menos riesgoso, pero planifica tiempo de inactividad.

7) ¿Por qué sólo algunas máquinas obtienen el controlador malo?

Los hardware IDs difieren más de lo que la gente piensa—subsystem IDs, revisiones y personalizaciones OEM cambian la coincidencia y la prioridad. Además, distintas máquinas acumulan diferentes contenidos en el Driver Store con el tiempo.

8) ¿Cómo pruebo de dónde vino el controlador?

Correlaciona las marcas de tiempo de SetupAPI en C:\Windows\inf\setupapi.dev.log con los registros de Windows Update y con los horarios de los actualizadores OEM. No es atribución perfecta, pero suele ser suficiente para identificar al actor.

9) ¿Bloquear controladores daña la seguridad?

A veces. Los controladores pueden incluir correcciones de seguridad. El enfoque correcto es actualizaciones controladas de controladores: probar, aprobar, desplegar—en lugar de “nunca actualizar controladores”. La estabilidad y la seguridad pueden coexistir si ejecutas un proceso en lugar de confiar en la esperanza.

10) ¿Qué pasa con las actualizaciones de firmware que parecen controladores?

El firmware (especialmente para almacenamiento, docks y Thunderbolt) puede distribuirse como actualizaciones y cambiar el comportamiento como una regresión de controlador. Trata el firmware como parte de la pila: inventaría, controla y no permitas que tres herramientas lo actualicen independientemente.

Conclusión: próximos pasos prácticos

Si Windows sigue reinstalando un controlador defectuoso, deja de negociar con él. Haz tres cosas en orden:

Identificar la instancia del dispositivo, la versión actual del controlador y el nombre INF (Tareas 1–3).
Expulsar el paquete de controlador no deseado del Driver Store e instalar tu versión conocida-buena (Tareas 9–11).
Hacer cumplir el límite: bloquear la entrega de controladores vía política y/o bloquear el dispositivo con restricciones de instalación (Tareas 8, 12–14).

Luego prueba como un pesimista: reescanea dispositivos, reinicia, acopla/desacopla y ejecuta Windows Update. Si se mantiene estable después de eso, probablemente se mantendrá estable frente a las sorpresas de la próxima semana también.