Controladores de hardware (drivers): qué son, cómo funcionan y cómo actualizarlos

Controladores de hardware entre el sistema operativo y los dispositivos Cómo los drivers conectan el sistema operativo con el hardware.

Los controladores de hardware —o drivers— son una de esas piezas de software que casi nunca vemos cuando todo funciona bien. El teclado responde, la tarjeta de red se conecta, la GPU acelera gráficos y el SSD aparece como una unidad más. Detrás de esa aparente simplicidad hay una capa que permite al sistema operativo comunicarse con dispositivos que pueden haber sido fabricados por compañías distintas y diseñados muchos años después de la versión inicial del sistema.

Comprender qué hace un driver ayuda a diagnosticar problemas, instalar correctamente un sistema operativo y evitar uno de los errores más comunes del mantenimiento de PCs: descargar controladores desde cualquier sitio o instalar “actualizadores universales” sin saber qué están reemplazando.

¿Qué es un controlador de hardware?

Un controlador de hardware es software que permite al sistema operativo utilizar un dispositivo o una familia de dispositivos. Traduce las operaciones que el sistema necesita realizar a las interfaces y protocolos que entiende el hardware.

No siempre existe una relación de “un driver por dispositivo”. Algunos controladores administran una clase completa de hardware; otros forman parte de una pila donde intervienen controladores del bus, del dispositivo y filtros adicionales.

En Windows, por ejemplo, el sistema Plug and Play detecta y enumera dispositivos, construye un árbol de hardware y selecciona el paquete de controladores que mejor coincide con cada equipo. Microsoft documenta este proceso en su documentación oficial de selección de drivers.

Driver, firmware y aplicación no son lo mismo

Estos tres conceptos suelen confundirse:

  • Driver: software que ejecuta el sistema operativo para comunicarse con el dispositivo.
  • Firmware: código que normalmente se ejecuta dentro del propio dispositivo, su controlador interno o algún microcontrolador asociado.
  • Aplicación o panel de control: programa de usuario que permite configurar funciones del dispositivo, pero que no necesariamente contiene el driver que lo hace funcionar.

Una GPU, por ejemplo, puede necesitar un driver de Windows, tener firmware propio y además ofrecer una aplicación de configuración. Actualizar uno no significa necesariamente actualizar los otros.

En Linux la separación también existe. La documentación del kernel de Linux explica que un driver puede solicitar desde espacio de usuario archivos de firmware que después se cargan en el microcontrolador del dispositivo. Es decir: el driver y el firmware pueden colaborar, pero no son la misma cosa.

¿Por qué no puede el sistema operativo controlar directamente todo el hardware?

Los sistemas operativos utilizan estándares siempre que pueden: USB, PCI Express, NVMe, SATA, Bluetooth, HID, UVC y muchos otros definen comportamientos comunes. Eso permite que una gran cantidad de dispositivos funcione sin que el usuario tenga que instalar nada manualmente.

Pero el hardware también incorpora funciones específicas. Una GPU necesita un enorme conjunto de capacidades que no puede reducirse a una interfaz universal simple; una tarjeta de audio profesional puede exponer múltiples canales y latencias especiales; una controladora RAID tiene funciones propias; un portátil puede incluir sensores, teclas especiales y administración de energía diseñada específicamente para ese modelo.

Los drivers permiten que el sistema operativo mantenga una interfaz coherente mientras debajo existen implementaciones de hardware muy diferentes.

Un driver genérico no significa necesariamente “funcionamiento a medias”

Este es un concepto importante que conviene corregir. Muchos dispositivos están diseñados para trabajar con controladores de clase incluidos en el propio sistema operativo.

Un teclado USB estándar puede funcionar perfectamente con el controlador HID de Windows o Linux. Una memoria USB puede utilizar el soporte estándar de almacenamiento masivo. Muchas webcams funcionan mediante UVC y no necesitan un instalador específico del fabricante.

Un paquete del fabricante puede añadir teclas programables, iluminación RGB, procesamiento de audio, telemetría, perfiles o ajustes avanzados, pero eso no significa que el controlador genérico esté incompleto. En algunos casos el driver estándar es precisamente la implementación correcta del estándar.

¿Qué contiene un paquete de drivers de Windows?

En Windows, un paquete de controladores suele contener varios componentes:

  • uno o más archivos del driver;
  • un archivo INF con información de instalación y los identificadores de hardware compatibles;
  • un catálogo CAT utilizado para comprobar la firma e integridad del paquete;
  • archivos adicionales requeridos por el dispositivo.

Microsoft explica la estructura en su documentación de componentes de un paquete de controladores.

Los paquetes que Windows instala quedan almacenados en el Driver Store. Plug and Play puede reutilizarlos posteriormente cuando detecta un dispositivo compatible.

La firma digital de drivers es una medida de seguridad

Un driver que se ejecuta en modo kernel tiene privilegios enormes. Un error puede provocar bloqueos o pantallas azules; un driver malicioso puede comprometer una parte muy sensible del sistema.

