«Este dispositivo no puede iniciarse (Código 10)»: pasos de reparación que realmente ayudan

¿Te fue útil?

El Código 10 es la forma que tiene Windows de encogerse de hombros mientras tu teclado, tarjeta de red, interfaz de audio, concentrador USB, controlador NVMe o cualquier dongle está ahí como un ladrillo.
El Administrador de dispositivos muestra Este dispositivo no puede iniciarse. (Código 10), y se supone que tienes que “actualizar el controlador” como si estuviéramos en 2009 y los controladores fueran polvo mágico.

En sistemas de producción no arreglamos fallos a base de intuiciones. Los arreglamos acotando el dominio del fallo: enlace hardware, firmware, energía, pila de controladores, políticas o una suposición errónea.
Esta es la guía práctica que le daría a un ingeniero de guardia que tiene cinco minutos antes de que un VP descubra que su portátil no tiene Wi‑Fi.

Qué significa realmente el Código 10 (y qué no)

El Código 10 no es un único error. Es una falla genérica de “el controlador del dispositivo arrancó… y el dispositivo no” durante el inicio. Eso puede ocurrir porque:
el dispositivo nunca se enumeró correctamente, el firmware está confundido, se vinculó el controlador incorrecto al ID de hardware, el controlador arrancó pero
se bloqueó durante la inicialización, o Windows aplicó una política/funcionalidad que rompió la ruta de arranque del dispositivo.

Piensa en el arranque de un dispositivo en Windows como una tubería: descubrimiento (PnP), emparejamiento (INF/driver store), instalación (copiar + registro),
inicio (carga del servicio) e inicialización funcional (llamadas específicas del dispositivo). El Código 10 suele lanzarse en el límite de “inicio/inicialización”.
Tu trabajo es encontrar qué cambió y qué capa está mintiendo.

Lugares comunes donde se esconde el Código 10

  • USB y docks: presupuesto de energía, suspensión selectiva, firmware del hub, o la ilusión de “funciona en mi puerto”.
  • Adaptadores de red: controladores filtro NDIS, clientes VPN, seguridad endpoint, o un controlador erróneo de Windows Update.
  • Controladoras de almacenamiento: Intel RST/VMD, controladores NVMe, controladores de chipset fuera de orden o cambios en la BIOS.
  • Bluetooth/interfases de audio: paquetes de controladores obsoletos, filtros de clase rotos o incompatibilidad de firmware/codec.

Una estrategia de reparación fiable parece aburrida: recopilar evidencia, identificar la instancia del dispositivo enumerado, leer los registros correctos y luego
o bien (1) corregir la vinculación del controlador, (2) eliminar un filtro en conflicto, (3) arreglar firmware/energía, o (4) aceptar que el hardware está fallando.

Una idea parafraseada de Werner Vogels (CTO de Amazon): Todo falla; diseña y opera como si la falla fuera el estado normal.
El Código 10 es la versión de escritorio de esa filosofía, excepto que falla justo antes de tu reunión.

Guion de diagnóstico rápido (primero/segundo/tercero)

Si solo tienes diez minutos, no “reinstales Windows”. Ni siquiera abras una página de descarga de controladores todavía.
Haz esto en orden para encontrar el cuello de botella rápidamente y evitar empeorar el incidente.

Primero: confirma el dominio del fallo (enumeración vs controlador vs política)

  1. ¿Se enumera el dispositivo? Si no aparece con un Hardware ID, estás en terreno de energía/puerto/cable/firmware.
  2. ¿Windows está vinculando el controlador esperado? Si vinculó un controlador genérico o de proveedor incorrecto, corrige la vinculación.
  3. ¿Un controlador filtro lo está bloqueando? VPN, EDR, filtro de almacenamiento, mejoras de audio: los filtros son el “algo más” que rompe el inicio.

Segundo: inspecciona los registros donde Windows confiesa

  1. Registros de SetupAPI para decisiones de emparejamiento/vinculación.
  2. Pestaña “Eventos” del Administrador de dispositivos para detalles de “Dispositivo no iniciado” y marcas temporales.
  3. Visor de eventos para fallos de carga de controladores/servicios, reinicios de hubs USB y eventos del kernel PnP.

Tercero: aplica el cambio más pequeño y reversible

  1. Reversión de controlador si el problema comenzó tras una actualización.
  2. Eliminar un paquete de controlador sospechoso usando las herramientas del driver store (no solo desinstalar desde el Administrador de dispositivos).
  3. Saneamiento de firmware / BIOS solo después de entender el estado actual: los cambios de firmware pueden arreglar o arruinar tu día.

