Anatomía de un driver de Windows: del DriverEntry al IRPAnatomy of a Windows driver: from DriverEntry to the IRP

El pantallazo más común está mal entendido#

Si has visto alguna pantalla azul, es probable que dijera IRQL_NOT_LESS_OR_EQUAL. Es el bugcheck 0xA, y su nombre invita a pensar que alguien rompió una regla abstracta sobre niveles de interrupción. Casi nunca es eso.

En la gran mayoría de casos reales, detrás hay algo mucho más prosaico: un puntero malo, NULL o que apunta a memoria ya liberada, o memoria paginable tocada a un IRQL demasiado alto para que el fallo de página se pueda resolver. A DISPATCH_LEVEL o por encima, el sistema no puede traer páginas del disco. Lo que en un programa normal sería un fallo de página rutinario, que el sistema resuelve sin que te enteres, en el kernel se convierte en un bugcheck. Su pariente, el 0xD1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL), va un paso más allá y señala directamente a un driver.

Por eso, cuando depuras uno de estos, la pregunta útil no es «¿qué regla de IRQL he roto?», sino esta:

En De Ring 3 a Ring 0 contamos la frontera entre tus programas y el kernel desde fuera: cómo se cruza y por qué un fallo al otro lado tumba el sistema entero. Hoy cruzamos esa frontera y miramos cómo está organizado el código que vive dentro: un driver de Windows, desde que se carga hasta que atiende una petición. Para entender esa pregunta, primero hay que entender qué es un driver y qué es el IRQL.

Un driver no es un programa#

Un ejecutable es pasivo: el sistema operativo lo arranca, le da su propio espacio de memoria y, si falla, cierra el proceso y limpia lo que dejó. Un driver no tiene nada de eso. Corre como parte del sistema operativo, en Ring 0, y no hay ninguna frontera de proceso que proteja al resto del sistema de sus errores.

Tampoco tiene main. Su punto de entrada es DriverEntry, y lo pone en marcha el I/O Manager de Windows al cargar el driver, sin la cadena de arranque de la biblioteca de C que en un programa normal acaba llamando a main. Lo único que se interpone es GsDriverEntry, un envoltorio mínimo que el compilador genera automáticamente, hace una pequeña inicialización y llama a tu DriverEntry. Esta es la firma de DriverEntry, en un fragmento de mi guía de fundamentos de drivers:

NTSTATUS DriverEntry(
    // tu identidad, te la entregan
    PDRIVER_OBJECT DriverObject,
    // tu clave de configuración en el registro
    PUNICODE_STRING RegistryPath
);

Tres reglas acompañan a esa firma:

• DriverEntry corre a PASSIVE_LEVEL, el nivel más bajo, el mismo que un hilo normal.
• Si devuelve un error en lugar de STATUS_SUCCESS, el driver no se carga y su rutina de descarga nunca se llama. Todo lo que hayas creado antes de fallar lo tienes que deshacer tú, allí mismo.
• El DRIVER_OBJECT no es tuyo: te lo entregan, y nunca lo borras.

IRQL, la ley física del kernel#

El IRQL (Interrupt Request Level) es un número pequeño, y hay uno por núcleo: de 0 a 15 en Windows de 64 bits, que es el único que existe en Windows 11, y de 0 a 31 en el antiguo x86 de 32 bits. La regla es sencilla y no admite excepciones: el código que corre a un IRQL solo puede ser interrumpido por algo de IRQL estrictamente mayor. Esta es la tabla de mi guía, con los valores de 64 bits:

Por encima de los dispositivos quedan niveles reservados al propio sistema, como el reloj (13) o el máximo, HIGH_LEVEL (15). La frontera importante, sin embargo, está entre el 1 y el 2. Por debajo, tu código se comporta como cualquier hilo: puede esperar, dormir y tocar memoria que quizá esté en disco, porque si hace falta el sistema la trae. A partir de DISPATCH_LEVEL no hay planificación de hilos en ese núcleo: nada puede dormirte ni despertarte, y el sistema no puede parar a leer una página del disco. Ahí está la explicación del pantallazo del principio: la misma línea de código que funciona a PASSIVE_LEVEL tumba el sistema a DISPATCH_LEVEL si la memoria que toca resulta estar paginada.

El viaje de un IRP#

Cuando un programa pide algo a un dispositivo, esa petición no llega al driver como una llamada de función. Llega como un IRP (I/O Request Packet): una estructura que representa la petición de E/S y que baja por una pila de drivers. Mi guía lo resume en seis pasos:

1. La aplicación llama a ReadFile, WriteFile o DeviceIoControl.
2. El I/O Manager construye el IRP, con un IO_STACK_LOCATION para cada driver de la pila.
3. Los drivers de filtro, si los hay, lo inspeccionan y lo pasan hacia abajo.
4. El driver de función recibe el IRP en su rutina de dispatch.
5. El driver de bus habla con el hardware.
6. IoCompleteRequest devuelve el IRP hacia arriba, con el resultado.

