Las profundidades de la E/S de Windows (parte 1) — Toda lectura y escritura se convierte en un IRP: panorama general del sistema de E/S

Una sola línea de File.ReadAllText, o una sola llamada a ReadFile. ¿Qué ocurre dentro de Windows mientras esa función tarda en devolver el control?

Al abrir Process Monitor durante la investigación de un fallo, aparecen términos desconocidos como IRP_MJ_READ o FASTIO_READ. Al perseguir una fuga de identificadores (handle leak), un archivo que debería haberse cerrado con CloseHandle sigue vivo. «El comportamiento cambia en una unidad de red», «solo es lento en el entorno donde hay un antivirus instalado»: estos fenómenos, que se repiten una y otra vez en el día a día de las aplicaciones empresariales, ocurren todos sobre el mismo terreno: el sistema de E/S de Windows.

Con este artículo comienza la serie «Las profundidades de la E/S de Windows», que excava ese terreno desde su base. Al igual que la célebre obra Windows Internals baja hasta el diseño del núcleo para explicarlo, esta serie tampoco trata sobre «cómo usar la API», sino sobre «por qué funciona así».¹ La estructura prevista es la siguiente.

1. Panorama general del sistema de E/S — toda lectura y escritura se convierte en un IRP (este artículo)
2. E/S síncrona y asíncrona — el verdadero significado de OVERLAPPED
3. Los puertos de finalización de E/S (IOCP) y el grupo de subprocesos de .NET — el sótano de async/await
4. El Administrador de caché — cuándo llega realmente su WriteFile al disco
5. La estructura interna de NTFS — entender el sistema de archivos a partir de la MFT
6. Controladores de filtro y minifiltros — por qué Procmon y los antivirus pueden interceptar la E/S

Este primer artículo, base de todas las entregas siguientes, fija con diagramas «los protagonistas y el flujo de las solicitudes». No es un artículo para escribir controladores, sino uno pensado para que el desarrollador de aplicaciones pueda seguir hasta el final el destino de la API que acaba de llamar.

Conocimientos previos: basta con haber usado FileStream en C# o haber llamado a CreateFile/ReadFile en C/C++. No hace falta experiencia en desarrollo de controladores; el código del lado del núcleo solo aparece como diagramas conceptuales. Tiempo estimado de lectura: unos 25 minutos leyendo de corrido y mirando los diagramas, o de 2 a 3 minutos si solo quiere la conclusión del capítulo 1.

Guía de lectura selectiva: como el artículo es largo, aquí tiene puntos de entrada según su objetivo.

• Solo quiero captar el panorama general → capítulo 1 (conclusión) → capítulo 2 (resolución de nombres) → capítulo 5 (un viaje completo de ReadFile)
• Quiero ordenar la terminología (objetos driver/device/archivo, IRP) → capítulos 3 y 4
• Quiero conocer las «formas de romperse» en la práctica (fugas de identificadores, «archivo en uso») → capítulo 6
• Quiero poner manos a la obra → capítulo 7

1. Ante todo, la conclusión

• La E/S de Windows está impulsada por paquetes. La mayoría de las solicitudes enviadas a un controlador de dispositivo se empaquetan en un IRP (I/O Request Packet) y fluyen de arriba hacia abajo por la pila de controladores apilados (la pila de dispositivos).²³
• CreateFile no siempre abre un «archivo». La resolución del nombre se realiza en el espacio de nombres del Administrador de objetos, y C: es, en realidad, un vínculo simbólico a un nombre de dispositivo NT como \Device\HarddiskVolume3 (capítulo 2).⁴⁵
• Hay tres objetos protagonistas. El «objeto driver» (driver object), que contiene la tabla de funciones de procesamiento; el «objeto device» (device object), que es el destinatario de la solicitud; y el «objeto archivo» (file object), que guarda el estado de una apertura concreta. El HANDLE que usted posee es una referencia al objeto archivo (capítulo 3).⁶⁷⁸⁹
• Cada controlador solo tiene tres opciones. Completar el IRP «por sí mismo», «pasarlo al controlador inferior» o «dejarlo pendiente para completarlo más tarde». La combinación de estas tres opciones explica por completo tanto los controladores de filtro como la caché y la E/S asíncrona (capítulo 4).³¹⁰
• En el fondo del núcleo no existe un mecanismo separado llamado «E/S síncrona». La verdadera naturaleza de la E/S síncrona es la garantía de «no retornar antes de completarse»; la espera solo ocurre cuando la solicitud queda pendiente. Este es el punto de entrada de la segunda y la tercera entrega (capítulo 5).¹¹
• CloseHandle no significa «cerrar», sino «devolver un identificador». Hay dos etapas: cleanup, cuando se cierra el último identificador, y close, cuando desaparecen todas las referencias dentro del núcleo. Esta diferencia es la verdadera causa del «cerrado pero en uso» (capítulo 6).¹²¹³
• Esta capa se puede observar directamente. WinObj permite ver el espacio de nombres y Process Monitor el flujo de los IRP. El vocabulario que muestra Procmon es exactamente la terminología de este artículo (capítulo 7).¹⁴

