Exportar controladores instalados a una carpeta (para que las reinstalaciones sean indoloras)

febrero 20, 2026 • febrero 20, 2026 • Lectura: 25 min • Views: 1

¿Te fue útil?

La fantasía de una reinstalación limpia es así: borrar, instalar, actualizar, listo. La realidad es más bien:
tu Wi‑Fi falta, el trackpad aparece como “un mouse” y el Administrador de dispositivos es una exposición de triángulos amarillos.
En algún punto, recuerdas que tu portátil solo se porta bien cuando se le dan los controladores correctos.

La solución no es un actualizador mágico de controladores. Es una exportación disciplinada de los controladores que ya sabes que funcionan,
almacenada en una carpeta que controlas, validada y lista para instalación sin conexión. Esto es higiene operativa básica.
También te hace parecer adulto en la sala cuando reconstruyes máquinas a escala.

Qué estás realmente exportando (y qué no)

En Windows moderno, “controladores” no son un montón suelto de DLLs esparcidas por C:\Windows.
La fuente canónica es el Driver Store bajo C:\Windows\System32\DriverStore\FileRepository.
Cuando se instala un dispositivo, Windows coloca un paquete de controlador en el Driver Store (INF + catálogo + binarios),
luego crea el enlace específico del dispositivo. Este staging es el concepto clave: si el paquete está staged,
normalmente puedes exportarlo.

Cuando la gente dice “exportar controladores instalados”, usualmente se refieren a “exportar paquetes staged
del Driver Store”. Esa es una buena noticia: es lo más parecido que tiene Windows a la caché de un gestor de paquetes.
También explica por qué una reinstalación puede ser indolora: estás trayendo paquetes conocidos y funcionales.

Lo que no estás exportando:

Firmware (BIOS/UEFI, firmware de SSD, NVM de Thunderbolt, firmware de docks). Eso es otro canal.
Paneles de control y aplicaciones del proveedor (suites de GPU, consolas de audio, tableros “optimizadores”).
Esas son aplicaciones. Algunas son útiles; muchas son confeti.
El comportamiento futuro de Windows Update. Exportar no impide que Windows luego “te ayude”.
Tokens de licencia para algunas herramientas propietarias relacionadas con controladores. Exportar paquetes INF no resolverá eso.

Si tu objetivo es “la máquina arranca con red, pantalla, almacenamiento y entrada funcionando”, exportar controladores es
justamente la jugada correcta. Si tu objetivo es “cada widget del OEM vuelve a la misma estética”, estás más cerca de
una tarea de imaging y empaquetado de aplicaciones. Es otro deporte.

Hechos interesantes y contexto histórico (para que las rarezas tengan sentido)

Windows XP popularizó la era del “CD de controladores” porque los controladores inbox eran escasos y el hardware cambiaba rápido.
Formó a una generación para acaparar instaladores como raciones.
Vista introdujo el modelo moderno del Driver Store para reducir la “ruleta de DLL” y hacer que las instalaciones de controladores fueran más transaccionales.
También hizo que el mantenimiento de controladores fuera menos un pasaje encantado.
WHQL y los catálogos (.cat) se convirtieron en la palanca de aplicación para la seguridad en modo kernel. Por eso los controladores no firmados son ahora casi siempre un dolor.
DISM creció de herramienta de despliegue a navaja suiza para mantenimiento offline, incluyendo controladores en imágenes de Windows fuera de línea.
Los “DCH drivers” (Declarative, Componentized, Hardware Support Apps) cambiaron cómo algunos proveedores envían pilas de gráficos/audio: más controlador, menos instaladores legacy.
La entrega de controladores por Windows Update se generalizó en la era de Windows 10, lo que redujo instalaciones manuales y aumentó las “sorpresas regresivas”.
El ranking de controladores es un algoritmo real (coincidencia, firma, fecha, versión). Windows no elige “el más nuevo”, elige “la mejor coincidencia” según reglas.
Los INF siguen siendo la verdad. Incluso con instaladores sofisticados, si no puedes razonar sobre el INF y sus hardware IDs, estás adivinando.

Guía rápida de diagnóstico: por qué tu exportación/restauración es lenta o falla

Al exportar controladores o restaurarlos tras una reinstalación, puedes perder horas en el lugar equivocado.
Aquí está el orden de triaje que realmente paga facturas.

Primero: confirma que estás exportando desde la fuente correcta (Driver Store) y tienes permisos suficientes