Broma #1: Reiniciar no es una solución; es una confesión de que no tuviste tiempo para depurar.

Datos interesantes y contexto histórico

  • Códigos de error del Administrador de dispositivos datan de la era Windows NT/2000, cuando Plug and Play tuvo que volverse apto para empresas.
  • Los registros de SetupAPI han sido la fuente autorizada del “por qué Windows eligió este controlador” desde Windows 2000—mucho antes de que “telemetría” fuera una palabra de uso común.
  • La firma de controladores se volvió progresivamente más estricta; en Windows x64 fue un punto de inflexión que redujo el caos y aumentó los tickets de “¿por qué no carga mi controlador antiguo?”.
  • La entrega de controladores por Windows Update mejoró el despliegue para consumidores, pero creó un nuevo modo de fallo: el controlador equivocado y “útil” que llega a escala.
  • La suspensión selectiva USB existe para ahorrar energía, especialmente en portátiles, pero puede exponer cables, hubs y dispositivos marginales que no toleran transiciones agresivas de estados de energía.
  • Los controladores filtro NDIS (VPNs, firewalls, EDR) son potentes por diseño: pueden interceptar tráfico y también romper la inicialización del adaptador de maneras creativas.
  • Intel VMD/RST cambió cómo los dispositivos NVMe se presentan a Windows; alternarlo en BIOS puede hacer que un disco de arranque “desaparezca” hasta que exista el controlador correcto.
  • Las claves de registro de filtros de clase (UpperFilters/LowerFilters) son un punto de extensión histórico usado por proveedores; también son causa frecuente de Código 10 y Código 19 cuando quedan obsoletas.

Tareas probadas: comandos, salidas, decisiones

Las tareas siguientes están escritas para Windows, pero voy a aplicar disciplina de línea de comandos: capturar estado, cambiar una cosa, volver a comprobar.
Cada tarea incluye un comando realista, una salida representativa, qué significa y qué decisión tomar a continuación.

Tarea 1 — Identificar la instancia del dispositivo fallido (entidad PnP)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Status Error | Select-Object -First 5 Status,Class,FriendlyName,InstanceId | Format-Table -Auto"
Status Class        FriendlyName                         InstanceId
------ -----        ------------                         ----------
Error  Net          Intel(R) Ethernet Connection (7)...  PCI\VEN_8086&DEV_15F3&SUBSYS_...
Error  USB          USB Composite Device                 USB\VID_0BDA&PID_5411\00A0C6...

Qué significa: Ahora tienes el InstanceId, que es el ancla para todo: eventos, vinculación de controladores y estado del registro.

Decisión: Si el dispositivo no aparece en la lista, para. Estás en territorio de hardware/energía/BIOS—salta a las tareas de USB/energía y comprobaciones de firmware.

Tarea 2 — Extraer Hardware IDs (lo que usa el emparejamiento de controladores)

cr0x@server:~$ powershell -NoProfile -Command "$id=(Get-PnpDevice -Status Error | Select-Object -First 1).InstanceId; Get-PnpDeviceProperty -InstanceId $id -KeyName 'DEVPKEY_Device_HardwareIds' | Select-Object -ExpandProperty Data"
PCI\VEN_8086&DEV_15F3&SUBSYS_00008086&REV_03
PCI\VEN_8086&DEV_15F3&SUBSYS_00008086
PCI\VEN_8086&DEV_15F3&CC_020000

Qué significa: Los Hardware IDs son la verdad con la que Windows hace coincidir los INFs. Si estos parecen genéricos o incorrectos, puedes estar tratando con un modo distinto (por ejemplo, RAID/VMD).

Decisión: Usa estos IDs para verificar si el controlador instalado es el previsto, no solo “algo que carga”.

Tarea 3 — Comprobar qué controlador está realmente vinculado (y su INF)

cr0x@server:~$ powershell -NoProfile -Command "$id=(Get-PnpDevice -Status Error | Select-Object -First 1).InstanceId; Get-PnpDeviceProperty -InstanceId $id -KeyName 'DEVPKEY_Device_DriverInfPath' | Select-Object -ExpandProperty Data"
oem42.inf

Qué significa: El controlador está instalado desde un INF OEM en el driver store. Ese INF es lo que quizá necesites eliminar o reemplazar.