2. La verdadera naturaleza de «todo se ve como un archivo»

2.1. Adónde va el nombre que se pasa a CreateFile

Todas las API de archivos de Win32 empiezan por un «nombre». Una ruta como C:\project\report.csv, una ruta UNC como \\server\share\data.csv, o una designación de dispositivo como \\.\COM3: todas ellas se pueden pasar a la misma función CreateFile.¹⁵

Detrás de esta coherencia hay un único espacio de nombres gestionado por el Administrador de objetos del núcleo. Dentro del núcleo, dispositivos, eventos y secciones de memoria compartida se registran todos como «objetos» en este espacio de nombres en forma de árbol. Con WinObj de Sysinternals se puede examinar directamente este espacio de nombres.¹⁴

flowchart TB
    ROOT["\ (raíz del espacio de nombres)"]
    DEV["\Device<br/>(objetos de dispositivo creados por los controladores)"]
    GLB["\GLOBAL??<br/>(lugar de los nombres globales visibles desde Win32)"]
    BNO["\BaseNamedObjects<br/>(mutexes con nombre, etc.)"]
    ROOT --> DEV
    ROOT --> GLB
    ROOT --> BNO
    DEV --> D1["HarddiskVolume3"]
    DEV --> D2["Serial0"]
    DEV --> D3["Mup (redirector de red)"]
    GLB --> L1["C: → \Device\HarddiskVolume3"]
    GLB --> L2["COM1 → \Device\Serial0"]
    GLB --> L3["PhysicalDrive0 → \Device\Harddisk0\DR0"]

Figura 1: espacio de nombres del Administrador de objetos (extracto). Lo que hay bajo \GLOBAL?? son vínculos simbólicos; su destino real está bajo \Device

El punto clave es que los nombres que usa una aplicación Win32 (letras de unidad, nombres de puerto COM) y los nombres que usa el núcleo (nombres de dispositivo NT) están en niveles distintos. El vínculo simbólico es lo que conecta ambos.

2.2. La letra de unidad es un vínculo simbólico

Cuando un controlador quiere que su dispositivo sea visible desde una aplicación Win32, crea con IoCreateSymbolicLink un vínculo simbólico desde un nombre de dispositivo MS-DOS, como \DosDevices\COM1, hacia el nombre de dispositivo NT.⁴ C: funciona igual: en realidad es un vínculo hacia un dispositivo de volumen como \Device\HarddiskVolume3.

Por eso, la resolución del nombre en CreateFile("C:\project\report.csv") avanza así.

flowchart TB
    A["Nombre pasado por la aplicación<br/>C:\project\report.csv"]
    B["La capa Win32 lo convierte a formato NT<br/>\??\C:\project\report.csv"]
    C["El Administrador de objetos busca en el espacio de nombres<br/>y detecta que \??\C: es un vínculo simbólico"]
    D["Sigue el vínculo y lo sustituye<br/>\Device\HarddiskVolume3\project\report.csv"]
    E["En \Device\HarddiskVolume3<br/>se llega al objeto de dispositivo del volumen"]
    F["La resolución del resto, \project\report.csv,<br/>queda a cargo del controlador del sistema de archivos (NTFS)<br/>cuando el Administrador de E/S emite un IRP_MJ_CREATE"]
    A --> B
    B --> C
    C --> D
    D --> E
    E --> F

Figura 2: resolución del nombre en CreateFile. La primera mitad es obra del Administrador de objetos; la segunda, una vez alcanzado el dispositivo, es trabajo del sistema de archivos

Este diagrama resuelve varias dudas habituales.

• El significado del prefijo \\.\. El \\.\ de \\.\PhysicalDrive0 o \\.\COM10 es una notación que apunta directamente al espacio de nombres de dispositivos de Win32 (≈ el directorio \??). Sin pasar por una letra de unidad, designa directamente el lugar donde están los vínculos.⁵¹⁵
• Por qué CON o NUL no se pueden usar como nombre de archivo. Porque están reservados como nombres de dispositivo MS-DOS y pueden resolverse hacia el dispositivo sin importar en qué punto de la ruta aparezcan.⁵ Las trampas prácticas relacionadas con esto están recopiladas en «MAX_PATH y las trampas de rutas y nombres de archivo en Windows».
• La ruta UNC tampoco recibe un trato especial. \\server\share se resuelve al dispositivo del redirector de red (\Device\Mup), y a partir de ahí el cliente SMB transporta la solicitud a través de la red. La raíz de los problemas en que el comportamiento cambia entre lo local y lo UNC está en que el dispositivo de destino de la resolución es distinto (véase «Trampas de las unidades de red y las rutas UNC»).