Si pnputil falla con errores de acceso, no estás elevado.
Si exportaste desde carpetas aleatorias del proveedor, exportaste sensaciones, no controladores.

Segundo: identifica la clase de controladores que falla (red/almacenamiento/pantalla) y prioriza el arranque

¿Sin red después de reinstalar? Necesitas los controladores NIC/Wi‑Fi primero, antes de “simplemente descargarlos”.
¿Falta el controlador del controlador de almacenamiento? Tu medio de instalación puede ni siquiera ver el disco. Eso es un problema pre-instalación.

Tercero: verifica la imposición de firmas y la incompatibilidad de arquitectura

Controladores legacy no firmados o cross-signed pueden stagearse pero no enlazarse, especialmente en builds recientes de Windows.
La incompatibilidad x86 vs x64 aún existe. Es menos común ahora, pero cuando ocurre es un bloqueo total.

Cuarto: encuentra el cuello de botella (IO, antivirus, longitud de ruta o volumen)

Las exportaciones pueden ser lentas si escribes a una memoria USB inestable o si un antivirus agresivo escanea cada archivo.
Los paquetes del Driver Store pueden ser numerosos. Si exportas desde un sistema antiguo, espera miles de archivos.

Quinto: decide si necesitas “todo” o “solo los dispositivos críticos”

Exportar todo es fácil. Restaurar todo puede causar conflictos si importas paquetes antiguos de GPU/audio.
Para flotas, prefiere una línea base curada más complementos por modelo.

Reglas de oro: qué hacer, qué evitar

Quieres dos resultados: (1) una carpeta que realmente contenga paquetes de controladores instalables, y (2) un proceso de restauración
determinista bajo presión. Las siguientes reglas separan “hice copia de seguridad de mis controladores” de “hice una carpeta llena de esperanza”.

Exporta desde el Driver Store usando herramientas soportadas. Usa pnputil y DISM.
No raspes System32 y lo llames día.
Mantén la exportación como solo lectura una vez creada. Cópiala, archívala, haz checksums. No la “limpies” borrando archivos que no reconoces.
Separa “controladores” de “software”. Si necesitas aplicaciones del proveedor, empaquétalas por separado.
Mezclarlas hace el troubleshooting miserable.
Registra los hardware IDs de los dispositivos críticos. Especialmente NIC y controlador de almacenamiento. Es tu mapa cuando Windows se hace el tonto.
Prefiere importaciones limpias. Tras reinstalar, stagea lo que necesitas, verifica y deja que Plug and Play enlace los dispositivos.
No trates las actualizaciones de controladores como actualizaciones de navegador. Más nuevo no siempre es mejor; “funciona con tu hardware y build de OS” es mejor.

Una verdad operativa más: las exportaciones de controladores son máquinas del tiempo. Las máquinas del tiempo son útiles, pero
también son la forma en que reintroduces bugs antiguos con confianza.

Tareas prácticas: comandos, salida esperada y qué decisiones tomar

Todos los comandos abajo asumen que estás en Windows, pero los bloques de consola están formateados como transcripciones de shell para legibilidad.
Ejecútalos en PowerShell o Símbolo del sistema elevados a menos que se indique otra cosa.

Tarea 1: Confirma la build y edición de Windows (importa para la política de controladores)

cr0x@server:~$ cmd /c ver
Microsoft Windows [Version 10.0.19045.4046]

Qué significa: El número de build influye en la imposición de firmas, disponibilidad de controladores inbox y expectativas del empaquetado del proveedor.
Decisión: Si te mueves entre versiones mayores (p. ej., 19045 a 22631), espera que algunos controladores legacy se nieguen a cargar.

Tarea 2: Comprueba si estás elevado (exportar requiere admin)

cr0x@server:~$ powershell -NoProfile -Command "[Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent().IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)"
True

Qué significa: True significa que puedes exportar desde el Driver Store e instalar paquetes.
Decisión: Si es False, detente. Vuelve a ejecutar la consola “Ejecutar como administrador”. No depures problemas de permisos fantasma.

Tarea 3: Exporta todos los drivers staged con pnputil (la herramienta de trabajo)

cr0x@server:~$ pnputil /export-driver * "D:\DriverExport\WIN10-19045"
Exporting driver package: oem42.inf
Driver package exported successfully.
Exporting driver package: oem43.inf
Driver package exported successfully.
...
Total driver packages: 186
Exported driver packages: 186