Decisión: Si este INF provino de Windows Update y el problema comenzó después del parche, planifica la reversión/eliminación y el bloqueo.

Tarea 4 — Inspeccionar detalles del paquete de controladores (proveedor, versión, fecha)

cr0x@server:~$ powershell -NoProfile -Command "pnputil /enum-drivers | Select-String -Context 0,6 'Published Name\s*:\s*oem42.inf'"
Published Name : oem42.inf
Original Name  : e1d68x64.inf
Provider Name  : Intel
Class Name     : Net
Class GUID     : {4d36e972-e325-11ce-bfc1-08002be10318}
Driver Version : 12/15/2024 2.1.4.0
Signer Name    : Microsoft Windows Hardware Compatibility Publisher

Qué significa: Ahora puedes correlacionar la versión del controlador con “cuándo se rompió”. Observa también el firmante—la firma WHCP no garantiza que sea adecuada para tu entorno.

Decisión: Si el proveedor es sorprendente (por ejemplo, un proveedor de docks que suministra el controlador NIC), trátalo como sospechoso y considera cambiar al controlador del proveedor del sistema OEM.

Tarea 5 — Leer detalles de “Dispositivo no iniciado” desde los eventos del Administrador de dispositivos vía PowerShell

cr0x@server:~$ powershell -NoProfile -Command "$id=(Get-PnpDevice -Status Error | Select-Object -First 1).InstanceId; Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Kernel-PnP/Configuration'; ID=411} -MaxEvents 20 | Where-Object {$_.Message -like \"*$id*\"} | Select-Object -First 1 TimeCreated,Message | Format-List"
TimeCreated : 2/4/2026 9:12:44 AM
Message     : Device PCI\VEN_8086&DEV_15F3&SUBSYS_00008086&REV_03\3&11583659&0&FE had a problem starting.
              Driver Name: oem42.inf
              Class Guid: {4d36e972-e325-11ce-bfc1-08002be10318}
              Service: e1dexpress
              Problem: 0x0
              Problem Status: 0xC00000E5

Qué significa: “Problem Status” te da un código estilo kernel. Eso suele ser más accionable que el propio Código 10.

Decisión: Si se identifica el servicio (aquí e1dexpress), comprueba si falla al iniciar, está bloqueado o colisiona con filtros.

Tarea 6 — Verificar que el servicio del controlador existe y esté en ejecución (o falle)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service -Name e1dexpress | Format-List Name,Status,StartType"
Name      : e1dexpress
Status    : Stopped
StartType : Manual

Qué significa: Muchos controladores son servicios kernel que no aparecerán “en ejecución” como un servidor web. “Stopped” no es necesariamente malo, pero es una pista.

Decisión: Si el tipo de inicio o el estado del servicio es extraño (deshabilitado, ausente), estás ante una instalación rota o una interferencia de una política/herramienta de seguridad.

Tarea 7 — Revisar SetupAPI para la decisión real de vinculación del controlador

cr0x@server:~$ powershell -NoProfile -Command "Select-String -Path $env:windir'\inf\setupapi.dev.log' -Pattern 'PCI\\VEN_8086&DEV_15F3','oem42.inf','!    dvi: Device not started' -SimpleMatch | Select-Object -Last 12"
>>>  [Device Install (DiInstallDevice) - PCI\VEN_8086&DEV_15F3&SUBSYS_00008086&REV_03]
>>>  Section start 2026/02/04 09:12:41.812
     dvi: Selected driver installs from section [E1DExpress.ndi.NTamd64.10.0] in "C:\WINDOWS\INF\oem42.inf".
     dvi: Driver Service Name: e1dexpress
!!!  dvi: Device not started: Device has problem: 0x0: 0xC00000E5
<<<  Section end 2026/02/04 09:12:45.120

Qué significa: SetupAPI te dice exactamente qué sección del INF se seleccionó y dónde falló el inicio. Aquí es donde la teoría de “Windows eligió el controlador equivocado” deja de ser teoría.

Decisión: Si SetupAPI muestra varios controladores candidatos, puede que necesites eliminar el equivocado del driver store para que Windows no lo pueda elegir de nuevo.

Tarea 8 — Listar dispositivos instalados en la misma clase (detectar duplicados/fantasmas)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Select-Object Status,FriendlyName,InstanceId | Format-Table -Auto"
Status Unknown  WAN Miniport (IP)                         ROOT\NET\0000
Status OK       Intel(R) Wi-Fi 6E AX211 160MHz            PCI\VEN_8086&DEV_51F0&SUBSYS_...
Status Error    Intel(R) Ethernet Connection (7)...       PCI\VEN_8086&DEV_15F3&SUBSYS_...