Cabe precisar que \?? no es un alias de un directorio real, sino una entrada virtual que representa un orden de búsqueda: «primero consultar el mapa local de dispositivos DOS de la sesión de inicio de sesión y, si no existe, recurrir a \GLOBAL??». Las letras de unidad creadas con net use o subst entran en este lado local, por lo que en el mismo equipo cada usuario (sesión de inicio de sesión) puede ver unidades distintas, y un servicio puede no ver las unidades de red del usuario. En la figura 1 solo se representó el lado global (\GLOBAL??).

En otras palabras, la forma exacta de decir que «en Windows todo se ve como un archivo» es que «todo nombre acaba resolviéndose en un objeto de dispositivo, y las solicitudes posteriores se unifican en el mismo formato: el IRP». Entonces, ¿qué es ese objeto de dispositivo? Vamos a ordenar los protagonistas.

3. Los protagonistas son tres objetos

La estructura del sistema de E/S de Windows puede describirse como la relación entre tres tipos de objetos del núcleo.

A partir de aquí se suceden términos técnicos. Para no perderse, aquí tiene primero una tabla de correspondencia entre «lo que se ve en el código habitual» y «el nombre que recibe en el lado del núcleo». Los capítulos 3 y 4 están escritos con el vocabulario de la columna derecha.

3.1. El objeto driver — la tabla de funciones de procesamiento

Cuando se carga un controlador, el Administrador de E/S crea un objeto driver (DRIVER_OBJECT) que lo representa.⁶ Desde el punto de vista de un desarrollador de aplicaciones, el miembro más importante es el arreglo MajorFunction. Se trata de una tabla de correspondencia entre «tipo de solicitud → función de procesamiento», donde el tipo de solicitud se expresa mediante códigos de función mayor como IRP_MJ_CREATE (abrir), IRP_MJ_READ (leer), IRP_MJ_WRITE (escribir), IRP_MJ_CLEANUP o IRP_MJ_CLOSE.¹⁶

Forzándolo un poco en C#, la idea sería algo así.

// Diagrama conceptual. En realidad es una estructura C dentro del núcleo
class DriverObject
{
    // El índice es IRP_MJ_XXX. Hay 28 tipos en total
    public DispatchRoutine[] MajorFunction = new DispatchRoutine[28];
}
// En ntfs.sys, MajorFunction[IRP_MJ_READ] contiene "el procesamiento de lectura de NTFS"

3.2. El objeto dispositivo — el destino de la solicitud

Un controlador crea un objeto dispositivo (DEVICE_OBJECT) por cada dispositivo del que se hace cargo.⁷ Este es el destino de la solicitud de E/S. No siempre existe una correspondencia uno a uno con un dispositivo físico: puede tratarse de una entidad lógica como un volumen (HarddiskVolume3), o de un «dispositivo que solo existe para interceptar», creado por un controlador de filtro. Como el objeto dispositivo apunta al objeto driver que lo creó, al determinar el destino queda determinada también la tabla de funciones de procesamiento.

3.3. El objeto archivo — el estado de «una apertura»

Cada vez que CreateFile tiene éxito, el núcleo crea un objeto archivo. No es «el archivo en disco» en sí, sino un objeto que representa una sesión concreta de apertura de ese archivo (o dispositivo).⁸ Si se abre el mismo archivo dos veces, se crean dos objetos archivo. Aquí se guardan el puntero de archivo actual (en el caso de identificadores síncronos) y el modo de uso compartido y las marcas con que se abrió.

Y el HANDLE que recibe la aplicación es una referencia al objeto archivo, obtenida a través de la tabla de identificadores propia de cada proceso.⁹

flowchart LR
    subgraph P["Proceso (modo usuario)"]
        H1["HANDLE 0x1A4"]
        H2["HANDLE 0x1B8"]
    end
    subgraph K["Espacio del núcleo"]
        FO1["Objeto archivo 1<br/>report.csv abierto para lectura<br/>desplazamiento actual: 4096"]
        FO2["Objeto archivo 2<br/>report.csv abierto para anexar<br/>desplazamiento actual: 65536"]
        DO["Objeto dispositivo<br/>equivalente a HarddiskVolume3"]
        DR["Objeto driver NTFS<br/>MajorFunction = tabla de funciones de procesamiento"]
    end
    H1 --> FO1
    H2 --> FO2
    FO1 --> DO
    FO2 --> DO
    DO --> DR

Figura 3: relación entre los tres objetos. El identificador apunta al objeto archivo a través de la tabla de identificadores; el objeto archivo se conecta al dispositivo, y el dispositivo, al controlador

Con este diagrama en mente, varios conocimientos prácticos dejan de ser «memorización» para volverse «evidentes».