La regla que no se negocia: cada IRP se completa o se reenvía exactamente una vez. Un IRP olvidado no es una fuga de memoria, es una E/S colgada: un programa esperando para siempre una respuesta que no va a llegar. Y mi guía incluye un aviso muy concreto: si llamas a IoSkipCurrentIrpStackLocation y después pones una rutina de finalización, puedes pisar la del driver que está por encima de ti.

Compruébalo desde modo usuario#

No hace falta escribir un driver para ver el primer paso de ese viaje. Este programa abre el primer disco físico y le pide su geometría al driver de disco de Windows con DeviceIoControl. Abre el disco con acceso 0, que solo permite consultar metadatos: no lee ni escribe nada, y por eso no necesita permisos de administrador. Como la entrada de Ring -2, es código solo para Windows:

// g++ -std=c++20 ioctl.cpp -o ioctl.exe   (Windows)
// Pide al driver de disco su geometría con DeviceIoControl,
// sin permisos de administrador.
#include <windows.h>
#include <winioctl.h>
#include <format>
#include <iostream>

int main() {
    // Acceso 0: solo metadatos; no se lee ni se escribe el disco.
    HANDLE disk = CreateFileW(L"\\\\.\\PhysicalDrive0", 0,
                              FILE_SHARE_READ | FILE_SHARE_WRITE,
                              nullptr, OPEN_EXISTING, 0, nullptr);
    if (disk == INVALID_HANDLE_VALUE) return 1;

    DISK_GEOMETRY_EX geo{};
    DWORD bytes = 0;
    const DWORD code = IOCTL_DISK_GET_DRIVE_GEOMETRY_EX;
    const BOOL ok = DeviceIoControl(disk, code, nullptr, 0,
                                    &geo, sizeof geo, &bytes, nullptr);
    CloseHandle(disk);
    if (!ok) return 1;

    // CTL_CODE(DeviceType, Function, Method, Access), desempaquetado
    std::cout << std::format("IOCTL    0x{:08X}\n", code)
              << std::format("  DeviceType 0x{:X}\n", code >> 16)
              << std::format("  Function   0x{:X}\n", (code >> 2) & 0xFFF)
              << std::format("  Method     {}\n", code & 3)
              << std::format("  Access     {}\n", (code >> 14) & 3)
              << std::format("Disk     {:.1f} GB\n",
                             geo.DiskSize.QuadPart / 1e9)
              << std::format("Sector   {} bytes\n",
                             geo.Geometry.BytesPerSector);
}

Esta es la salida real en mi equipo, un Intel Core i9-14900KF con Windows 11:

IOCTL    0x000700A0
  DeviceType 0x7
  Function   0x28
  Method     0
  Access     0
Disk     2000.4 GB
Sector   512 bytes

Esa llamada a DeviceIoControl es exactamente el paso 1 del viaje. El I/O Manager construye un IRP de tipo IRP_MJ_DEVICE_CONTROL y lo baja por la pila de drivers de disco, que responde con un disco de 2000,4 GB y sectores de 512 bytes.

Lo más interesante está en las primeras líneas. El código 0x000700A0 no es un número arbitrario: es la macro CTL_CODE empaquetada, y el programa la desempaqueta. DeviceType 0x7 es el tipo disco; Function 0x28 es la operación concreta; Method 0 es METHOD_BUFFERED; y Access 0 es FILE_ANY_ACCESS, que es justo lo que permite pedirla con un handle abierto con acceso 0. Enseguida veremos qué significan esos métodos, porque es lo mismo que define un driver cuando crea sus propios códigos.

La tabla de dispatch#

¿Cómo sabe el driver qué función llamar cuando le llega un IRP? Por su tabla de dispatch. DRIVER_OBJECT.MajorFunction es un array de punteros a función indexado por el tipo de petición, IRP_MJ_*, y DriverEntry la rellena. Otro fragmento de mi guía:

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject,
                     PUNICODE_STRING RegistryPath) {
    DriverObject->MajorFunction[IRP_MJ_CREATE]         = MyCreateClose;
    DriverObject->MajorFunction[IRP_MJ_CLOSE]          = MyCreateClose;
    DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = MyDeviceControl;
    DriverObject->DriverUnload                         = MyUnload;
    // ... IoCreateDevice e IoCreateSymbolicLink (más abajo) ...
    return STATUS_SUCCESS;
}

Las entradas que no asignas fallan la petición por defecto. Y mi guía insiste en el orden: la tabla se rellena antes de llamar a IoCreateDevice, para que el dispositivo nunca exista con la tabla a medias.

IOCTL propios#

Cuando un driver necesita operaciones que no encajan en leer o escribir, define sus propios IOCTL con la misma macro que acabamos de desempaquetar:

#define IOCTL_MY_DEVICE_DO_THING \
    CTL_CODE(FILE_DEVICE_UNKNOWN, 0x800, METHOD_BUFFERED, FILE_ANY_ACCESS)

El tercer argumento, el método de transferencia, decide cómo viajan los datos entre modo usuario y el driver:

• METHOD_BUFFERED: el I/O Manager copia los datos a un búfer del sistema. Es el recomendado, y el que usa el driver de disco en nuestro ejemplo.
• METHOD_IN_DIRECT y METHOD_OUT_DIRECT: los datos se describen con una MDL. Pensados para transferencias grandes.
• METHOD_NEITHER: el driver recibe los punteros de usuario en bruto y tiene que validarlo todo a mano. Se usa poco, y por algo.