Qué significa: Puedes ver si solo un dispositivo falla o si toda la clase está rara (lo que apunta a filtros de clase o políticas).

Decisión: Si varios dispositivos de la misma clase fallan tras instalar una VPN/EDR, inspecciona los controladores filtro a continuación.

Tarea 9 — Comprobar controladores filtro NDIS (culpable común de Código 10 en NICs)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterBinding -Name '*' -ComponentID ms_tcpip,ms_lltdio,ms_rspndr,ms_pacer | Select-Object Name,ComponentID,Enabled | Format-Table -Auto"
Name                          ComponentID Enabled
----                          ----------- -------
Intel(R) Ethernet Connection  ms_tcpip    True
Intel(R) Ethernet Connection  ms_lltdio   True
Intel(R) Ethernet Connection  ms_rspndr   True
Intel(R) Ethernet Connection  ms_pacer    True

Qué significa: Esto muestra las vinculaciones estándar. Los filtros de terceros suelen aparecer con sus propios ComponentID.

Decisión: Si ves componentes de filtro inesperados (de VPN/EDR), desactívalos temporalmente (con el control de cambios adecuado) y vuelve a probar el inicio del dispositivo.

Tarea 10 — Enumerar problemas de controladora y hubs USB (para Código 10 en USB)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class USB | Where-Object {$_.Status -ne 'OK'} | Select-Object Status,FriendlyName,InstanceId | Format-Table -Auto"
Error USB Composite Device         USB\VID_0BDA&PID_5411\00A0C6...
Error Generic USB Hub              USB\VID_2109&PID_2817\5&2b3d...

Qué significa: Si hubs/controladoras fallan, el problema no es el dispositivo: es tu árbol USB.

Decisión: Mueve el dispositivo a otro puerto/controladora (frontal vs trasero, USB-C vs USB-A), o retira el dock/hub y prueba directamente.

Tarea 11 — Desactivar la suspensión selectiva USB (prueba dirigida, no una religión)

cr0x@server:~$ powercfg /SETACVALUEINDEX SCHEME_CURRENT SUB_USB USBSELECTIVE SUSPEND_DISABLED
Power Setting Index value set.

Qué significa: Has deshabilitado la suspensión selectiva para alimentación AC en el esquema de energía activo. Esto elimina toda una clase de comportamientos de inicialización/resumen inestables.

Decisión: Si esto arregla el Código 10 en dispositivos USB, probablemente tienes hardware/firmware marginal (dock, hub, cable) o firmware del dispositivo con bugs. Decide si mantener la configuración o reemplazar el eslabón débil.

Tarea 12 — Reconstruir la pila del controlador eliminando el paquete (la desinstalación real)

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

Driver package deleted successfully.

Qué significa: El paquete de controladores se elimina del driver store y los dispositivos que lo usan se desinstalan. Esto es más efectivo que “Desinstalar dispositivo” solo.

Decisión: Tras la eliminación, vuelve a explorar hardware e instala el controlador conocido bueno desde tu OEM o paquete aprobado por la empresa.

Tarea 13 — Forzar un reescaneo de hardware (re-enumeración PnP)

cr0x@server:~$ powershell -NoProfile -Command "pnputil /scan-devices"
Microsoft PnP Utility

Scanning for hardware changes...
Scan completed.

Qué significa: Windows vuelve a ejecutar detección y vinculación. Si ahora vincula un INF distinto, lo verás en SetupAPI.

Decisión: Si aún vincula el mismo INF problemático, te faltó otra copia (otro oem INF) o Windows lo re-descargó. Considera desactivar temporalmente las actualizaciones de controladores para esa clase mientras estabilizas.

Tarea 14 — Comprobar sorpresas en disco/controladora (Código 10 relacionado con almacenamiento)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class SCSIAdapter | Select-Object Status,FriendlyName,InstanceId | Format-Table -Auto"
OK    Intel(R) Volume Management Device NVMe RAID Controller   PCI\VEN_8086&DEV_9A0B&SUBSYS_...

Qué significa: Si esperabas una controladora NVMe sencilla pero ves VMD/RST, el modo de almacenamiento en BIOS importa. El Código 10 en almacenamiento suele aparecer tras resets de BIOS o cambios “de rendimiento”.