• La verdadera naturaleza de una fuga de identificadores es una acumulación de objetos archivo (y de los recursos que dependen de ellos) que siguen siendo referenciados y no pueden liberarse. Lo que hay que contar son las entradas de la tabla de identificadores, y eso es exactamente lo que muestran Process Explorer o handle.exe («Process Explorer / Handle / VMMap en la práctica»; como caso de investigación, «Investigación de una falla tras un funcionamiento prolongado de una cámara industrial - fuga de identificadores»).
• Que dos identificadores del mismo archivo tengan punteros de archivo independientes se debe a que el puntero reside en el objeto archivo. En cambio, un identificador duplicado con DuplicateHandle apunta al mismo objeto archivo, por lo que comparte el puntero.
• Una infracción de uso compartido (sharing violation) se determina cuando el núcleo compara el modo de uso compartido de los objetos archivo existentes con la nueva solicitud de CreateFile. La práctica del control de exclusión se trató en «Conceptos básicos del control de exclusión en la integración de archivos».

4. El IRP — la solicitud de E/S se convierte en un paquete

4.1. Por qué convertirla en un paquete

Cuando el Administrador de E/S recibe una solicitud de la aplicación (abrir, leer, escribir…), la empaqueta en un paquete llamado IRP (I/O Request Packet) y la entrega al controlador. La mayoría de las solicitudes a un controlador de dispositivo llegan como un IRP.³ Como los dispositivos no van a la misma velocidad que el sistema operativo (un disco es órdenes de magnitud más lento que la CPU), se optó por convertir la solicitud en un «paquete» en lugar de una «llamada», de modo que la emisión y la finalización se puedan separar.²

Además de una cabecera con la información global de la solicitud, el IRP contiene tantas áreas llamadas ubicaciones de pila de E/S como controladores por los que está previsto que pase. Cada controlador lee «las instrucciones dirigidas a él» (el código de función mayor y sus parámetros) desde su propia ubicación de pila.¹⁷

4.2. Bajando por la pila de dispositivos

Los objetos dispositivo se apilan y forman la pila de dispositivos.¹⁸ Por ejemplo, una lectura de un archivo en un disco local recorre, a grandes rasgos, el siguiente camino.

flowchart TB
    IOM["El Administrador de E/S arma el IRP<br/>(IRP_MJ_READ + ubicación de pila)"]
    subgraph FSSTACK["Pila del lado del sistema de archivos"]
        FLT["Filtro del sistema de archivos<br/>(antivirus, cifrado, Procmon, etc.)"]
        NTFS["NTFS<br/>convierte el desplazamiento dentro del archivo en una posición del volumen"]
    end
    subgraph STSTACK["Pila del lado del almacenamiento"]
        VOL["Gestión de volumen/partición<br/>(volmgr, etc.)"]
        DISK["Controlador de clase de disco<br/>(disk.sys)"]
        PORT["Puerto de almacenamiento/miniport<br/>(storport, etc.)"]
    end
    HW[("Dispositivo de disco")]
    IOM --> FLT
    FLT --> NTFS
    NTFS --> VOL
    VOL --> DISK
    DISK --> PORT
    PORT --> HW

Figura 4: el camino que recorre una solicitud de lectura. El lado del sistema de archivos y el lado del almacenamiento son pilas de dispositivos separadas, y NTFS encarga el trabajo emitiendo un nuevo IRP subordinado dirigido a la pila de almacenamiento

De este diagrama hay dos cosas que conviene recordar.

1. El filtro es un habitante legítimo. Que un antivirus pueda inspeccionar toda la E/S de archivos no es un truco: este mecanismo de «insertarse en medio» es un punto de extensión oficial del sistema operativo.¹⁹ Process Monitor se sitúa en el mismo lugar y registra toda la E/S. Es también el primer sospechoso al investigar por qué «el acceso a archivos solo es lento en ese entorno» (los detalles, en la sexta entrega).
2. El significado de la solicitud se traduce en cada capa. La aplicación dice «8 KB a partir del desplazamiento 4096 de este archivo»; NTFS lo traduce a «este clúster de este volumen», y la pila de almacenamiento, a «este sector de este disco». Las capas superiores no conocen los asuntos internos de las inferiores. Aquí hay una precisión importante: un mismo IRP no llega de la aplicación al disco tal cual, sin cambios. El lado del sistema de archivos y el del almacenamiento son pilas separadas, y NTFS, como resultado de procesar el IRP dirigido al archivo, crea y emite un nuevo IRP subordinado dirigido al volumen (la pila de almacenamiento). Si el archivo está fragmentado, una sola lectura puede dividirse en varios IRP subordinados, y tanto la granularidad como la vida útil de la solicitud cambian de capa en capa.

4.3. Las tres opciones de cada controlador

Lo que puede hacer un controlador que recibe un IRP se reduce, en esencia, a tres opciones.³¹⁰