Qué significa: Exportaste paquetes actualmente staged en el Driver Store. Cada oemXX.inf corresponde a un paquete.
Decisión: Si la cuenta exportada es sospechosamente baja, puede que estés en una instalación fresca (pocos paquetes) o ejecutando sin elevación.

Tarea 4: Exporta drivers con DISM (útil para scripting y comprobaciones de paridad)

cr0x@server:~$ dism /online /export-driver /destination:"D:\DriverExport\WIN10-19045-DISM"
Deployment Image Servicing and Management tool
Version: 10.0.19041.3636

Exporting driver packages...
The operation completed successfully.

Qué significa: DISM exportó controladores desde el OS en ejecución (“online image”).
Decisión: Si DISM tiene éxito pero pnputil falla (o viceversa), aprendiste algo sobre políticas/permisos; conserva la exportación que funcionó.

Tarea 5: Verifica que la exportación tenga INFs y catálogos (no solo binarios)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Recurse D:\DriverExport\WIN10-19045 -Include *.inf,*.cat | Select-Object -First 5 | Format-Table -AutoSize Name,Directory"
Name        Directory
----        ---------
netrtwlane.inf D:\DriverExport\WIN10-19045\netrtwlane.inf_amd64_4f0c1c5a0a0c3b2d
netrtwlane.cat D:\DriverExport\WIN10-19045\netrtwlane.inf_amd64_4f0c1c5a0a0c3b2d
iaStorVD.inf D:\DriverExport\WIN10-19045\iastorvd.inf_amd64_2f7b4acb3e4a1c9b
iaStorVD.cat D:\DriverExport\WIN10-19045\iastorvd.inf_amd64_2f7b4acb3e4a1c9b
oemsetup.inf D:\DriverExport\WIN10-19045\oemsetup.inf_amd64_0d1a2b3c4e5f6a7b

Qué significa: Los paquetes de controladores están intactos: el INF describe la instalación, el CAT provee la firma, los binarios hacen el trabajo.
Decisión: Si ves pocos/ningún .cat, puede que tengas exportaciones incompletas o paquetes legacy; planea fricción por firmas.

Tarea 6: Obtén un inventario de paquetes de controladores (qué capturaste realmente)

cr0x@server:~$ pnputil /enum-drivers
Published Name : oem42.inf
Original Name  : netrtwlane.inf
Provider Name  : Realtek Semiconductor Corp.
Class Name     : Net
Class GUID     : {4d36e972-e325-11ce-bfc1-08002be10318}
Driver Version : 11/10/2023 10.66.1234.2023
Signer Name    : Microsoft Windows Hardware Compatibility Publisher

Published Name : oem43.inf
Original Name  : iaStorVD.inf
Provider Name  : Intel Corporation
Class Name     : SCSIAdapter
Driver Version : 09/15/2022 19.5.0.1037
Signer Name    : Microsoft Windows Hardware Compatibility Publisher

Qué significa: Esta es la lista autoritativa de paquetes staged y sus metadatos.
Decisión: Captura esta salida en un archivo junto a tu carpeta de exportación. Es tu herramienta de diff más adelante.

Tarea 7: Guarda la salida enum en un archivo con marca de tiempo (para probar qué cambió)

cr0x@server:~$ powershell -NoProfile -Command "pnputil /enum-drivers | Out-File -Encoding utf8 D:\DriverExport\WIN10-19045\driver-inventory.txt"

Qué significa: Ahora tienes un inventario en texto plano que puede compararse entre reinstalaciones o máquinas.
Decisión: Si haces esto en más de una máquina, estandariza nombres de archivo e incluye hostname/model.

Tarea 8: Identifica dispositivos críticos y sus hardware IDs (la lista de impacto de la restauración)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -PresentOnly | Where-Object {$_.Class -in 'Net','Display','System','HDC'} | Select-Object -First 10 Status,Class,FriendlyName,InstanceId | Format-Table -AutoSize"
Status Class  FriendlyName                          InstanceId
------ -----  ------------                          ----------
OK     Net    Intel(R) Ethernet Connection          PCI\VEN_8086&DEV_15F3&SUBSYS_...
OK     Net    Intel(R) Wi-Fi 6 AX201 160MHz         PCI\VEN_8086&DEV_06F0&SUBSYS_...
OK     Display NVIDIA GeForce RTX 3060 Laptop GPU   PCI\VEN_10DE&DEV_2520&SUBSYS_...
OK     HDC    Standard SATA AHCI Controller         PCI\VEN_8086&DEV_A352&SUBSYS_...