Decisión: No cambies el modo de almacenamiento en BIOS en un disco de arranque a la ligera. Asegura tener el controlador correcto instalado antes de cambiar modos, o intercambiarás Código 10 por “no hay arranque”.

Tarea 15 — Inspeccionar UpperFilters/LowerFilters (punto clásico de rotura)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}' /v UpperFilters"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}
    UpperFilters    REG_MULTI_SZ    edrNdisflt

Qué significa: Un filtro a nivel de clase está adjunto a todas las NICs. Si ese filtro está roto o parcialmente desinstalado, los adaptadores pueden fallar al iniciar (hola, Código 10).

Decisión: Si esto se correlaciona con la instalación o eliminación de un EDR/VPN, arregla la instalación del producto correctamente. No elimines filtros a menos que estés preparado para recuperar la conectividad (y tengas un plan de reversión).

Tarea 16 — Comprobar si Windows piensa que el dispositivo está presente pero “tiene un problema”

cr0x@server:~$ powershell -NoProfile -Command "$id=(Get-PnpDevice -Status Error | Select-Object -First 1).InstanceId; Get-PnpDeviceProperty -InstanceId $id -KeyName 'DEVPKEY_Device_ProblemCode','DEVPKEY_Device_ProblemStatus' | Format-Table KeyName,Data -Auto"
KeyName                     Data
-------                     ----
DEVPKEY_Device_ProblemCode  10
DEVPKEY_Device_ProblemStatus 3221225701

Qué significa: Puedes capturar los valores numéricos exactos que usa el SO, lo que ayuda a correlacionar entre registros e incidentes.

Decisión: Usa ProblemStatus para comparar entre máquinas—si muchas muestran el mismo estado tras la misma actualización, tienes una regresión de flota, no un portátil aislado.

Broma #2: Los docks USB-C son el equivalente empresarial de una dependencia sorpresa—no la desplegaste, pero definitivamente está en tu camino crítico.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El incidente causado por una suposición errónea

Una empresa mediana desplegó nuevos portátiles a un equipo de ventas. El primer día, varios abrieron tickets: el Ethernet en el dock mostraba Código 10.
El equipo supuso “docks defectuosos” porque las fallas estaban agrupadas en una oficina.

IT cambió docks. Mismo problema. Cambiaron cables Ethernet. Mismo problema. Reimaginizaron un portátil. Funcionó una hora y falló otra vez.
Mientras tanto, el Wi‑Fi de la oficina se saturó porque la mitad del equipo perdió acceso cableado a la vez.

La falla real fue la suposición de que la NIC del dock era “un problema del dock”. No lo era. Una actualización del cliente VPN había instalado un filtro NDIS.
En máquinas donde la NIC del dock se enumeraba antes que el Wi‑Fi al arrancar, el filtro se adjuntaba durante la inicialización del adaptador y a veces bloqueoaba la ruta de inicio.
El Código 10 fue el síntoma; el controlador filtro fue la causa raíz.

La solución fue brutalmente aburrida: revertir la versión del cliente VPN y luego desplegar una compilación corregida que no dejara entradas de filtro de registro obsoletas.
Los docks eran inocentes. La oficina era culpable solo de tener un orden de arranque consistente.

Micro-historia 2: La “optimización” que salió mal

Un equipo de ingeniería quería arranques más rápidos y mejor batería. Una guía interna bienintencionada recomendó ajustes de energía agresivos:
habilitar características de modern standby, mantener la suspensión selectiva USB activa y dejar que Windows gestione energía de dispositivos agresivamente.
La guía no estaba equivocada en abstracto. Estaba equivocada en lo específico.

Un subconjunto de usuarios dependía de una interfaz de audio USB para llamadas. Tras una actualización de Windows, esos dispositivos comenzaron a lanzar Código 10
después de reanudar. Volver a enchufar ayudaba a veces. Deshabilitar y volver a habilitar el dispositivo ayudaba a veces. El problema real era el tiempo intermitente del reanudo:
el firmware del dispositivo de audio no toleraba ser ciclado en energía mientras el hub también transitaba estados.

El equipo se empeñó: “Quizá los usuarios tienen cables malos.” Compraron cables nuevos. Compraron hubs nuevos. Compraron dispositivos nuevos.
La tasa de fallos cambió pero no desapareció, porque el comportamiento de reanudo era el desencadenante, no los accesorios.