Por esa razón Windows aplica políticas estrictas de firma. Microsoft indica que los controladores que ejecutan código en modo kernel deben estar firmados para cargarse normalmente en sistemas Windows modernos de 64 bits. La firma ayuda a verificar tanto la identidad del editor como que el paquete no haya sido modificado después de su publicación.

Puedes consultar los detalles en la documentación oficial de firma digital de controladores de Windows.

Desactivar permanentemente la comprobación de firmas para instalar un driver descargado de una fuente desconocida no es una solución de mantenimiento normal. Los modos de prueba existen para desarrollo y diagnóstico controlado, no para convertir un PC de uso diario en un sistema que acepta cualquier controlador.

¿De dónde debemos obtener los drivers en Windows?

Para un equipo moderno conviene seguir un orden de confianza.

1. Windows Update

Windows Update instala automáticamente muchos controladores recomendados. En Windows 11 también puede ofrecer versiones adicionales en Configuración → Windows Update → Opciones avanzadas → Actualizaciones opcionales.

Los drivers opcionales no tienen que instalarse simplemente porque aparezcan. Pueden ser útiles para resolver un problema concreto, habilitar hardware nuevo o probar una versión distinta, pero si el dispositivo funciona correctamente no siempre existe una razón para sustituir el controlador actual.

2. Sitio oficial del fabricante del equipo

En portátiles, equipos todo-en-uno y PCs de marca, la página de soporte del fabricante suele ser la primera referencia cuando necesitamos controladores específicos de chipset, gráficos, audio, touchpad, cámara, lector biométrico, teclas especiales o administración de energía.

Los fabricantes pueden personalizar controladores para un modelo concreto. Intel y AMD advierten explícitamente que en determinados portátiles y sistemas OEM puede ser preferible utilizar el paquete validado por el fabricante del equipo antes que un driver genérico.

3. Fabricante del componente

Cuando necesitamos una versión más nueva o administramos un componente instalado por separado, acudimos al fabricante original. Algunos ejemplos útiles son:

La versión más reciente del fabricante del chip no siempre es la mejor para un portátil concreto. Si después de instalar un controlador genérico aparecen problemas de suspensión, brillo, pantalla, consumo o estabilidad, conviene volver al driver OEM validado para ese modelo.

Evita los “driver packs” y actualizadores universales de procedencia dudosa

Hace años eran populares enormes paquetes que prometían encontrar e instalar automáticamente todos los drivers de una computadora. Hoy su relación riesgo/beneficio es muy mala para un sistema conectado a Internet.

Un paquete de terceros puede instalar una versión incorrecta, antigua, modificada o no diseñada para las personalizaciones del equipo. También añade una fuente de software privilegiado que no necesitamos.

Windows Update, el fabricante del equipo y el fabricante del componente cubren prácticamente todos los escenarios normales. Si un dispositivo realmente carece de soporte oficial, debemos identificar exactamente el hardware y evaluar alternativas concretas, no instalar un paquete indiscriminado.

¿Hay que instalar siempre el driver más nuevo?

No. “Más nuevo” y “mejor para mi equipo” no son sinónimos.

Una actualización puede ser importante cuando corrige una vulnerabilidad, soluciona un fallo que estamos experimentando, añade soporte para una versión nueva del sistema operativo, mejora compatibilidad con una aplicación o habilita una función que necesitamos.

Pero en estaciones de trabajo, servidores o equipos que ya son estables, actualizar drivers sin una razón también introduce cambios. Las ramas de producción de algunos fabricantes priorizan precisamente estabilidad frente a novedades.

La política sensata es mantener un sistema soportado y corregido, leer las notas de versión cuando la actualización sea importante y conservar la posibilidad de volver atrás si algo falla.

Administrador de dispositivos: qué podemos comprobar

En Windows 11 podemos abrir Administrador de dispositivos desde el menú contextual de Inicio o buscándolo por su nombre.

Desde las propiedades de cada dispositivo podemos comprobar:

  • fabricante y modelo detectado;
  • proveedor, fecha y versión del driver;
  • estado del dispositivo y códigos de error;
  • identificadores de hardware;
  • actualización, desinstalación o, cuando está disponible, reversión al controlador anterior.

Los Hardware IDs son especialmente útiles cuando aparece un dispositivo desconocido. Identificadores PCI como VEN_xxxx y DEV_xxxx, o identificadores USB VID_xxxx y PID_xxxx, permiten averiguar exactamente qué componente está conectado antes de buscar un controlador.

Respaldar drivers en Windows sin instalar aplicaciones de terceros

Windows incorpora PnPUtil, una herramienta administrativa para gestionar paquetes de controladores.

Podemos exportar los paquetes de terceros del Driver Store a una carpeta con:

pnputil /export-driver * C:DriverBackup

Microsoft documenta esta función en los ejemplos oficiales de PnPUtil.

Esto es útil antes de reinstalar un equipo antiguo cuyo fabricante ya no publica fácilmente sus paquetes. No sustituye un backup completo del sistema y no significa que debamos restaurar todos esos drivers sin comprobar si la nueva versión de Windows ya incorpora otros mejores.

Drivers en GNU/Linux: una arquitectura diferente

Decir simplemente que “los drivers de Linux están en el kernel” es una aproximación útil para comenzar, pero incompleta.