Qué significa: Estás recopilando los identificadores que Windows usa para emparejar INFs con dispositivos.
Decisión: Guarda estos IDs. Si una reinstalación pierde Wi‑Fi, sabrás exactamente qué paquete debería coincidir.

Chiste 1: Los controladores son como becarios: si no anotas lo que hicieron, pasarás el próximo trimestre redescubriéndolo.

Tarea 9: Detecta “dispositivos problemáticos” antes de la reinstalación (para no exportar fallos)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice | Where-Object {$_.Status -ne 'OK'} | Format-Table -AutoSize Status,Class,FriendlyName,InstanceId"
Status Class    FriendlyName                 InstanceId
Error  System   PCI Encryption/Decryption... PCI\VEN_1022&DEV_...

Qué significa: Ya tienes un estado de dispositivo roto. Exportar el Driver Store actual no necesariamente lo arreglará después.
Decisión: Investiga y remedia antes de “congelar” este sistema como tu baseline. De lo contrario estarás preservando una falla.

Tarea 10: Comprueba el estado de la firma en los archivos de catálogo exportados (sanidad, no perfección)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Recurse D:\DriverExport\WIN10-19045 -Filter *.cat | Select-Object -First 3 | ForEach-Object {Get-AuthenticodeSignature $_.FullName | Select-Object Status,SignerCertificate,Path} | Format-Table -AutoSize"
Status  SignerCertificate                                              Path
------  -----------------                                              ----
Valid   [Subject] CN=Microsoft Windows Hardware Compatibility Publisher D:\DriverExport\WIN10-19045\netrtwlane.inf_amd64_...\netrtwlane.cat
Valid   [Subject] CN=Microsoft Windows Hardware Compatibility Publisher D:\DriverExport\WIN10-19045\iaStorVD.inf_amd64_...\iaStorVD.cat
Valid   [Subject] CN=Microsoft Windows Hardware Compatibility Publisher D:\DriverExport\WIN10-19045\oemsetup.inf_amd64_...\oemsetup.cat

Qué significa: Un estado Valid es lo que quieres. NotSigned o UnknownError es una señal de alarma.
Decisión: Si paquetes críticos están sin firmar, planea fricción con Secure Boot / firma en modo kernel tras reinstalar.

Tarea 11: Crea un manifiesto de checksum para la carpeta de exportación (la integridad importa)

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Recurse D:\DriverExport\WIN10-19045 -File | Get-FileHash -Algorithm SHA256 | Export-Csv -NoTypeInformation D:\DriverExport\WIN10-19045\hashes-sha256.csv"

Qué significa: Más adelante puedes validar que la carpeta no se ha corrompido por un USB defectuoso o una sincronización “útil”.
Decisión: Si los hashes no coinciden el día de la restauración, no importes. Re-copia desde una fuente fiable.

Tarea 12: Restaurar controladores tras reinstalar: stagea todo desde la carpeta

cr0x@server:~$ pnputil /add-driver "D:\DriverExport\WIN10-19045\*.inf" /subdirs /install
Processing inf: D:\DriverExport\WIN10-19045\netrtwlane.inf_amd64_...\netrtwlane.inf
Driver package added successfully.
Driver package installed on matching devices.
Processing inf: D:\DriverExport\WIN10-19045\iaStorVD.inf_amd64_...\iaStorVD.inf
Driver package added successfully.
Driver package installed on matching devices.
...

Qué significa: /add-driver coloca paquetes en el nuevo Driver Store; /install dispara instalaciones en dispositivos coincidentes.
Decisión: Si quieres máximo control, omite /install, stagea primero y luego instala por clase de dispositivo.

Tarea 13: Si falta un dispositivo, fuerza un reescaneo y verifica el estado

cr0x@server:~$ pnputil /scan-devices
Scanning for hardware changes...
Done.

Qué significa: Plug and Play volvió a enumerar hardware. A veces eso es todo lo necesario tras stagear controladores.
Decisión: Si el dispositivo sigue desconocido, pasa a hardware IDs y selección directa del controlador.

Tarea 14: Encuentra dispositivos desconocidos rápidamente (triaje post-reinstalación)

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice | Where-Object {$_.Status -ne 'OK'} | Format-Table -AutoSize Status,Class,FriendlyName,Problem,InstanceId"
Status Class   FriendlyName   Problem InstanceId
------ -----   ------------   ------- ----------
Error  Unknown Unknown device 28      PCI\VEN_8086&DEV_XXXX&SUBSYS_...