La solución pragmática: desactivar la suspensión selectiva en las flotas afectadas (solo esas) y estandarizar en una revisión de firmware de dock que se comportara.
A largo plazo, actualizaron la guía para decir: las optimizaciones de energía son cambios de producción—pruébalas con periféricos reales, no solo con benchmarks.

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

Un departamento financiero ejecutaba una aplicación empresarial que dependía de un dongle de seguridad hardware. Un lunes, tras parchear, los dongles en varios escritorios
comenzaron a fallar con Código 10. Siguió el pánico, porque “vienen los auditores” es una fuerza de la naturaleza.

El equipo de escritorios tenía un hábito poco glamuroso: mantenían un pequeño catálogo interno de “paquetes de controladores conocidos buenos” y registraban qué nombres de INF OEM
se desplegaban para dispositivos críticos. También tenían una regla estricta: nunca confiar en Windows Update para esa clase de dispositivos; empaquetarlo en su herramienta de gestión.

Así, cuando apareció el Código 10, no adivinaron. Compararon los enlaces oem*.inf de las máquinas fallidas con el catálogo.
Como era de esperar, Windows Update había reemplazado el controlador del dongle con un paquete más nuevo que decía ser compatible pero cambió el comportamiento de inicialización.

Eliminaron el paquete nuevo del driver store, reinstalaron el conocido bueno y bloquearon esa actualización de controlador en la política de la flota.
Sin heroísmos. Sin reimágenes. Solo higiene disciplinada de controladores y registros—como gestión de cambios, pero para el arranque de dispositivos.

Errores comunes: síntomas → causa raíz → reparación

1) “Código 10 en dispositivo USB, pero funciona en otro PC”

  • Síntoma: El dispositivo falla en una máquina, funciona en otra; a veces funciona tras desenchufar y volver a enchufar.
  • Causa raíz: Caso límite de gestión de energía (suspensión selectiva), firmware de hub/dock inestable o puerto/controladora de esa máquina comportándose distinto.
  • Solución: Probar puerto directo (sin hub), deshabilitar suspensión selectiva como diagnóstico, actualizar firmware del dock y evitar puertos frontales en desktops si la carrera del cable es marginal.

2) “Código 10 tras Windows Update; el controlador dice que está actualizado”

  • Síntoma: Roto de repente después de parchear; el Administrador de dispositivos insiste en que no hay controlador más reciente.
  • Causa raíz: Windows Update entregó un controlador “más nuevo” que es peor para tu revisión de hardware/firmware.
  • Solución: Revertir, luego eliminar el oem*.inf ofensivo del driver store e instalar el paquete aprobado por el OEM. Considerar bloquear esa actualización.

3) “Adaptador de red Código 10 solo cuando hay VPN/EDR instalado”

  • Síntoma: El adaptador no inicia o desaparece; reinstalar el controlador NIC no ayuda.
  • Causa raíz: Conflicto de controlador filtro NDIS o entradas UpperFilters/LowerFilters obsoletas tras una desinstalación parcial.
  • Solución: Reparar o desinstalar/reinstalar correctamente el VPN/EDR. Si es necesario, eliminar entradas de filtro obsoletas con plan de reversión y acceso offline.

4) “Controladora de almacenamiento Código 10 tras actualización/reset de BIOS”

  • Síntoma: Controladora NVMe/RAID muestra Código 10; a veces Windows arranca pero el rendimiento de almacenamiento cae o los discos desaparecen.
  • Causa raíz: La BIOS cambió el modo VMD/RST, mapeo de líneas PCIe o reseteó a valores por defecto sin el stack de controladores correspondiente.
  • Solución: Restaurar el modo de almacenamiento anterior o instalar el controlador correcto antes de cambiar modos. Trátalo como una migración, no como un interruptor.

5) “Bluetooth Código 10 tras suspensión/hibernación”

  • Síntoma: El adaptador Bluetooth falla tras reanudar; un reinicio lo arregla temporalmente.
  • Causa raíz: Bug en la transición de estado de energía del firmware/controlador, a veces desencadenado por Fast Startup/hibernación.
  • Solución: Actualizar controladores Bluetooth y chipset, probar desactivar Fast Startup y comprobar si el adaptador está detrás de un hub USB interno con sus propios problemas.