flowchart TB
    RECV["El controlador recibe el IRP"]
    Q{"¿Cómo tratar esta solicitud?"}
    DONE["(1) Completarlo por sí mismo<br/>llama a IoCompleteRequest<br/>ej.: responde de inmediato con datos en caché"]
    PASS["(2) Pasarlo al dispositivo inferior<br/>llama a IoCallDriver<br/>ej.: un filtro lo inspecciona y lo deja pasar"]
    PEND["(3) Dejarlo pendiente<br/>devuelve STATUS_PENDING y encola el IRP<br/>ej.: espera de respuesta del hardware"]
    LATER["Más tarde, a raíz de una interrupción u otro evento,<br/>se llama a IoCompleteRequest"]
    UP["El procesamiento de finalización sube la pila en orden inverso<br/>(se invoca la rutina de finalización de cada capa)"]
    RECV --> Q
    Q --> DONE
    Q --> PASS
    Q --> PEND
    PASS -->|"la capa inferior lo completó en el acto"| UP
    PASS -->|"la capa inferior lo dejó pendiente<br/>(lo pendiente se propaga hasta el llamador)"| LATER
    PEND --> LATER
    DONE --> UP
    LATER --> UP

Figura 5: las tres opciones de un controlador que recibe un IRP. No son excluyentes entre sí; el camino más habitual es «pasarlo hacia abajo y que quede pendiente allí», y todas terminan, al final, en una finalización mediante IoCompleteRequest

Cabe aclarar que estas tres opciones no son mutuamente excluyentes. El camino más común es que, al pasarlo hacia abajo con la opción (2), alguna capa más adelante elija la opción (3) y lo deje pendiente; en ese caso, STATUS_PENDING se propaga tal cual tanto a los controladores intermedios como al llamador original. Cuando la capa inferior lo completa más tarde, cada capa que había registrado una rutina de finalización al pasarlo hacia abajo es invocada de nuevo en orden inverso; es decir, «pasar» y «dejar pendiente» ocurren superpuestos sobre un mismo y único IRP.

Esta triple opción es la fuente de la flexibilidad de la E/S de Windows.

• Si hay un acierto de caché, se completa de inmediato y resulta rápido (el Administrador de caché, en la cuarta entrega).
• Se pueden insertar tantos filtros como se quiera que dejen pasar la solicitud (los minifiltros, en la sexta entrega).
• Como se puede dejar pendiente, no hace falta bloquear un subproceso mientras se espera a un dispositivo lento (la E/S asíncrona, en la segunda y la tercera entrega).

En realidad, todo el resto de la serie no es más que una nota al pie de este diagrama.

5. Siguiendo un viaje completo de ReadFile

Con los protagonistas y las herramientas ya presentados, sigamos de principio a fin un único viaje de ReadFile. Es el caso en que se falla la caché y hay que llegar hasta el disco (el caso en que se acierta en la caché se tratará en la cuarta entrega).

sequenceDiagram
    participant App as Subproceso de la aplicación
    participant IOM as Administrador de E/S
    participant FS as Filtro + NTFS
    participant ST as Pila de almacenamiento
    participant HW as Dispositivo de disco

    App->>IOM: ReadFile → NtReadFile (llamada al sistema)
    Note over IOM: Resuelve el objeto archivo a partir del identificador<br/>y arma el IRP (IRP_MJ_READ)
    IOM->>FS: IoCallDriver (hacia la cima de la pila)
    FS->>ST: Traduce la posición al volumen<br/>y emite un IRP subordinado dirigido a la pila de almacenamiento
    ST->>HW: Emite el comando de lectura
    ST-->>FS: STATUS_PENDING (el IRP subordinado queda pendiente)
    FS-->>IOM: El IRP original también vuelve pendiente<br/>(aquí termina la ida)
    Note over App: E/S síncrona: aquí se duerme esperando la finalización<br/>E/S asíncrona: el control vuelve y puede hacer otro trabajo
    HW-->>ST: Interrupción — se terminó de leer los datos
    Note over ST: Desde la rutina de interrupción (ISR)<br/>el procesamiento de finalización continúa en un DPC
    ST->>FS: Completa el IRP subordinado (IoCompleteRequest)<br/>la rutina de finalización del lado de NTFS lo recibe
    Note over FS: Cuando todos los IRP subordinados<br/>necesarios se completan
    FS->>IOM: Completa el IRP original (IRP_MJ_READ)
    Note over IOM: Ejecuta en orden inverso la rutina de finalización de cada capa<br/>y confirma el resultado mediante un APC al subproceso solicitante
    IOM->>App: Se confirman el estado y el número de bytes (mediante notificación de evento, etc.)

Figura 6: un viaje completo de ReadFile cuando falla la caché. La finalización del IRP subordinado y la del IRP original son pasos distintos, y la «ida» y la «vuelta» avanzan también como eventos separados

5.1. La ida y la vuelta son sucesos distintos

El punto clave de este diagrama es la línea de STATUS_PENDING. En el momento en que el controlador de almacenamiento emite el comando al hardware, suelta el control, y el procesamiento de «ida» termina ahí. Que los datos ya se han leído se notifica después mediante un evento distinto, una interrupción, y a partir de ahí comienza el procesamiento de finalización de la «vuelta».¹⁰

