Práctica 32: Drivers y diagnóstico de periféricos en máquinas virtuales

• Entender qué es un driver, por qué los necesita el sistema operativo y qué diferencia hay entre kernel mode y user mode.
• Reconocer y aplicar los tipos de instalación de drivers: paquete del fabricante (.exe/.msi), instalación desde archivo .inf, drivers genéricos de Windows Update.
• Saber qué significa un driver firmado digitalmente (WHQL), por qué es importante y qué implica usar uno sin firmar.
• Manejar con soltura el Administrador de dispositivos: identificar problemas, leer códigos de error, examinar detalles de driver, ver hardware IDs.
• Usar pnputil para gestionar el almacén de drivers de Windows desde línea de comandos.
• Hacer rollback de un driver problemático y forzar la reinstalación desde el almacén.
• Gestionar los módulos del kernel en Linux con lsmod, modinfo, modprobe y rmmod; entender la estructura de /lib/modules.
• Identificar hardware desconocido a partir de su Vendor ID / Device ID con lspci -nnk y lsusb -v.
• Aplicar una metodología de diagnóstico paso a paso, de lo barato y rápido a lo caro y lento.
• Diagnosticar fallos provocados por uno mismo en la VM y repararlos: driver desinstalado, dispositivo deshabilitado, driver con rollback necesario, módulo de kernel bloqueado, dispositivo desconocido en Windows.
• Consultar el Visor de eventos de Windows y dmesg / journalctl -k en Linux para correlacionar problemas con eventos del sistema.
• Documentar incidencias en una ficha técnica profesional trazable y reutilizable.

0.1 - Qué es un driver y por qué hace falta

Un driver (o controlador) es un pequeño programa que actúa de traductor entre el sistema operativo y un dispositivo concreto. El SO sabe hablar en términos genéricos ("escribe estos bytes en la impresora", "lee la posición del ratón"), pero cada modelo de impresora o ratón habla su propio dialecto: registros internos, formatos de paquetes, comandos específicos. El driver traduce la petición genérica al lenguaje específico del dispositivo.

Por eso, sin el driver adecuado, un periférico nuevo no funciona aunque esté conectado correctamente: el sistema lo ve, pero no sabe qué decirle.

0.2 - Kernel mode vs user mode

Un sistema operativo moderno separa la memoria y los privilegios en dos zonas:

Modo	Privilegios	Qué pasa si falla
Kernel mode (anillo 0)	Acceso total a hardware y memoria	Cuelga el sistema entero (BSOD en Windows, kernel panic en Linux)
User mode (anillo 3)	Acceso restringido, sólo a su propia memoria	Sólo se cae el programa, el SO sigue

Los drivers que tocan directamente el hardware (red, disco, GPU) corren en kernel mode porque necesitan acceso a registros físicos. Por eso un driver mal escrito o un driver corrupto puede tirar el sistema entero: a diferencia de una app normal, no hay red de seguridad. Los drivers más modernos de Windows (UMDF, User-Mode Driver Framework) intentan llevar parte del código a user mode para reducir el riesgo: un escáner que se cuelga ya no debería tirar Windows.

0.3 - Firma digital (WHQL)

Un driver firmado es un driver que Microsoft (o un certificado autorizado) ha "sellado" digitalmente. La firma garantiza dos cosas:

• Autenticidad: el driver viene de quien dice venir (Intel, NVIDIA, Logitech...). Nadie ha sustituido el .sys legítimo por uno modificado.
• Integridad: el binario no se ha alterado desde que se firmó (si alguien cambia un byte, la firma deja de cuadrar).

El sello WHQL (Windows Hardware Quality Labs) significa además que el driver ha pasado el laboratorio de pruebas de Microsoft. En Windows 64 bits, instalar un driver sin firmar requiere arrancar el sistema en un modo especial; en producción no se hace nunca.

0.4 - Tipos de paquetes de drivers en Windows