6) “Dispositivo de audio Código 10 con mejoras (‘enhancements’) activadas”

  • Síntoma: Interfaz de audio externa falla; los altavoces internos funcionan.
  • Causa raíz: Capa de mejoras del proveedor o incompatibilidad de APO (audio processing object) tras una actualización.
  • Solución: Reinstalar el paquete de controladores correcto; desactivar mejoras como prueba; eliminar componentes de filtro de audio obsoletos si se identifican.

7) “Desinstalar dispositivo no ayudó”

  • Síntoma: Desinstalas en el Administrador de dispositivos, reinicias y vuelve en mal estado.
  • Causa raíz: El paquete de controladores permanece en el driver store, así que Windows vuelve a enlazar el mismo INF inmediatamente.
  • Solución: Usar pnputil /delete-driver oemXX.inf /uninstall para eliminar el paquete, luego reescanear e instalar el conocido bueno.

8) “El dispositivo muestra Código 10 y Código 43 en distintos arranques”

  • Síntoma: Los códigos de error varían; el comportamiento depende del tiempo de arranque/reanudado.
  • Causa raíz: Enlace de hardware marginal, inestabilidad de energía o condiciones de carrera de firmware (común con docks/hubs).
  • Solución: Eliminar intermediarios, actualizar firmware, desactivar transiciones de energía agresivas y reemplazar cables/hubs cuestionables.

Listas de verificación / plan paso a paso

Plan paso a paso para una máquina individual (edición “no lo empeores”)

  1. Registrar el estado: instance ID del dispositivo, Hardware IDs, INF del controlador, versión del controlador y la marca temporal cuando funcionó por última vez.
  2. Confirmar el alcance: ¿es un dispositivo, toda la clase (USB/Red) o varios dispositivos fallando simultáneamente?
  3. Revisar eventos: registros Kernel-PnP de configuración y eventos del Administrador de dispositivos para “Dispositivo no iniciado” más códigos de estado.
  4. Leer SetupAPI: encontrar la sección de instalación y por qué Windows eligió ese controlador.
  5. Intentar el cambio reversible más pequeño:
    • Reversión de controlador si se actualizó recientemente.
    • Deshabilitar suspensión selectiva (USB) como diagnóstico.
    • Eliminar componente filtro de terceros si está claramente implicado (preferir reparación/desinstalación del producto en lugar de cirugía del registro).
  6. Realizar el reinicio real del controlador: eliminar el paquete del driver store cuando sea necesario y luego reescanear.
  7. Instalar controladores conocidos buenos en el orden correcto: chipset primero, luego controladores de clase de controladora (almacenamiento/USB), luego controladores específicos del dispositivo.
  8. Solo entonces tocar firmware: actualizar BIOS/firmware de dock/dispositivo con notas de estabilidad de alimentación y reversión.
  9. Volver a probar arranque en frío y reanudo: algunos fallos de Código 10 solo aparecen tras suspensión/hibernación.

Lista de verificación para flotas (cuando Código 10 aparece “en todas partes”)

  1. Detener arreglos aleatorios: un ingeniero “arreglando” reinstalando controladores manualmente crea un problema de contaminación de datos.
  2. Elegir 3 máquinas de muestra: distintas revisiones de hardware si es posible, y una máquina control que no se vea afectada.
  3. Capturar diffs del driver store: identificar qué oem*.inf cambiaron y correlacionarlo con los anillos de actualización.
  4. Comprobar software de filtro compartido: VPN, EDR, DLP, suites de audio—cualquier cosa que se inserte en una pila.
  5. Desplegar una solución determinista: fijación de paquete de controladores, reparación de filtros o cambio de configuración de energía dirigido.
  6. Medir recurrencia: si “funciona en su mayoría”, trátalo como no resuelto. Los bugs Código 10 adoran la intermitencia.

Si debes hacer cambios a nivel de registro

A veces una entrada UpperFilters/LowerFilters rota te deja sin opciones. Si lo haces:
exporta primero la clave de clase relevante completa, asegúrate de tener acceso offline (administrador local, fuera de banda o modo seguro),
y sabe cómo restaurarás la conectividad si rompes la pila de red.

Preguntas frecuentes

1) ¿El Código 10 es siempre un problema de controlador?

No. A menudo es una falla de vinculación o inicialización del controlador, pero puede ser energía, firmware o un dispositivo que nunca se enumeró correctamente.
Si no hay un Hardware ID estable, deja de culpar controladores y empieza a revisar puertos, hubs, BIOS y estados de energía.

2) ¿Por qué “Actualizar controlador” en el Administrador de dispositivos suele no ayudar?