Es decir, dentro del núcleo la emisión y la finalización de la E/S están diseñadas para poder separarse. No existe una tubería aparte llamada «E/S síncrona»: el significado exacto de la E/S síncrona es la garantía de que la llamada no retorna antes de completarse. La espera solo ocurre cuando la solicitud queda pendiente; si el controlador puede completar la solicitud en el acto (el camino de «completar» de la figura 5), incluso con E/S síncrona el subproceso vuelve con el resultado sin dormirse ni una sola vez. Que Win32 alterne entre síncrono y asíncrono según la forma de abrir el identificador (FILE_FLAG_OVERLAPPED) se debe justamente a que lo asíncrono no es una «función adicional especial», sino una diferencia en la forma de esperar.¹¹

Con esta perspectiva, las preguntas que se tratarán en la segunda entrega —por qué lo asíncrono o no se decide al abrir el identificador y no en cada llamada (aunque la propia estructura OVERLAPPED sí es necesaria para cada operación en curso), y qué significa que «algo que debería ser asíncrono se complete de forma síncrona»— se revelan como una consecuencia inevitable del mecanismo. La razón por la que, con async/await de .NET, la espera de E/S no consume un subproceso (tema que se trató desde el lado práctico en «Tabla de decisiones prácticas de async/await en C#») también se fundamenta en este diagrama.

5.2. También hay una excepción — el atajo que no crea un IRP

Para ser honestos, hay que añadir que no toda E/S se convierte en un IRP. Para la lectura y escritura síncronas de un archivo que está en caché, el sistema de archivos ofrece un atajo llamado E/S rápida (fast I/O), que «copia directamente desde la caché sin llegar a armar un IRP». Son las líneas que en la columna Operation de Procmon empiezan por FASTIO_. Las condiciones en las que no se puede usar este atajo y su relación con el Administrador de caché se tratarán en la cuarta entrega.

6. Detrás de CloseHandle — cleanup y close son cosas distintas

Por último, cómo se cierra lo que se abrió. Este punto está directamente relacionado con la investigación de fugas de identificadores y con el problema del «archivo en uso».

Lo que hace CloseHandle es eliminar una entrada de la tabla de identificadores del proceso. El objeto archivo tiene un contador de identificadores (handle count, el número de identificadores) y un contador de referencias (reference count, el número de referencias desde dentro del núcleo), y ambos disminuyen por separado.

sequenceDiagram
    participant App as Aplicación
    participant OB as Administrador de objetos
    participant IOM as Administrador de E/S
    participant FS as Sistema de archivos

    App->>OB: CloseHandle(h)
    Note over OB: Elimina la entrada de la tabla de identificadores<br/>y reduce el contador de identificadores
    alt Era el último identificador
        IOM->>FS: IRP_MJ_CLEANUP
        Note over FS: Cancela la E/S sin completar<br/>y libera los bloqueos de ese objeto archivo
    end
    Note over OB: Pero si quedan referencias dentro del núcleo,<br/>como E/S sin completar o secciones (mapeo en memoria),<br/>el objeto archivo sigue vivo
    alt El contador de referencias también llegó a cero
        IOM->>FS: IRP_MJ_CLOSE
        Note over FS: Terminan los últimos trámites del objeto archivo<br/>solo aquí se ha 'terminado de cerrar'
    end

Figura 7: las dos etapas — cleanup (se cerró el último identificador) y close (desaparecieron también todas las referencias)

• IRP_MJ_CLEANUP es la notificación de que «se cerró el último identificador». Sin embargo, la propia documentación aclara que, si quedan operaciones de E/S sin completar, es posible que el objeto archivo todavía no se libere.¹²
• IRP_MJ_CLOSE es la notificación de que «el contador de referencias llegó a cero». Entre cleanup y close puede haber un intervalo; no siempre uno sigue inmediatamente al otro.¹³

Conocer estas dos etapas permite explicar varios misterios del día a día.

• El archivo no se libera aunque se cierre un archivo mapeado en memoria. Esto ocurre porque la sección mapeada sigue manteniendo una referencia al objeto archivo, y el close no llega hasta que se desasigna la vista y se cierra la sección. La práctica en torno a la memoria compartida se trató en «Trampas de la memoria compartida y buenas prácticas en la práctica».
• Buscar al culpable de un «archivo en uso» no termina solo con los identificadores. Aunque se hayan cerrado todos los identificadores, puede haber referencias dentro del núcleo (como imágenes mapeadas) reteniendo el archivo. Precisamente por eso, la búsqueda de Process Explorer abarca tanto los identificadores como las DLL (archivos mapeados).
• Tampoco conviene confiar en que SafeFileHandle o el finalizador de .NET «lo cerrarán eventualmente», porque un identificador que se olvidó cerrar retrasa el cleanup y prolonga las infracciones de uso compartido o la retención de bloqueos.

7. Compruébelo con sus propios ojos

Todo lo visto hasta aquí se puede observar con un único PC con Windows en el que se disponga de privilegios de administrador.

Solo hacen falta tres cosas.

• Privilegios de administrador. Process Monitor necesita ejecutarse como administrador porque carga un controlador del núcleo. En WinObj también hay objetos que no se ven sin permisos de administrador.
• Las herramientas de Sysinternals. Microsoft distribuye WinObj y Process Monitor de forma gratuita. Se pueden obtener desde sus páginas de descarga individuales (WinObj, Process Monitor), o bien instalarlas todas juntas con el Sysinternals Suite. No requieren instalador: basta con descomprimir y ejecutar el exe.
• Alguna operación sencilla para observar. Basta con guardar un archivo desde el Bloc de notas o copiar un archivo pequeño. Pruébelo en su disco local, no en una carpeta compartida de trabajo ni en una máquina de producción.

Ver el espacio de nombres con WinObj. Al iniciar WinObj de Sysinternals y abrir el directorio GLOBAL??, se muestra directamente que C: es un vínculo simbólico hacia \Device\HarddiskVolumeN (figura 1). Bajo \Device se pueden ver los nombres reales de los objetos dispositivo que crean los controladores.¹⁴

Leer el vocabulario del IRP en Procmon. Al activar Filter > Enable Advanced Output en el menú de Process Monitor, la columna Operation deja de mostrar ReadFile y pasa a mostrar el vocabulario del lado del núcleo: IRP_MJ_READ, FASTIO_READ, etc. Con solo seguir la copia de un archivo, aparece de forma literal el flujo de este artículo: IRP_MJ_CREATE → FASTIO_READ/IRP_MJ_READ → IRP_MJ_WRITE → IRP_MJ_CLEANUP → IRP_MJ_CLOSE. El uso práctico de Procmon está recopilado en «Guía práctica de Process Monitor (ProcMon)».

Tener presente el fondo desde .NET. El FileStream de C# llama internamente a CreateFileW y conserva el identificador como SafeFileHandle. El parámetro FileOptions del constructor se traslada de forma casi directa a las marcas de Win32.

A partir de .NET 6, con File.OpenHandle y la clase RandomAccess también es posible escribir código sin pasar por la abstracción de FileStream, más cercano a la forma original de Win32 de «identificador + E/S con desplazamiento explícito». Si se entiende el significado de la columna derecha de esta tabla, la elección de la columna izquierda deja de ser memorización.

8. Resumen

• La E/S de Windows está regida por un único diseño: determinar el destino (el objeto dispositivo) en el espacio de nombres del Administrador de objetos, empaquetar la solicitud en un IRP y hacerla fluir por la pila de dispositivos.²³¹⁸
• C: es un vínculo simbólico, \\.\ designa directamente el lugar de los nombres, y UNC se resuelve al redirector. La verdadera naturaleza de «todo se ve como un archivo» es la coherencia de la resolución de nombres.⁴⁵
• Los protagonistas son tres: el objeto driver (tabla de funciones de procesamiento), el objeto dispositivo (destino) y el objeto archivo (estado de una apertura). El HANDLE es una referencia al objeto archivo.⁶⁷⁸⁹
• El controlador tiene tres opciones: completar, dejar pasar o dejar pendiente. Tanto la intercepción de un filtro como la respuesta inmediata de la caché o la E/S asíncrona son aplicaciones de esta triple opción.³¹⁰
• La emisión y la finalización están diseñadas para poder separarse, y la E/S síncrona es la garantía de que «no se retorna antes de completarse». En una solicitud que queda pendiente, la ida (emisión) y la vuelta (interrupción → finalización) avanzan como eventos distintos.¹¹¹⁰
• CloseHandle solo «devuelve un identificador». Si se conocen las dos etapas, cleanup (el último identificador) y close (la última referencia), el «cerrado pero en uso» deja de ser un misterio.¹²¹³

La continuación es la segunda entrega, «E/S síncrona y asíncrona — el verdadero significado de OVERLAPPED». Ahí se profundizará en el mecanismo que permite usar desde el lado de la aplicación la «separación de emisión y finalización» vista en este artículo: FILE_FLAG_OVERLAPPED, los cuatro métodos de notificación de finalización, la cancelación y la trampa de «algo que debería ser asíncrono pero vuelve de forma síncrona».

Artículos relacionados

• Guía práctica de Process Monitor (ProcMon) — identifique en 10 minutos «no se lee la configuración» o «ACCESS DENIED»
• Process Explorer / Handle / VMMap en la práctica — seguir cuelgues, fugas y «archivo en uso» desde el estado del momento
• Investigación de una falla tras un funcionamiento prolongado de una cámara industrial - parte de la fuga de identificadores
• Conceptos básicos del control de exclusión en la integración de archivos - buenas prácticas de bloqueo de archivos y claim atómico
• Trampas de la memoria compartida y buenas prácticas en la práctica
• Tabla de decisiones prácticas de async/await en C# - Task.Run y ConfigureAwait
• Trampas de las unidades de red y las rutas UNC — la práctica de trabajar con servidores de archivos (carpetas compartidas) en aplicaciones empresariales
• MAX_PATH y las trampas de rutas y nombres de archivo en Windows — el límite de 260 caracteres, nombres reservados, puntos finales y mayúsculas/minúsculas

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa del diseño y la investigación de fallos en torno a la E/S de archivos de aplicaciones empresariales de Windows (fugas de identificadores, «archivo en uso», lentitud de E/S en entornos específicos, entre otros).

• Desarrollo de aplicaciones Windows
• Investigación de fallos y análisis de causas
• Aprovechamiento de activos existentes y apoyo a la migración
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Qué es un IRP?

El IRP (I/O Request Packet, paquete de solicitud de E/S) es el paquete que el Administrador de E/S del núcleo de Windows utiliza para empaquetar las solicitudes de lectura y escritura de las aplicaciones, entre otras, y entregarlas a los controladores de dispositivo. La documentación de Microsoft para desarrollo de controladores explica que la mayoría de las solicitudes enviadas a un controlador de dispositivo se empaquetan como un IRP. El IRP contiene un código de función mayor que indica el tipo de solicitud (creación, lectura, escritura, limpieza, etc.) y una ubicación de pila por cada controlador por el que pasa, y se procesa mientras se transmite de arriba hacia abajo por la pila de dispositivos. Cada controlador elige entre completar el IRP por sí mismo, pasarlo al controlador inferior o dejarlo pendiente para completarlo más tarde. Los desarrolladores de aplicaciones nunca manipulan un IRP directamente, pero notaciones como IRP_MJ_READ, que aparecen en la columna Operation de Process Monitor, son precisamente este mecanismo.

¿Por qué en Windows se pueden abrir archivos, puertos serie e impresoras con la misma función CreateFile?

Porque todo nombre pasado a CreateFile sigue el mismo camino: se resuelve, en última instancia, a un objeto de dispositivo dentro del espacio de nombres del Administrador de objetos, y el Administrador de E/S crea un objeto de archivo asociado a ese dispositivo y devuelve un identificador (handle). La letra de unidad C:, por ejemplo, es en realidad un vínculo simbólico a un nombre de dispositivo NT como \Device\HarddiskVolume3, y una designación como \\.\COM1 se resuelve del mismo modo al objeto de dispositivo del puerto serie. Sea cual sea el dispositivo al que se resuelve, toda solicitud posterior llega al controlador empaquetada en el mismo formato, el IRP, de modo que tanto archivos como dispositivos pueden abrirse y leerse o escribirse con la misma API. Las rutas UNC siguen el mismo mecanismo: simplemente se resuelven al dispositivo del redirector de red. Este diseño de «espacio de nombres + paquete» es, en realidad, la clave de la coherencia de la E/S de Windows.

¿Por qué a veces un archivo no se libera de inmediato aunque se haya llamado a CloseHandle?

Porque lo que hace CloseHandle es «devolver un identificador», no «cerrar el archivo». El objeto de archivo dentro del núcleo mantiene dos contadores independientes: el número de identificadores abiertos (handle count) y el número de referencias desde componentes del núcleo (reference count). Cuando se cierra el último identificador, el sistema de archivos recibe un IRP_MJ_CLEANUP, pero mientras queden referencias vivas dentro del núcleo —por ejemplo, E/S sin completar o secciones de archivos mapeados en memoria—, el objeto de archivo en sí sigue existiendo, y solo cuando el contador de referencias llega a cero se envía el IRP_MJ_CLOSE. Buena parte de los fenómenos como no poder eliminar un archivo después de haberlo usado como archivo mapeado en memoria, o que la aplicación se cierre y aun así aparezca el mensaje de que «el archivo está en uso», se explican por este mecanismo en dos etapas.

¿De qué le sirve a un desarrollador de aplicaciones conocer el IRP y la pila de dispositivos?

Aunque nunca vaya a escribir un IRP directamente, este conocimiento ayuda tanto en la investigación como en el diseño. En primer lugar, la columna Operation de Process Monitor (con la salida detallada activada) muestra exactamente la terminología de los IRP, como IRP_MJ_CREATE o IRP_MJ_READ, así que conocer el vocabulario de esta capa permite leer sus registros. En segundo lugar, al saber que controladores de filtro como los antivirus se insertan en el camino de toda E/S de archivos, se puede orientar mejor la investigación de un problema como «el acceso a archivos solo es lento en cierto entorno». Además, al entender que la E/S de Windows está diseñada para separar la emisión de la finalización, y que la E/S síncrona no es más que la garantía de «no retornar antes de completarse», resulta natural comprender y usar con criterio la E/S asíncrona, los puertos de finalización de E/S y el comportamiento de async/await en .NET.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.