Qué significa: El código de problema 28 suele ser “controladores no instalados”.
Decisión: Usa el hardware ID para localizar el INF correcto en tu exportación, o stagea paquetes faltantes del proveedor.

Tarea 15: Mapea un hardware ID a un INF en tu carpeta de exportación

cr0x@server:~$ powershell -NoProfile -Command "$id='PCI\VEN_8086&DEV_06F0'; Select-String -Path 'D:\DriverExport\WIN10-19045\*\*.inf' -Pattern $id -SimpleMatch | Select-Object -First 5"
D:\DriverExport\WIN10-19045\netwtw08.inf_amd64_...\netwtw08.inf:    %NIC.DeviceDesc% = Install, PCI\VEN_8086&DEV_06F0

Qué significa: Encontraste el paquete que declara soporte para ese device ID.
Decisión: Si no hay coincidencias, tu exportación no contiene el paquete correcto. Tendrás que obtenerlo en otro lugar (OEM, proveedor o Windows Update).

Tarea 16: Instala un INF específico (quirúrgico en lugar de bombardear)

cr0x@server:~$ pnputil /add-driver "D:\DriverExport\WIN10-19045\netwtw08.inf_amd64_...\netwtw08.inf" /install
Driver package added successfully.
Driver package installed on matching devices.

Qué significa: Instalaste un paquete dirigido. Este es el movimiento cuando sospechas conflictos o controladores GPU/audio obsoletos.
Decisión: Usa instalaciones dirigidas para pantalla/audio; usa instalaciones masivas para chipset/red en sistemas bare.

Tarea 17: Confirma que el nuevo sistema realmente vinculó la versión de controlador esperada

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Get-PnpDeviceProperty DEVPKEY_Device_DriverVersion | Select-Object -First 5 InstanceId,Data | Format-Table -AutoSize"
InstanceId                                   Data
----------                                   ----
PCI\VEN_8086&DEV_06F0&SUBSYS_...             22.250.1.2
PCI\VEN_8086&DEV_15F3&SUBSYS_...             12.19.2.45

Qué significa: Puedes demostrar qué versión está en uso, no solo qué paquetes están staged.
Decisión: Si Windows vinculó un controlador más antiguo o genérico, decide si lo aceptas (estabilidad) o lo fuerzas (funciones/rendimiento).

Tarea 18: Evitar que Windows Update reemplace inmediatamente tus controladores conocidos (entorno controlado)

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

Qué significa: Esta política desalienta la entrega de controladores vía quality updates. No es un escudo universal, pero reduce la rotación.
Decisión: Úsala en flotas gestionadas o durante troubleshooting. En máquinas personales, considera dejarla por defecto si dependes de WU para controladores.

Cita (idea parafraseada): la máxima de fiabilidad de Gene Kranz era básicamente “sé duro y competente”: sin excusas, verifica tus sistemas y mantente disciplinado.

Tres micro-historias corporativas desde las trincheras de los controladores

Micro-historia 1: El incidente causado por una suposición equivocada (la caída “es solo Wi‑Fi”)

Una empresa mediana desplegó una renovación de portátiles en varios departamentos. El equipo de despliegue tenía una imagen de Windows limpia,
un conjunto de apps y la alegre creencia de que “Windows encontrará los controladores”. Esa suposición funcionó en la oficina. Luego los portátiles se enviaron
al personal remoto.

El primer día, varios usuarios arrancaron y encontraron el escritorio sin el controlador de Wi‑Fi enlazado. Tampoco había puertos Ethernet—portátiles finos, pocas opciones.
La imagen no incluía el paquete inalámbrico específico para esa revisión de modelo. En la oficina, un dock con Ethernet enmascaró el problema; Plug and Play
instaló felizmente un NIC distinto y todos siguieron.

El playbook de helpdesk fue básicamente: “Conéctate a internet y ejecuta actualizaciones.” Es como decirle a una persona que se está ahogando que nade hacia el bote
que no trajiste. El incidente no fue dramático en métricas—no hubo servidores caídos—pero operacionalmente fue una caída en cámara lenta:
los usuarios no pudieron autenticarse al VPN, no pudieron descargar el controlador y no pudieron trabajar.

La solución fue dolorosamente simple: exportar controladores NIC conocidos de una máquina funcional, guardarlos en el recurso de despliegue y stagearlos durante el imaging.
La lección fue más aguda: no tratas los controladores de red como opcionales. Son dependencias de bootstrap.

Micro-historia 2: La optimización que salió mal (deduplicar exportaciones de controladores)

Otra organización quiso “optimizar” el almacenamiento de controladores. Tenían docenas de modelos de hardware y exportaron controladores de cada máquina de referencia,
generando un repositorio grande. Alguien propuso deduplicar borrando carpetas que “se veían duplicadas” y quedándose solo con la versión más nueva por proveedor.
Sonaba razonable en una hoja de cálculo.

En la práctica, el patrón de nombre del Driver Store (something.inf_amd64_hash) no es un detalle cosmético. Ese hash se correlaciona con el contenido exacto
del paquete y la firma del catálogo. Dos paquetes con el mismo proveedor y cadenas de versión similares pueden aún diferir en los hardware IDs soportados,
co-installeres o INFs de extensión.

El equipo “optimizó” el repositorio y más tarde descubrió que un modelo de portátil perdió los gestos del trackpad tras reimaginarse.
El dispositivo seguía funcionando como un mouse HID básico, por lo que el problema no se detectó en pruebas superficiales. Los usuarios lo notaron de inmediato,
porque las manos humanas son muy sensibles cuando sus dedos no hacen lo que esperan.

Habían eliminado un paquete más antiguo, específico del modelo, que contenía la coincidencia de hardware ID correcta. El paquete más nuevo “unificado” no cubría ese ID de subsistema exacto.
Reconstruir el repo desde cero llevó tiempo y, peor aún, erosionó la confianza en la tubería de despliegue.

La verdadera optimización no fue deduplicar por intuición; fue construir un manifiesto: modelo → hardware IDs críticos → paquetes de controladores validados.
El almacenamiento es más barato que tu semana de on-call.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día (inventario + hashes)

Un equipo que gestionaba un pequeño entorno VDI y endpoints tenía una política: cada paquete exportado debía incluir (1) un archivo de inventario de controladores,
(2) snapshots de hardware ID para red/almacenamiento/pantalla y (3) un manifiesto de checksums. Era tan aburrido que nadie lo presumía.

Durante una reconstrucción apresurada tras un incidente de seguridad, necesitaron reimaginar un conjunto de máquinas rápidamente manteniendo soporte de periféricos estable
(lectores de smartcard, adaptadores serial USB, equipo de audio nicho). Sacaron el bundle exportado de un recurso de red y comenzaron a stagearlo.
Varias instalaciones fallaron con errores extraños de lectura de archivos.

Porque tenían hashes, no perdieron tiempo culpando a DISM, Windows o rayos cósmicos. Validaron la exportación y encontraron corrupción en tránsito:
uno de los destinos de almacenamiento había perdido bits silenciosamente bajo carga. Los paquetes estaban incompletos, lo que explica por qué las instalaciones fallaban
de manera inconsistente y enloquecedora.

Restauraron el bundle desde una copia limpia, re-ejecutaron el staging y la reconstrucción continuó. Sin heroísmos, solo recibos.

Chiste 2: Una “copia de seguridad de controladores” sin verificación es como un paracaídas que empacaste durante una reunión—técnicamente posible, emocionalmente temerario.

Listas de verificación / plan paso a paso

Plan A: PC individual, solo quieres una reinstalación sin problemas

Prepara el almacenamiento: elige un destino con espacio suficiente y fiabilidad decente (un SSD externo vence a un USB al azar).
Crea un nombre de carpeta que incluya build del OS y modelo de la máquina.
Exporta controladores: ejecuta pnputil /export-driver * hacia la carpeta.
Captura inventario: guarda la salida de pnputil /enum-drivers en driver-inventory.txt.
Captura hardware IDs críticos: registra IDs de NIC y controladores de almacenamiento usando Get-PnpDevice.
Hashea la exportación: crea un manifiesto SHA256 en CSV.
Haz la exportación de solo lectura: cópiala a dos lugares si te importa (externo + NAS). No edites en sitio.
Después de reinstalar: stagea controladores desde la carpeta con pnputil /add-driver ... /subdirs.
Verifica el enlace: confirma versiones de controladores NIC y que el Administrador de dispositivos no muestre entradas “Unknown device”.

Plan B: Flota / imaging corporativo, donde el caos es una línea de presupuesto