Tipo	Cómo se instala	Cuándo lo encontrarás
Setup .exe / .msi	Doble clic y siguiente-siguiente. Suele incluir software adicional (panel de control, suite del fabricante).	GPUs, impresoras multifunción, suites de marca
Paquete .inf + .sys + .cat	Clic derecho sobre el .inf → Instalar, o pnputil /add-driver.	Drivers genéricos, paquetes de actualización descargados manualmente
Driver genérico de Windows Update	Lo busca y lo instala automáticamente el SO al detectar el dispositivo.	Casi cualquier dispositivo nuevo arranca con esto
Driver embebido (inbox)	Ya viene incluido en la ISO de instalación de Windows.	Controladoras estándar (USB, SATA AHCI, teclado HID)

El .inf es un archivo de texto que describe el driver: a qué hardware se aplica (Vendor/Device IDs), qué archivos copiar y dónde, qué entradas de registro crear. El .sys es el binario que corre en el kernel. El .cat es el catálogo con la firma.

0.5 - El almacén de drivers (Driver Store)

Windows guarda una copia de cada driver instalado en C:\Windows\System32\DriverStore\FileRepository. Cuando un dispositivo se reconecta o se reinstala, Windows no necesita ir a buscar el driver a internet: lo saca del almacén. Por eso al desinstalar un dispositivo, Windows te ofrece dos opciones:

• Sin marcar "eliminar el software del controlador": el dispositivo se desinstala pero el driver queda en el almacén. Al reconectarlo, se reinstala solo desde ahí.
• Marcando la casilla: se borra también del almacén. La próxima vez Windows tiene que ir a Windows Update (o pedírtelo manualmente).

0.6 - Drivers en Linux: módulos del kernel

Linux no separa "el SO" del "driver" como Windows. En Linux los drivers son módulos del kernel (archivos .ko) que se cargan dinámicamente. Los módulos viven en /lib/modules/$(uname -r)/; la mayoría se carga automáticamente al detectar el hardware y muchos vienen ya compilados dentro del kernel.