Muchos controladores forman parte del árbol oficial del kernel y pueden compilarse directamente dentro del kernel o como módulos cargables. Las distribuciones empaquetan esos módulos junto con su kernel y normalmente detectan el hardware durante el arranque.

También existen módulos externos al árbol principal, controladores propietarios y componentes de espacio de usuario. El soporte de una GPU, por ejemplo, puede involucrar un módulo del kernel, bibliotecas gráficas de usuario y firmware del dispositivo.

La documentación oficial del kernel de Linux describe la infraestructura que utilizan los desarrolladores de controladores.

Firmware en Linux: por qué a veces el driver existe pero el dispositivo no funciona

Un caso frecuente es que el kernel tenga el controlador correcto, pero falte un archivo de firmware necesario para inicializar Wi-Fi, Bluetooth, GPU u otro dispositivo.

El kernel puede solicitar esos archivos desde el sistema de archivos y cargarlos en el microcontrolador del hardware. Por eso una distribución puede necesitar paquetes de firmware adicionales aunque el driver ya forme parte del kernel.

Cuando un dispositivo aparece detectado pero no termina de inicializarse, revisar los mensajes del kernel y los paquetes de firmware de la distribución suele ser más útil que descargar un “driver para Linux” de cualquier página.

Módulos firmados y Secure Boot en Linux

Linux también dispone de mecanismos para firmar criptográficamente módulos del kernel. Las distribuciones que integran Secure Boot pueden exigir que módulos externos estén firmados con una clave de confianza antes de cargarlos.

Eso explica por qué algunos drivers propietarios o módulos DKMS dejan de cargar después de activar Secure Boot o de actualizar el kernel hasta que se recompilan y firman correctamente.

La documentación de firma de módulos del kernel Linux explica cómo el kernel verifica estas firmas.

En Linux, empieza por los repositorios de la distribución

Para la mayoría del hardware, el mejor camino es utilizar el kernel, Mesa, firmware y paquetes que mantiene la propia distribución.

Incluso NVIDIA indica en su sitio oficial de drivers que muchas distribuciones Linux ofrecen el controlador NVIDIA en su formato nativo de paquetes y que esa integración puede funcionar mejor con el resto del sistema.

Esto es especialmente importante para que actualizaciones de kernel, DKMS, Secure Boot y dependencias permanezcan coordinadas.

Drivers en máquinas virtuales: VirtIO y Guest Additions

Una máquina virtual también ve “hardware”, aunque sea virtual. Por eso necesita drivers.

En entornos KVM/QEMU se utiliza ampliamente VirtIO, un estándar diseñado para que sistemas invitados utilicen dispositivos virtuales eficientes de red, almacenamiento y otros tipos.

En Oracle VirtualBox, las Guest Additions instalan controladores y servicios que mejoran gráficos, integración del puntero y otras funciones dentro de la VM.

La virtualización deja muy claro el papel de un driver: el sistema invitado no necesita saber si detrás existe una tarjeta de red física concreta; necesita un controlador para el dispositivo virtual que el hipervisor le presenta.

¿Cuándo sospechar de un problema de driver?

Algunos síntomas comunes son:

  • un dispositivo aparece con advertencia o código de error;
  • desaparecen funciones después de reinstalar Windows;
  • la resolución gráfica queda limitada o falta aceleración;
  • Wi-Fi, Bluetooth, sonido o cámara no aparecen;
  • un dispositivo USB se conecta y desconecta repetidamente;
  • después de una actualización aparecen pantallas azules, bloqueos o problemas de suspensión;
  • en Linux, el dispositivo aparece en lspci o lsusb pero el módulo o firmware no carga correctamente.

No todos estos síntomas implican necesariamente un driver. Hardware defectuoso, firmware, alimentación, cables, BIOS/UEFI, configuración o el propio sistema operativo pueden producir efectos similares. Un buen diagnóstico identifica primero el componente y después comprueba cada capa.

Un criterio práctico para mantener los drivers

Podemos resumir una política razonable en pocas ideas:

  • deja que el sistema operativo gestione automáticamente los dispositivos comunes;
  • utiliza Windows Update o los repositorios oficiales de tu distribución;
  • para equipos OEM, consulta primero al fabricante del equipo;
  • para GPU, chipset u otro componente específico, utiliza el fabricante oficial cuando sea apropiado;
  • evita paquetes universales y sitios de descargas no verificadas;
  • no actualices por número de versión solamente: revisa qué corrige o añade;
  • si una actualización causa problemas, utiliza rollback o reinstala la versión estable anterior;
  • distingue siempre entre driver, firmware y aplicación de configuración.

Los drivers son una parte crítica del sistema operativo porque se encuentran exactamente en la frontera entre software y hardware. Cuando esa capa está bien mantenida prácticamente desaparece de nuestra vista; cuando falla, puede hacer que un componente perfectamente sano parezca averiado.

Para entender mejor dónde encaja esta capa dentro del computador, puedes continuar con nuestra introducción a los sistemas operativos y con la guía general de virtualización.

Fuentes y documentación oficial

Ir al contenido