Sincronización: ¿encuentras el bug?#

Un driver atiende peticiones de varios hilos y de varios núcleos a la vez, así que necesita proteger sus datos compartidos. Tiene dos herramientas principales, y el IRQL decide cuál puedes usar:

• Spinlock: se adquiere a DISPATCH_LEVEL o por debajo, y te sube a DISPATCH_LEVEL mientras lo tienes. Si está ocupado, esperas activamente dando vueltas, así que hay que tenerlo el menor tiempo posible.
• Mutex: para esperarlo hay que estar como mucho a APC_LEVEL, y en la práctica a PASSIVE_LEVEL. Si está ocupado, el hilo se duerme hasta que se libere.

Con eso, este fragmento de mi guía es un reto. Míralo con calma antes de seguir leyendo:

VOID MyDpcRoutine(PKDPC Dpc, PVOID Context, PVOID Arg1, PVOID Arg2) {
    KeAcquireSpinLock(&g_DeviceLock, &oldIrql);
    // Recurso compartido que TAMBIÉN usa un manejador de IOCTL
    KeWaitForSingleObject(&g_ConfigMutex, Executive, KernelMode,
                          FALSE, NULL);
    UpdateSharedConfig();
    KeReleaseMutex(&g_ConfigMutex, FALSE);
    KeReleaseSpinLock(&g_DeviceLock, oldIrql);
}

¿Lo ves? Un DPC ya corre a DISPATCH_LEVEL, y además tiene un spinlock adquirido. Esperar en un objeto del dispatcher, como el mutex, a ese IRQL, con una espera que no sea de tiempo cero (aquí es indefinida), es un error fatal documentado: bugcheck inmediato. Tiene todo el sentido si recuerdas la tabla: a DISPATCH_LEVEL no hay planificación de hilos, así que nada puede dormir a este hilo ni despertarlo cuando el mutex quede libre.

El arreglo depende de quién toca el dato:

• Si lo tocan el DPC y el manejador del IOCTL, se protege con el mismo spinlock en ambos sitios, y el mutex sobra.
• Si solo debería tocarse a PASSIVE_LEVEL, ese trabajo se saca del DPC con un work item, que el sistema ejecuta después en un hilo a PASSIVE_LEVEL.

Ciclo de vida: crear y descargar#

Para que un programa pueda hablar con el driver, este tiene que crear un dispositivo. Lo hace con IoCreateDevice, cuyos parámetros clave son el tamaño de la extensión del dispositivo (la memoria propia del driver para ese dispositivo), un nombre del tipo \Device\…, el tipo de dispositivo y FILE_DEVICE_SECURE_OPEN. Después, IoCreateSymbolicLink crea un enlace simbólico para que modo usuario pueda abrirlo con CreateFile.

Con un matiz: la documentación de Microsoft recomienda que los drivers de producción usen IoRegisterDeviceInterface, con una clase de interfaz identificada por un GUID. El enlace simbólico es lo habitual en guías y drivers sencillos.

Al descargar, DriverUnload deshace todo en orden inverso: primero borra el enlace simbólico, después el dispositivo, y libera todo lo que haya reservado. En el kernel no hay proceso que cerrar: una fuga dura hasta el reinicio.

Cómo se trabaja de verdad#

Todo lo anterior explica por qué el desarrollo de drivers tiene su propio método de trabajo. Mi guía de laboratorio lo organiza así:

• Nunca en la máquina principal. Se trabaja en una máquina virtual de pruebas.
• Test-signing en esa VM, para poder cargar tus drivers de prueba. Queda bloqueado si la VM tiene Secure Boot activo.
• Depuración con dos máquinas. Un bugcheck mata también a cualquier depurador que corra en la misma máquina, así que WinDbg se conecta desde fuera: por una tubería serie de la VM o por red con KDNET.
• Símbolos del servidor público de Microsoft, para que las pilas de llamadas tengan nombres y no solo direcciones.
• Driver Verifier (verifier.exe), que estresa el driver a propósito para que los fallos de memoria, las fugas y las violaciones de IRQL salgan en el laboratorio y no en producción. Solo en la VM.
• Volcado de memoria del kernel activado, y el reinicio automático desactivado, para poder leer la pantalla azul y analizarla después.
• Snapshots. Cuando la VM queda rota, se vuelve al último snapshot en vez de intentar salvarla.

En el kernel no hay red#

Si hay una idea que une todo lo anterior es que en el kernel no hay red. En modo usuario, un puntero malo cierra tu programa; en Ring 0, cierra el sistema. Por eso las reglas de esta entrada no son cuestión de estilo: respetar el IRQL, completar cada IRP exactamente una vez y validar cada búfer que llega de modo usuario es lo que separa un driver de un pantallazo.

Si quieres ver dónde encaja todo esto en la arquitectura de la CPU, la serie de los anillos empieza en De Ring 3 a Ring 0, baja al hipervisor en Ring -1 y termina en el firmware, en Ring -2.