Establece una máquina de referencia por modelo de hardware (o por familia si validaste compatibilidad de hardware IDs).
Exporta controladores e inventario con una convención de nombres estándar:
MODEL-OSBUILD-DATE (las fechas están bien en nombres de carpeta; evítalas en slugs y documentos de política).
Curar un “bootstrap pack”: NIC + almacenamiento + chipset + controladores USB. Este pack debe funcionar sin conexión.
Mantén un “pack riesgoso” separado: GPU, audio, cámara, pilas Bluetooth. Aquí se esconden conflictos y regresiones.
Fija y prueba versiones de controladores con un grupo piloto pequeño. No persigas “lo más reciente”, persigue “aburridamente estable”.
Hashea todo y valida en la importación. La degradación de bits y las herramientas de sincronización defectuosas son más comunes de lo que te gustaría.
Documenta el rollback: si un nuevo driver de GPU rompe monitores externos, debes conocer el paquete anterior conocido bueno.

Plan C: Antes de borrar, te das cuenta de que la máquina tiene hardware nicho

Exporta controladores inmediatamente (pnputil).
Identifica y captura en pantalla (o exporta) hardware IDs de dispositivos desconocidos/críticos.
Stagea la exportación en una segunda máquina para confirmar que contiene las coincidencias INF correctas (busca los IDs en los INFs).
Solo entonces borra.

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

1) Síntoma: La exportación “tiene éxito” pero la restauración no instala nada

Causa raíz: Stageaste controladores pero no disparaste la instalación, o los dispositivos aún no están enumerados.
Solución: Usa pnputil /add-driver ... /install, luego ejecuta pnputil /scan-devices. Verifica con Get-PnpDevice.

2) Síntoma: Tras restaurar, Wi‑Fi sigue faltando y no puedes descargar controladores

Causa raíz: La exportación no incluye el paquete correcto para ese hardware ID específico de NIC (común entre revisiones de modelo).
Solución: Extrae el hardware ID de la máquina rota, búsquelo en tus INFs exportados con Select-String.
Si no aparece, consigue el controlador correcto y agrégalo a tu repositorio para la próxima.

3) Síntoma: “El INF de terceros no contiene información de firma digital”

Causa raíz: Paquete no firmado, o archivo de catálogo faltante/inválido, o firma bloqueada por políticas/Secure Boot.
Solución: Prefiere paquetes firmados. Si el hardware legacy es realmente necesario, puede que requieras cambios controlados (test signing / política de Secure Boot),
pero trátalo como excepción con aprobación de riesgo.

4) Síntoma: La exportación tarda una eternidad, luz del disco encendida, ventiladores a tope

Causa raíz: Medio de destino lento, antivirus escaneando cada archivo, o un Driver Store hinchado en una máquina de larga vida.
Solución: Exporta primero a SSD local, luego copia al almacenamiento externo. Ajusta temporalmente la política AV si tu entorno lo permite.
Considera limpiar paquetes obsoletos (con cuidado) en el sistema origen antes de convertirlo en referencia.

5) Síntoma: Tras reinstalar, la pantalla funciona pero el rendimiento es pésimo (o fallan monitores externos)

Causa raíz: Windows vinculó un controlador de pantalla genérico o un paquete incorrecto del proveedor (común con gráficos híbridos).
Solución: Usa instalación dirigida del INF para el paquete GPU. Verifica la versión vinculada con DEVPKEY_Device_DriverVersion.
Mantén los controladores GPU en un “pack riesgoso” separado para poder revertir rápidamente.

6) Síntoma: El touchpad/teclado funciona “a medias” pero faltan gestos/teclas rápidas

Causa raíz: Los controladores de clase HID están presentes, pero el controlador de extensión o filtro específico del proveedor no fue staged/instalado.
Solución: Identifica el hardware ID del dispositivo e instala el paquete OEM correspondiente. No asumas que “es un mouse” es suficiente.

7) Síntoma: La restauración funciona, luego Windows Update “actualiza” controladores y las cosas regresan

Causa raíz: La entrega de controladores vía Windows Update sobreescribe tu paquete elegido según el ranking.
Solución: Usa políticas para excluir los controladores de WU durante la estabilización, o fija versiones con tu herramienta de gestión.
Decide si priorizas estabilidad o actualizaciones automáticas y luego aplícalo.

8) Síntoma: Exportaste controladores de una máquina “funcional”, pero otro modelo idéntico falla

Causa raíz: “Idéntico” no es idéntico: distinto proveedor de NIC, distinto subsystem ID, distinto modo de controlador de almacenamiento o cambios en la BIOS que alteran hardware IDs.
Solución: Captura hardware IDs por revisión de modelo. No confíes en nombres de marketing. Confía en IDs PCI y subsystem.

Preguntas frecuentes (FAQ)

1) ¿Debo usar pnputil o DISM para exportar controladores?

Usa pnputil /export-driver * como predeterminado. Es directo y mapea bien a cómo restauras con pnputil /add-driver.
DISM es excelente para imágenes offline y para entornos ya construidos alrededor de flujos DISM. Si dudas, exporta con ambos y compara conteos.

2) ¿Exportar controladores copia desde System32?

No como la gente asume. Las exportaciones correctas copian paquetes staged (INF/CAT/binarios) desde el Driver Store.
Esa es la unidad instalable. Archivos aleatorios en System32 suelen ser componentes compartidos y no suficientes para reinstalar.

3) ¿Puedo restaurar controladores sin internet?

Sí. Ese es el objetivo. Stagea desde tu carpeta de exportación usando pnputil /add-driver ... /subdirs.
En una instalación limpia, prioriza paquetes NIC y de almacenamiento para que el sistema quede autosuficiente rápido.

4) ¿Esto captura completamente los controladores GPU?

Captura los paquetes de controladores que están staged. No necesariamente captura la aplicación de control del proveedor,
servicios de telemetría o componentes “auxiliares” que se entregan como apps separadas. Si te importan, empaquétalas por separado.

5) ¿Es seguro importar todo desde la carpeta de exportación?

Usualmente sí—especialmente en la misma familia de modelo. Pero en sistemas de larga vida pueden acumularse múltiples versiones de GPU/audio.
Importar masivamente puede reintroducir paquetes antiguos que preferirías evitar. Para esas clases, prefiere instalaciones dirigidas.

6) ¿Por qué Windows a veces elige un controlador distinto al que stageé?

La selección de controladores se basa en ranking: calidad de coincidencia de hardware ID, firma, fecha/versión y otros factores.
El staging hace los paquetes disponibles; no fuerza la selección a menos que instales específicamente un paquete coincidente o uses pasos de gestión de dispositivos más contundentes.

7) ¿Cuánto espacio debo reservar para una exportación?

Varía mucho. Un portátil típico puede ser unos pocos gigabytes; una máquina actualizada por años puede ser más grande.
Si exportas a una unidad USB, deja margen—quedarte sin espacio a mitad de exportación es una tristeza especialmente evitable.

8) ¿Puedo exportar controladores desde una instalación de Windows offline (no arrancada)?

Sí, usando DISM contra una ruta de imagen offline, pero es más orientado a despliegue y necesitas conocer el directorio Windows montado.
Para la mayoría, exportar con el sistema en ejecución es más simple y menos propenso a errores.

9) ¿Necesito desactivar Secure Boot para restaurar controladores?

No para controladores debidamente firmados. Si tu restauración requiere controladores de modo kernel no firmados, estás en territorio de excepción.
La corrección suele ser “usar controladores firmados”, no “debilitar la cadena de arranque”.

10) ¿Cuál es la mejor forma de mantener esto manejable en el tiempo?

Trata las exportaciones como artefactos: versiona por build de OS y modelo de hardware, incluye inventarios y hashes, y no los mutes.
Cuando actualices un controlador, crea un nuevo bundle. Los bundles antiguos son tu paracaídas de rollback.

Conclusión: siguientes pasos que puedes hacer hoy

Si no haces nada más, haz esto: exporta tus controladores staged con pnputil, guarda un archivo de inventario y almacena el bundle en un lugar fiable.
Eso por sí solo convierte una reinstalación de “teatro improvisado” a “procedimiento repetible”.

Pasos prácticos:

Crea D:\DriverExport\YOURMODEL-OSBUILD y ejecuta la exportación.
Guarda driver-inventory.txt y un manifiesto SHA256 en la misma carpeta.
Registra hardware IDs de NIC y controladores de almacenamiento.
Tras reinstalar, stagea controladores desde esa carpeta y luego verifica qué se vinculó realmente.
Decide si permites que Windows Update cambie controladores durante la estabilización—and aplícalo.

Las reinstalaciones son inevitables. El pánico es opcional. Exporta los controladores mientras las cosas funcionan y el tú del futuro podrá dormir.