Porque normalmente busca lo que Windows ya conoce o lo que Windows Update ofrece, no lo que tu hardware realmente necesita.
Si el controlador equivocado ya está en el driver store, Windows puede elegirlo con confianza para siempre.

3) ¿Cuál es la diferencia entre “Desinstalar dispositivo” y eliminar el paquete de controladores?

Desinstalar el dispositivo elimina la instancia del dispositivo. Eliminar el paquete de controladores borra el INF y los binarios del driver store.
Si no eliminas el paquete, Windows puede reinstalar el mismo controlador problemático en el siguiente escaneo.

4) ¿Cómo sé si una VPN o EDR causó el Código 10 de mi NIC?

Busca componentes filtro NDIS, comprueba UpperFilters en el GUID de la clase de red y correlaciona la marca temporal del fallo con la instalación/actualización de ese software.
Si varios adaptadores fallan (Ethernet y Wi‑Fi), los filtros deberían estar al inicio de tu lista de sospechosos.

5) ¿Puede una actualización de BIOS causar Código 10?

Sí. Las actualizaciones de BIOS pueden resetear ajustes, cambiar modos de dispositivo o alterar el orden de enumeración. Los modos de almacenamiento (VMD/RST/AHCI) son especialmente sensibles.
Trata los cambios de BIOS como cambios de infraestructura: planifica, verifica y revierte si es necesario.

6) ¿Por qué el dispositivo funciona tras reiniciar pero falla después de suspensión?

Suspensión/reenmarcado ejercita estados de energía distintos al arranque en frío. Dispositivos y hubs que sobreviven al arranque pueden fallar en la inicialización al reanudar.
Prueba con suspensión selectiva desactivada y evalúa firmware y comportamiento de energía del dock/hub.

7) ¿El Código 10 indica que el hardware está muerto?

A veces. Si el dispositivo falla en varios puertos, en varias máquinas, y los registros muestran fallas repetidas de enumeración, el hardware es una posibilidad real.
Pero no lo declares muerto hasta que hayas eliminado vinculación de controladores, filtros y gestión de energía.

8) ¿Debería usar herramientas de “actualización de controladores” de terceros?

No. En términos empresariales, son ruleta de la cadena de suministro. Pueden instalar controladores no coincidentes, añadir filtros y crear nuevos modos de fallo.
Usa canales OEM o paquetes internos curados.

9) ¿Qué hago si el Código 10 está en una controladora de almacenamiento y la máquina no arranca?

No entres en pánico. Arranca desde medios de recuperación, confirma el modo de almacenamiento en BIOS y asegura que el controlador correcto esté disponible.
Toggles aleatorios pueden dejar el SO sin arrancar al cambiar la identidad de la controladora que Windows espera.

10) ¿Cuándo es razonable usar “Restaurar sistema”?

Cuando tienes evidencia sólida de que la rotura está ligada a una actualización reciente de controlador o software, y necesitas una reversión rápida.
No es elegante, pero puede ser una reversión controlada si capturas qué cambió después.

Conclusión: siguientes pasos que funcionan

El Código 10 es Windows diciéndote “el contrato de arranque fue violado”. El camino más rápido es dejar de adivinar e interrogar la pila:
enumera el dispositivo, confirma la vinculación del controlador, lee SetupAPI, comprueba filtros y luego haz un cambio reversible a la vez.

Pasos prácticos siguientes:

  1. En la próxima máquina con Código 10, captura InstanceId + Hardware IDs + Driver INF antes de hacer nada.
  2. Usa SetupAPI para confirmar qué eligió Windows y por qué.
  3. Si desinstalar no funciona, elimina el paquete real del controlador con pnputil.
  4. Si las fallas se correlacionan con VPN/EDR, trata los filtros como sospechosos de primera clase y arregla mediante la reparación del producto.
  5. Para rarezas de USB/dock, prueba la conexión directa, ajustes de energía y firmware—y luego reemplaza el eslabón más débil en lugar de discutir con él.

El objetivo no es “hacer que desaparezca”. El objetivo es hacer que la falla sea comprensible, reproducible y prevenible.
Así conviertes un simulacro de Código 10 en una tarea de mantenimiento rutinaria—silenciosa, documentada y un poco orgullosa.

← Anterior
Pantalla azul tras instalar un controlador: revertir desde modo de recuperación
Siguiente →
Seguridad en Proxmox: Tokens API bien hechos (para que la contraseña root deje de ser un arma)

Deja un comentario