Comando Linux	Qué hace	Equivalente Windows
lsmod	Lista los módulos cargados ahora mismo	(no hay equivalente directo)
modinfo <mod>	Información de un módulo: autor, descripción, parámetros, firma	Pestaña "Detalles" del driver en Admin. de dispositivos
modprobe <mod>	Carga un módulo (resolviendo dependencias)	Reinstalar driver
modprobe -r <mod> o rmmod	Descarga un módulo	Desinstalar driver del dispositivo
/etc/modprobe.d/*.conf	Configuración: blacklist, parámetros por defecto	Deshabilitar / configurar driver
dmesg / journalctl -k	Mensajes del kernel (incluyendo drivers)	Visor de eventos → Sistema

0.7 - Metodología de diagnóstico paso a paso

Cuando un periférico no funciona, sigue siempre estos pasos en este orden. La idea es ir de lo barato y rápido a lo caro y lento, y descartar causas obvias antes de tocar nada complicado:

El Administrador de dispositivos es la herramienta principal de diagnóstico de hardware en Windows. Cualquier técnico abre esta ventana antes que nada cuando le dicen "no me funciona X".

1.1 - Abrir y recorrer

Anota cuántos dispositivos hay en cada categoría. En una VM verás bastantes menos que en un PC real (no hay periféricos reales conectados), pero las categorías principales están presentes.

Categoría	Número de dispositivos
Adaptadores de pantalla
Adaptadores de red
Controladoras de almacenamiento
Controladoras USB (universal serial bus)
Dispositivos de sistema
Procesadores
Unidades de disco
Total aproximado

1.2 - Vista por conexión, recursos y dispositivos ocultos

En el menú Ver, prueba estas opciones:

• Dispositivos por conexión: reorganiza el árbol mostrando la jerarquía real de buses (CPU → PCI → USB → dispositivos). Muy útil para entender de qué bus cuelga cada cosa.
• Recursos por tipo: lista IRQs, rangos de memoria y puertos I/O. Antes era esencial (los conflictos de IRQ eran comunes); hoy PCI Express los asigna de forma dinámica y casi nunca hay conflictos.
• Mostrar dispositivos ocultos: revela dispositivos no presentes en este momento pero recordados por Windows (controladores fantasma). Útil para limpiar restos.

Cambia a "Dispositivos por conexión" y localiza tu adaptador de red. Anota de qué bus cuelga.

Bus del que cuelga el adaptador de red

1.3 - Examinar un driver al detalle

Proveedor del controlador
Fecha del controlador
Versión del controlador
¿Está firmado digitalmente? ¿Por quién?
Hardware Id (el primero de la lista)
Driver Inf path (nombre del .inf usado)

1.4 - Códigos de error que verás en el día a día

Cuando un dispositivo tiene un triángulo amarillo, en su pestaña General aparece un mensaje del tipo "Este dispositivo no puede iniciarse (Código 10)". Conviene tener identificados los códigos más frecuentes para ahorrarse búsquedas:

Código	Significado	Solución habitual
1	El dispositivo no está configurado correctamente	Reinstalar driver
10	No se puede iniciar	Actualizar / reinstalar driver, comprobar firmware
12	No hay recursos suficientes	Desinstalar otro dispositivo conflictivo
19	Registro dañado	Desinstalar y reinstalar el dispositivo
22	Dispositivo deshabilitado	Botón derecho → Habilitar
28	No hay controladores instalados	Instalar el driver del fabricante
39	Controlador dañado o no encontrado	Reinstalar driver desde el almacén
43	El dispositivo reporta problemas al SO (hardware o firmware)	Probar en otro equipo; si falla igual, está averiado
45	El hardware no está conectado en este momento	Normal si lo desconectaste; con "mostrar ocultos" salen estos
52	Driver sin firmar bloqueado	Firmar el driver o usar uno firmado

1.5 - El Visor de eventos como apoyo

El historial de la pestaña "Eventos" es un resumen. El detalle completo está en el Visor de eventos:

El Visor de eventos será tu mejor aliado cuando un dispositivo falle silenciosamente: muchas veces el triángulo amarillo no aparece, pero el evento sí.

Vas a aprender los cuatro mecanismos principales para gestionar drivers en Windows: por la GUI del Administrador, por pnputil en línea de comandos, mediante el rollback de Windows y mediante la instalación desde un .inf.

2.1 - Listar todo lo instalado con pnputil

pnputil es la herramienta oficial de Microsoft para gestionar el almacén de drivers desde línea de comandos. Está incluida en cualquier Windows desde 7. Es la forma "profesional" de tocar drivers, sobre todo en scripts y despliegues.

pnputil /enum-drivers

Verás una lista de los drivers de terceros en el almacén (cada uno con su "Nombre publicado" del tipo oem12.inf). Los drivers inbox de Microsoft no se listan aquí: pnputil sólo muestra los OEM. Si quieres ver todos los drivers (inbox incluidos), usa cualquiera de estas alternativas:

(1) DISM (CMD o PowerShell elevado; incluye drivers inbox con /all):

dism /online /get-drivers /all /format:table

(2) driverquery (CMD; lista todos los drivers cargados en kernel):

driverquery /v /fo table

(3) PowerShell (equivalente moderno de DISM, solo PowerShell):

Get-WindowsDriver -Online -All | Format-Table -AutoSize

Si lo que quieres es filtrar por clase de dispositivo con pnputil tienes que pasarle un GUID concreto, no un comodín. Por ejemplo, la clase "Adaptadores de red" tiene GUID {4d36e972-e325-11ce-bfc1-08002be10318}:

pnputil /enum-drivers /class "{4d36e972-e325-11ce-bfc1-08002be10318}"

pnputil /enum-devices /connected
pnputil /enum-devices /problem

El segundo (/problem) lista sólo los que tienen problema; idealmente devolverá lista vacía.

Número aproximado de drivers de terceros
Proveedores que aparecen en la lista
Resultado de /enum-devices /problem

2.2 - Actualizar un driver desde Windows Update

La primera opción que prueba Windows ante un dispositivo nuevo es buscar el driver en su catálogo online. Vamos a forzar una búsqueda:

2.3 - Instalar el driver del fabricante (la forma profesional)

El driver genérico de Windows suele bastar para que el dispositivo arranque, pero el driver del fabricante añade funciones (utilidades, perfiles, optimizaciones). En GPUs e impresoras la diferencia es enorme.

Hay dos vías para un paquete .inf:

• Vía GUI: clic derecho sobre el .inf → "Instalar".
• Vía línea de comandos (CMD o PowerShell elevado):

pnputil /add-driver C:\ruta\driver.inf /install

2.4 - Rollback de un driver

Si actualizas un driver y empieza a fallar todo, Windows guarda automáticamente el anterior. Para volver a él:

2.5 - Eliminar un driver del almacén

"Desinstalar dispositivo" desinstala el binding entre el dispositivo y su driver, pero el driver sigue en el almacén. Para borrarlo del almacén (necesario cuando quieres forzar que Windows baje uno nuevo, o si el driver está estropeado):

Flujo (en CMD o PowerShell elevado):

pnputil /enum-drivers
pnputil /delete-driver oem12.inf
pnputil /delete-driver oem12.inf /uninstall
pnputil /delete-driver oem12.inf /uninstall /force

• 1ª línea: localiza el "Published Name" (oemNN.inf) del driver que quieres borrar.
• 2ª línea: elimina ese driver del almacén.
• 3ª línea: además desinstala el dispositivo asociado.
• 4ª línea: forzado (úsalo con cuidado).

2.6 - Buscar cambios de hardware

Cuando desinstalas un dispositivo, el menú Acción → Buscar cambios de hardware obliga a Windows a re-escanear el bus y volver a detectarlo. Es equivalente a desconectar y reconectar el dispositivo físicamente.

2.7 - Política de firma de drivers

Windows 64 bits bloquea por defecto los drivers no firmados. Para ver tu política actual abre PowerShell como administrador:

Desde CMD:

bcdedit /enum {current} | findstr "nointegritychecks testsigning"

Desde PowerShell hay que entrecomillar {current} porque si no lo trata como un ScriptBlock vacío:

bcdedit /enum '{current}' | findstr "nointegritychecks testsigning"

Si las dos opciones están en No o no aparecen, estás en modo normal (sólo se aceptan drivers firmados). En desarrollo se puede arrancar en modo "Test Signing", pero no es algo que vayas a tocar en un equipo de producción.

En Linux la palabra "driver" se sustituye casi siempre por "módulo del kernel". El concepto es el mismo, pero el sistema de gestión es muy distinto al de Windows: no hay almacén ni Administrador de dispositivos, todo se hace con comandos y archivos de configuración.

3.1 - Ver los módulos cargados

lsmod | head -20
lsmod | wc -l               # número total de módulos cargados

Cada fila es un módulo: nombre, tamaño en bytes y used by (cuántos otros módulos o procesos lo están usando). Un módulo con un used by en cero se puede descargar; uno con valor mayor que cero está siendo usado por otros y no se puede quitar sin descargar primero los que dependen de él.

Número total de módulos cargados
Tres módulos cualesquiera de la lista

3.2 - Información detallada de un módulo

modinfo muestra todo lo que se sabe de un módulo: autor, descripción, licencia, versión, firma, alias (qué hardware reclama) y parámetros que admite.

modinfo e1000           # driver de muchas tarjetas de red Intel (incluida la de VirtualBox)
modinfo ext4            # driver del FS ext4
modinfo nvidia 2>/dev/null || echo "no instalado"   # NVIDIA, sólo si lo hubiera

Localiza en la salida de modinfo e1000 los campos filename, license, description, author, vermagic y los alias (los alias son los Vendor/Device IDs que reclama el driver).

3.3 - El directorio /lib/modules

Todos los módulos viven aquí, agrupados por versión de kernel:

uname -r                                    # versión actual del kernel
ls /lib/modules/                            # versiones de kernel instaladas
ls /lib/modules/$(uname -r)/kernel | head
find /lib/modules/$(uname -r) -name "e1000*"

Si tienes varios kernels instalados, cada uno tiene su carpeta. Por eso al actualizar el kernel a veces dejan de funcionar drivers de terceros: hay que recompilarlos para la nueva versión (eso es lo que hace DKMS, Dynamic Kernel Module Support).

3.4 - Cargar y descargar módulos

# probar a descargar un módulo que probablemente esté sin usar
lsmod | grep -E "^pcspkr|^joydev"          # busca uno con "used by" en 0
sudo modprobe -r pcspkr                    # descarga (si está cargado)
lsmod | grep pcspkr                        # comprueba que ya no aparece
sudo modprobe pcspkr                       # vuelve a cargarlo
lsmod | grep pcspkr

Si un módulo está siendo usado, modprobe -r falla con un mensaje claro:

# intento de descargar el driver del FS raíz: fallará porque está en uso
sudo modprobe -r ext4 2>&1 | head -3

3.5 - Bloquear (blacklistear) un módulo

A veces interesa que un módulo no se cargue automáticamente al arrancar: porque entra en conflicto con otro, porque consume demasiada batería, porque hay una versión propietaria mejor (caso clásico de nouveau vs nvidia). Para ello:

sudo nano /etc/modprobe.d/blacklist-pcspkr.conf
# contenido del archivo:
blacklist pcspkr

# regenera initramfs para que el cambio aplique también en arranques tempranos
sudo update-initramfs -u
# en el siguiente reinicio el módulo ya no se cargará automáticamente

Para deshacer el bloqueo basta con borrar el archivo y volver a ejecutar update-initramfs -u.

3.6 - Cargar un módulo siempre al arrancar

Lo contrario: forzar que un módulo opcional se cargue siempre:

echo "pcspkr" | sudo tee -a /etc/modules-load.d/manual.conf
# se cargará en el siguiente arranque

3.7 - Mensajes del kernel: dmesg y journalctl

Cuando el kernel detecta o pierde hardware, lo apunta. Verlo es esencial para diagnosticar.

sudo dmesg | tail -20                       # últimas 20 líneas del kernel
sudo dmesg --level=err,warn                  # sólo errores y avisos
sudo journalctl -k -p err --since today      # errores del kernel de hoy

En Ubuntu moderno la lectura de dmesg está restringida a root (kernel.dmesg_restrict=1), por eso aquí se usa sudo. Cuando estés diagnosticando un dispositivo, abre un terminal con sudo dmesg -wH (modo "watch", muestra los mensajes nuevos en tiempo real con timestamps legibles) antes de conectar/desconectar nada. Verás cada evento al instante.

El caso más típico: alguien te trae un PC con un "Dispositivo desconocido" en el Administrador de dispositivos y no sabe qué pieza es. La etiqueta del hardware se perdió, no hay manual, no sirve de nada el nombre genérico. La pista correcta son los identificadores de hardware (Vendor ID y Device ID).

4.1 - Vendor ID y Device ID

Cada dispositivo PCI o USB lleva grabados dos números:

• Vendor ID (VID): 4 dígitos hexadecimales que identifican al fabricante (Intel = 8086, Realtek = 10EC, NVIDIA = 10DE, etc.).
• Device ID (DID o PID en USB): 4 dígitos hexadecimales que identifican el modelo concreto dentro de ese fabricante.

Estos dos códigos identifican unívocamente cualquier dispositivo, aunque la pegatina exterior se haya perdido. Hay bases de datos públicas que los convierten en texto legible:

• pci.ids: base mantenida por la comunidad. En Linux está en /usr/share/misc/pci.ids.
• usb.ids: equivalente para USB, en /usr/share/misc/usb.ids.
• Versión web: pci-ids.ucw.cz y usb-ids.gowdy.us (puedes consultarlas desde fuera).

4.2 - Sacar los IDs en Windows

VID de tu adaptador de red
DID de tu adaptador de red
Nombre comercial al que se traducen

4.3 - Sacar los IDs en Linux

lspci -nn                       # lista todos los dispositivos PCI con sus IDs entre corchetes
lspci -nnk | head -30           # añade el módulo del kernel asociado a cada uno
lsusb                           # lo mismo para USB
lsusb -v 2>/dev/null | head -40 # detalle (necesita sudo para verlo todo)

Localiza tu adaptador de red en la salida de lspci -nnk y anota qué Kernel driver in use tiene asociado:

Línea del adaptador de red en lspci -nn
Kernel driver in use
Kernel modules disponibles (si los hay)

4.4 - Caso práctico: traducir un ID

Imagina que te encuentras este Hardware Id en una incidencia: PCI\VEN_10DE&DEV_1B81&...

• VEN 10DE → NVIDIA Corporation.
• DEV 1B81 → GP104 [GeForce GTX 1070].
• Con esos dos datos vas directo a la web oficial de NVIDIA, sección drivers, eliges GTX 1070 y descargas el correcto. Total: 30 segundos.

Sin esta técnica, depender del nombre que te diga el cliente ("tengo una NVIDIA, creo que la 1060 o por ahí") es muy poco fiable.

Aquí es donde se aprende de verdad. Vas a provocar tú mismo cinco fallos diferentes en tu VM, hacer como si los acabases de "encontrar" y aplicar la metodología de diagnóstico de la Parte 0.7. Después comparas el resultado con lo que sabes que rompiste.

5.1 - Caso A (Windows) - Driver desinstalado

Qué rompes: el driver de un dispositivo de red secundario (o de un dispositivo de sistema poco crítico).

Ahora diagnostica como si no supieras qué pasó:

Repara:

Dispositivo elegido
Síntoma observado
Código de error que mostró
Evento relevante en el Visor de eventos
¿Resuelto con "Buscar cambios de hardware"?

5.2 - Caso B (Windows) - Dispositivo deshabilitado

Qué rompes: deshabilitas un dispositivo (no lo desinstalas). El sistema lo sigue "viendo" pero el driver no carga. Es un caso muy frecuente en la realidad porque se hace en dos clics y a veces el usuario no recuerda haberlo hecho.

Diagnostica:

Repara: botón derecho → Habilitar dispositivo. Comprueba con ping que vuelve la red.

Mensaje de la pestaña General
Código de error
Resultado de ping antes y después

5.3 - Caso C (Windows) - Hardware ID huérfano (dispositivo "desconocido")

Qué rompes: añades un dispositivo virtual cuya identificación no coincide con ningún driver conocido. La forma sencilla es activar/desactivar un controlador opcional en VirtualBox para que aparezca un "Dispositivo desconocido".

Diagnostica:

Repara: botón derecho → Actualizar controlador → Buscar automáticamente. Si Windows tiene un driver inbox para ese chip, lo instala. Si no, vuelve a VirtualBox y restaura el controlador anterior; con eso el sonido debería volver.

VID/DID del nuevo dispositivo de audio
¿Pudo Windows resolver el driver solo?
Solución aplicada

5.4 - Caso D (Linux) - Módulo del kernel bloqueado

Qué rompes: blacklisteas el módulo del adaptador de red para que no se cargue en el siguiente arranque.

lspci -nnk | grep -A 3 -i ethernet

Verás algo como "Kernel driver in use: e1000". Ese es el módulo que vas a bloquear.

cat <<'EOF' | sudo tee /etc/modprobe.d/blacklist-roto.conf
blacklist e1000
install e1000 /bin/false
EOF
sudo update-initramfs -u
sudo reboot

Al volver del reinicio la VM ya no tiene red.

Diagnostica:

Repara:

sudo rm /etc/modprobe.d/blacklist-roto.conf
sudo update-initramfs -u
sudo modprobe e1000          # carga el módulo ahora mismo
ip a                          # ya aparece el adaptador
ping -c 3 8.8.8.8

(También se podría reiniciar, pero modprobe a mano basta para recuperar la red al instante sin esperar el reboot).

Salida de lspci -nnk | grep -A 3 -i ethernet con el fallo
Archivo culpable encontrado en /etc/modprobe.d/
Comando exacto que resolvió la incidencia

5.5 - Caso E (Linux) - Módulo con parámetro inválido

Qué rompes: intentas cargar un módulo con un parámetro que el driver no admite. Modprobe rechaza la carga (o la acepta avisando, según el módulo y el kernel) y deja constancia en dmesg. Es un caso muy realista: alguien edita un archivo en /etc/modprobe.d/ con un parámetro mal escrito y a partir de ahí el módulo no carga al arrancar.

Vamos a trabajar con un módulo no crítico. Comprueba primero qué parámetros admite (los que empiezan por parm:):

modinfo pcspkr | grep -E "^parm"
# si pcspkr no tiene parámetros o no existe en tu sistema, prueba con otro
modinfo snd_intel8x0 2>/dev/null | grep "^parm"
modinfo loop | grep "^parm"               # loop suele tener parámetros (max_loop, max_part)

Elige un módulo que sí tenga parámetros. Vas a cargarlo con un parámetro inventado:

Diagnostica:

• El usuario diría "instalé el driver pero no funciona / da error al cargar".
• El técnico ejecuta el comando y obtiene el código de salida no nulo (echo $? tras el modprobe → distinto de 0).
• sudo dmesg | tail revela el motivo exacto (parámetro desconocido).
• Si el parámetro inválido estuviera escrito en un archivo de /etc/modprobe.d/ con la forma options <mod> parametro_inventado=999, sería un fallo persistente que reaparecería en cada arranque. grep -r "<mod>" /etc/modprobe.d/ lo encuentra al instante.

Repara: carga el módulo sin parámetros (sudo modprobe <modulo>) o, si el problema estaba en un archivo de /etc/modprobe.d/, edítalo (corrige el nombre del parámetro) o elimínalo.

Módulo elegido
Mensaje exacto que dio modprobe (terminal)
Mensaje exacto en sudo dmesg | tail
Código de salida (echo $?)
Solución

5.6 - Tabla resumen de los cinco casos

Caso	Tiempo total (min)	Paso de la metodología donde estaba la pista clave	¿Lo resolverías hoy en 5 minutos?
A - Driver desinstalado
B - Dispositivo deshabilitado
C - Hardware desconocido
D - Módulo blacklisteado
E - Parámetro malo

6.1 - DISM para gestionar drivers en una imagen offline

DISM (Deployment Image Servicing and Management) es la herramienta de Microsoft para manipular imágenes de Windows sin necesidad de arrancarlas. Sirve para "preparar" un sistema con sus drivers antes de instalarlo:

(Todos los comandos siguientes desde CMD o PowerShell elevado.)

Listar drivers de terceros del Windows en ejecución (equivalente a pnputil /enum-drivers):

dism /online /get-drivers /format:table

Inyectar drivers en una imagen montada (uso típico en despliegue masivo):

dism /image:C:\offline-mount /add-driver /driver:C:\drivers\miNIC.inf

Limpiar el almacén de componentes (sin tocar drivers):

dism /online /cleanup-image /startcomponentcleanup

En tu día a día como técnico de soporte de proximidad probablemente no integres drivers en imágenes, pero conviene saber que existe la opción para entornos corporativos con MDT o WDS.

6.2 - Herramientas de información del sistema

Herramienta	Plataforma	Para qué sirve
msinfo32	Windows	Inventario completo del sistema, IRQ, recursos, dispositivos con problemas (sección "Componentes → Dispositivos problemáticos")
dxdiag	Windows	Diagnóstico de DirectX: GPU, audio, controladores de juego. Resume drivers gráficos y certificados WHQL
driverquery /v /fo table	Windows (CMD)	Lista todos los drivers del sistema (incluyendo inbox) con su estado
verifier.exe	Windows	Driver Verifier: estresa los drivers para detectar los que provocan BSOD. Sólo en pruebas, no en producción
hwinfo / inxi	Linux	Inventario detallado (sudo apt install hwinfo e inxi)
udevadm	Linux	Información de eventos PnP. Muy potente: udevadm monitor muestra en tiempo real qué pasa al conectar/desconectar hardware

6.3 - Driver Verifier (rápido) en Windows

Es la herramienta que usan los ingenieros de Microsoft cuando un sistema tiene BSODs intermitentes que sospechan que provienen de un driver de tercero. Ejecuta los drivers con comprobaciones extra (acceso ilegal a memoria, fugas, IRQL incorrecta...) y, si encuentra algo, provoca un BSOD controlado apuntando al culpable. Después se analiza el volcado.

6.4 - Eventos en tiempo real en Linux

El equivalente Linux a "ver qué pasa cuando conecto algo" es udevadm monitor o sudo dmesg -wH. Pruébalo:

sudo udevadm monitor --kernel --property --subsystem-match=usb
# en otro terminal, cambia el adaptador USB de VirtualBox o conecta un dispositivo
# verás aparecer los eventos KERNEL[...] add /devices/...

Es la versión Linux del "Eventos" del Administrador de dispositivos, sólo que en streaming.

El último paso de cada incidencia es dejarla escrita. Una empresa pequeña puede llevarlas en un Excel; una más grande, en una herramienta como GLPI, Jira Service Management o un ticket de Helpdesk. La estructura, sea cual sea la herramienta, es la misma. Rellena una ficha completa para el caso que más te haya costado de la Parte 5: