Las profundidades del I/O en Windows (6.ª entrega, final) ── Controladores de filtro y minifiltros: por qué Procmon y el análisis antivirus pueden interceptar el I/O

Última entrega de la serie «Las profundidades del I/O en Windows».

Desde que en la primera entrega dibujamos, en el diagrama de la pila de dispositivos, un recuadro llamado «filtro del sistema de archivos (antivirus, cifrado, Procmon, etc.)», los que se interponen en el camino han ido asomando una y otra vez a lo largo de esta serie. La razón por la que Procmon puede registrar todo el I/O (primera entrega). «El acceso a archivos solo es lento en ese entorno» (segunda entrega). El punto de reanálisis (reparse point) que hace que OneDrive empiece a descargar en el instante en que se abre un archivo (quinta entrega). En esta entrega abordamos por fin de frente ese propio mecanismo de interposición —los controladores de filtro del sistema de archivos y los minifiltros— y recogemos todos los cabos sueltos de la serie.

1. La conclusión, antes que nada

• «Interceptar el I/O» es un punto de extensión reconocido oficialmente por el sistema operativo. Un filtro del sistema de archivos puede ver, reescribir, denegar o procesar en su lugar las solicitudes dirigidas al sistema de archivos (capítulo 2). ¹
• El estándar actual son los minifiltros. Para resolver los problemas del modelo heredado que se interponía directamente en la pila de dispositivos (orden indeterminado, imposibilidad de descargarlo), el diseño evolucionó hacia el registro de callbacks en el Filter Manager (FltMgr) incluido en Windows (capítulo 2). ²³
• El funcionamiento se basa en callbacks pre/post. Se invocan antes y después de cada operación, en el orden de registro, es decir, por orden de altitude. Dejar pasar, completar, denegar o reescribir: las «opciones del controlador» que vimos en la primera entrega se aplican tal cual (capítulo 3). ²
• La altitude («altura») determina el orden. A cada grupo según su finalidad se le asigna una banda numérica (Activity Monitor 360000-389999, Anti-Virus 320000-329999, etc.), y cada instancia adjunta a un volumen recibe un número único (capítulo 4). ⁴⁵
• Los «habitantes» de su PC se pueden ver con fltmc. Procmon (solo mientras está en ejecución), el antivirus, el filtro de nube de OneDrive: todos aparecen en esta lista (capítulo 5).
• La configuración de exclusiones del antivirus significa «omitir el análisis de ese producto en concreto» y no afecta a otros minifiltros. Excluir implica una contrapartida que debilita la protección; para los volúmenes de desarrollo existe una opción más segura: Dev Drive (análisis asíncrono) (capítulo 6). ⁶⁷
• La investigación de «solo ese entorno va lento» parte de la columna Duration de Procmon y de la comparación de la configuración con fltmc (capítulo 7).

2. Historia de los que se interponen — de los filtros heredados a FltMgr

Un controlador de filtro del sistema de archivos es un controlador capaz de interceptar las solicitudes dirigidas al sistema de archivos (o al volumen subyacente). Puede registrar solicitudes, monitorizarlas, modificar su contenido e incluso denegarlas o procesarlas en su lugar; es la base de software como los antivirus, el cifrado, las copias de seguridad o el almacenamiento jerárquico. ¹

El modelo de implementación más antiguo (los filtros heredados, o legacy) consistía en apilar el propio objeto de dispositivo directamente en la pila de dispositivos que vimos en la primera entrega. Como mecanismo es sencillo, pero en la práctica estaba plagado de problemas: el orden de apilamiento dependía del orden de carga y era difícil de garantizar; una vez apilado, no se podía retirar de forma segura (no se podía descargar); y era un caldo de cultivo para errores de incompatibilidad entre filtros.

Por eso Windows introdujo el Filter Manager (FltMgr). El propio FltMgr se sitúa en la pila como filtro incluido en el sistema operativo, mientras que cada funcionalidad de filtrado individual registra callbacks en FltMgr en forma de minifiltro. ²

flowchart TB
    accTitle: Del modelo de filtros heredados al modelo de minifiltros
    accDescr: Comparación entre el modelo heredado, donde los filtros se apilan directamente en la pila de dispositivos con orden dependiente de la carga y sin descarga segura, y el modelo de minifiltros, donde el Filter Manager (FltMgr) es lo único que se sitúa en la pila y los minifiltros registran callbacks con orden determinista según la altitude y posibilidad de carga y descarga en cualquier momento
    subgraph OLD["Modelo heredado"]
        L1["Filtro heredado A"]
        L2["Filtro heredado B"]
        LFS1["Sistema de archivos"]
        L1 --> L2
        L2 --> LFS1
        NOTE1["El orden depende de la carga<br/>No se puede descargar de forma segura"]
    end
    subgraph NEW["Modelo de minifiltros (estándar actual)"]
        FM["Filter Manager (FltMgr)<br/>Incluido en el SO. Es lo único que se sitúa en la pila"]
        M1["Minifiltro A (altitude alta)"]
        M2["Minifiltro B (altitude baja)"]
        LFS2["Sistema de archivos"]
        FM -. "Registro de callbacks" .- M1
        FM -. "Registro de callbacks" .- M2
        FM --> LFS2
        NOTE2["El orden es determinista según la altitude<br/>Se puede cargar en cualquier momento<br/>(los filtros compatibles también se pueden descargar)"]
    end

Figura 1: El cambio de generación. De «apilarse» en la pila a «registrarse» en FltMgr

Las ventajas del modelo de minifiltros están enumeradas oficialmente: se pueden cargar en cualquier momento, se puede controlar el orden y, si el filtro implementa un callback de descarga, incluso se puede descargar mientras el sistema está en funcionamiento (los filtros que no lo implementan o que rechazan la descarga no se pueden retirar). ³ Para convivir con los filtros heredados, FltMgr puede situarse en varios puntos de la pila en forma de múltiples «frames», y se garantiza que un minifiltro, al volver a cargarse tras ser descargado, regresa a la misma posición (la misma altitude). ² Prácticamente todo el software moderno de antivirus, monitorización y sincronización es, hoy en día, un minifiltro.

3. Cómo funciona un minifiltro — los callbacks pre/post

Un minifiltro declara ante FltMgr «en qué operaciones está interesado». Por ejemplo, puede declarar que solo le interesan IRP_MJ_CREATE (abrir) e IRP_MJ_WRITE (escribir). A partir de ahí, cada vez que fluye una de esas operaciones, se invoca antes de la operación (callback pre) y después de la operación (callback post).

sequenceDiagram
    accTitle: Secuencia de los callbacks pre/post entre el Administrador de I/O, FltMgr, los minifiltros y NTFS
    accDescr: Diagrama de secuencia que muestra cómo el Administrador de I/O envía una solicitud a FltMgr, que invoca el callback pre de cada minifiltro en orden de altitude descendente antes de pasar la solicitud a NTFS, y luego invoca el callback post de cada minifiltro en orden inverso antes de devolver la finalización al Administrador de I/O
    participant IOM as Administrador de I/O
    participant FM as FltMgr
    participant A as Minifiltro A<br/>(altitude alta)
    participant B as Minifiltro B<br/>(altitude baja)
    participant FS as NTFS

    IOM->>FM: Solicitud (IRP_MJ_CREATE, etc. El mundo de la 1.ª entrega)
    FM->>A: Callback pre
    FM->>B: Callback pre
    FM->>FS: Hacia el sistema de archivos
    FS-->>FM: Resultado del procesamiento
    FM-->>B: Callback post
    FM-->>A: Callback post
    FM-->>IOM: Completado (hacia el flujo de finalización de la 1.ª entrega)

Figura 2: Los callbacks pre/post. A la ida se llaman en orden de altitude descendente; a la vuelta, en orden inverso

¿Qué se puede hacer en cada callback? Se ofrece el mismo esquema que las «tres opciones del controlador» del apartado 4.3 de la primera entrega, pero con una API más segura.

flowchart TB
    accTitle: Las cuatro opciones disponibles en el callback pre de un minifiltro
    accDescr: Diagrama que muestra que, tras invocarse el callback pre, el minifiltro puede elegir entre dejar pasar la operación, denegarla, completarla él mismo o modificar sus parámetros o contenido antes de dejarla continuar
    PRE["Se invocó el callback pre"]
    Q{"¿Qué hacer con esta operación?"}
    PASS["Dejarla pasar<br/>(si tampoco necesita post, también se declara)"]
    DENY["Denegarla<br/>Devuelve de inmediato acceso denegado, etc.<br/>Ejemplo: detección de virus, escritura prohibida"]
    DONE["Completarla uno mismo<br/>Ejemplo: un filtro de nube<br/>obtiene el contenido real y lo entrega"]
    MOD["Modificar parámetros o contenido y dejarla continuar<br/>Ejemplo: filtro de cifrado"]
    PRE --> Q
    Q --> PASS
    Q --> DENY
    Q --> DONE
    Q --> MOD

Figura 3: Las opciones del callback pre. «Ver, detener, sustituir y reescribir» son todas posibles de forma oficial

Y aquí se resuelve la tarea pendiente de la cuarta entrega: los minifiltros también pueden estar presentes en Fast I/O (el atajo que no crea un IRP). Esto es posible porque FltMgr hace pasar el mecanismo de callbacks también por la ruta de Fast I/O, por lo que no ocurre, como en la época heredada, que «si pasan por el atajo, no se ven». El hecho de que en el registro de Procmon aparezcan incluso líneas FASTIO_ se debe precisamente a esta posición privilegiada.

4. Altitude — la «altura» determina el orden

Cuando varios filtros están interesados en la misma operación, quién la ve primero es una cuestión crítica. Si el antivirus no la ve antes que el cifrado, terminará escaneando texto cifrado; y si una herramienta de monitorización no está por encima de todos los demás, no podrá observar el conjunto.

Quien determina este orden es la altitude («altura» o «altitud»). Para cada tipo de filtro se definen un grupo de orden de carga (load order group) y una banda numérica. Para ser precisos, la altitude no se asigna al controlador en su conjunto, sino a la «instancia» del minifiltro adjunta a un volumen. El número es único, y cuanto mayor es, más arriba se sitúa en la pila (más cerca de la aplicación). ⁴ Un mismo controlador puede tener varias definiciones de instancia y aparecer en distintas altitudes; por eso el listado de fltmc instances está organizado por instancia.

flowchart TB
    accTitle: Bandas de altitude de los grupos de orden de carga de minifiltros
    accDescr: Diagrama que ordena de arriba a abajo, de mayor a menor altitude, los grupos FSFilter Activity Monitor, FSFilter Undelete, FSFilter Anti-Virus, FSFilter Replication, FSFilter Continuous Backup y bandas adicionales más cercanas al sistema de archivos, mostrando que cada finalidad tiene asignada una altura determinada
    APP["Más cerca de la aplicación (número mayor)"]
    G1["FSFilter Activity Monitor: 360000-389999<br/>Observación y registro de I/O (aquí está Procmon)"]
    G2["FSFilter Undelete: 340000-349999<br/>Recuperación de archivos eliminados"]
    G3["FSFilter Anti-Virus: 320000-329999<br/>Detección y eliminación de virus"]
    G4["FSFilter Replication: 300000-309999<br/>Replicación remota"]
    G5["FSFilter Continuous Backup: 280000-289999<br/>Copia de seguridad continua"]
    G6["Más abajo: Content Screener /<br/>Quota Management / System Recovery /<br/>y siguen bandas de cifrado, compresión, etc."]
    FS["Más cerca del sistema de archivos (número menor)"]
    APP --> G1 --> G2 --> G3 --> G4 --> G5 --> G6 --> FS

Figura 4: Bandas de altitude (extracto). A cada finalidad le corresponde una «altura» determinada

Lo importante es que este número lo asigna y administra Microsoft. ⁵ Los proveedores no lo eligen libremente, sino que lo solicitan y reciben una asignación; por eso, en cualquier PC se mantiene el orden «la monitorización va por encima del antivirus, y el antivirus por encima del cifrado». Esta fue la respuesta a la «lotería del orden de carga» de la época heredada.

Dónde solicitarla si va a desarrollar su propio minifiltro. Para los desarrolladores, dejamos anotado solo el siguiente paso. La altitude se solicita siguiendo el procedimiento de Request a Filter Altitude Identifier, enviando un correo en inglés a fsfcomm@microsoft.com con el asunto «Filter altitude request». Es necesario completar todos los datos: nombre de la empresa, contacto (un alias de empresa de uso prolongado, no una persona individual), nombre del producto, URL del producto, descripción del filtro, nombre de archivo del controlador, tipo de filtro, tipo de inicio, y el grupo de orden de carga y la altitude deseados. También se indica expresamente que hay que prever unos 30 días hábiles de trámite, que no existe una vía de urgencia, y que el número asignado puede diferir del solicitado. ⁸ Además, una empresa que ya tenga una altitude entera dentro del mismo grupo de orden de carga puede decidir por su cuenta un valor con decimales a partir de ese número (por ejemplo, 325000.3), en cuyo caso basta con notificarlo por correo a posteriori. ⁸

5. Presentación de los habitantes — su PC visto con fltmc

Dejemos la teoría por ahora y veamos algo real. Desde un símbolo del sistema con privilegios de administrador:

:: Lista de minifiltros registrados (con su altitude)
fltmc

:: Qué filtros están adjuntos a cada volumen
fltmc instances

:: Verlo desde el lado del volumen
fltmc volumes

fltmc sin argumentos muestra el mismo listado que fltmc filters. La salida tiene 4 columnas, y la documentación de Microsoft incluye un ejemplo con el mismo formato. ⁹

C:\Windows\system32>fltmc

Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------  ------------  -----
bindflt                                 1        409800         0
cldflt                                  1        409500         0
WdFilter                                4        328010         0
luafv                                   1        135000         0
FileInfo                                4         45000         0

El listado anterior es un extracto con fines explicativos. Los nombres que aparecen y el número de instancias varían según el entorno, pero como los valores de altitude son valores fijos asignados por Microsoft, se pueden contrastar con el listado público mencionado en el capítulo 4.

Estas son las columnas.

Con estas cinco líneas ya se puede ver que bindflt y cldflt están en la banda superior FSFilter Top (400000-409999), WdFilter en la banda Anti-Virus (320000-329999) y FileInfo en la banda inferior FSFilter Bottom (40000-49999). El esquema que vimos en el capítulo 4 —«a cada finalidad le corresponde una altura determinada»— se confirma directamente con estos números. Y si vuelve a ejecutar fltmc después de iniciar Procmon, aparecerá una línea adicional cuyo nombre empieza por PROCMON en la banda de Activity Monitor (360000-389999).

Los nombres varían según el entorno, pero los habitantes típicos son, en su mayoría, viejos conocidos de esta serie.

• WdFilter — el minifiltro de Microsoft Defender. Se sitúa en la banda Anti-Virus. En muchos PCs es el puesto de control por el que pasa obligatoriamente todo el I/O de archivos.
• cldflt — el filtro de archivos en la nube. Es el brazo ejecutor de Files On-Demand de OneDrive, y prepara el contenido real cuando se abre el punto de reanálisis (el marcador de posición, o placeholder) que vimos en la quinta entrega. ¹⁰
• PROCMON24 (u otro similar) — un minifiltro temporal en la banda de Activity Monitor que solo aparece mientras Process Monitor está en ejecución. Este es el truco que le permite a Procmon ver todo el I/O. ¹¹ Pruebe a ejecutar fltmc antes y después de iniciarlo, y compare.
• Además, software de copia de seguridad, productos de cifrado (prevención de fugas de información), EDR, almacenamiento virtualizado, etc.: cuanto más corporativo es el PC, más habitantes suele tener.

Al volver a mirar, en esta última entrega, desde fuera de la caja de herramientas la herramienta llamada Procmon que hemos usado desde la primera entrega, se cierra un bonito círculo: «el observador también resultó ser un habitante más del mismo mecanismo que observaba».

6. Dónde consume tiempo el antivirus

El mayor impacto práctico de los filtros es el coste del análisis antivirus. Veamos en un diagrama dónde se genera ese tiempo (los detalles varían según el producto; lo que sigue es un caso típico).

sequenceDiagram
    accTitle: Dónde se genera el coste del análisis antivirus al abrir, escribir y cerrar un archivo
    accDescr: Diagrama de secuencia entre la aplicación, el minifiltro antivirus y NTFS que muestra la evaluación previa en pre-create, el análisis del contenido y la posible cancelación de la apertura en post-create si el archivo no ha sido analizado, y el reanálisis de los archivos modificados al cerrarlos, cuyo coste se acumula con una gran cantidad de archivos pequeños
    participant App as Aplicación
    participant AV as Minifiltro AV
    participant FS as NTFS

    App->>AV: Abrir archivo
    Note over AV: pre-create: evaluación previa de la ruta y la política
    AV->>FS: Dejar pasar (ejecutar la apertura)
    FS-->>AV: Apertura completada (post-create)
    Note over AV: Si el archivo no ha sido analizado,<br/>aquí se analiza su contenido<br/>y, si hay un problema, se cancela la apertura<br/>── causa principal de la lentitud al abrir
    AV-->>App: Si no hay problemas, se devuelve el handle
    App->>AV: Escribir y cerrar
    Note over AV: Los archivos modificados quedan<br/>pendientes de reanálisis, por ejemplo al cerrarlos
    Note over App,FS: Con una gran cantidad de archivos pequeños<br/>(como los productos intermedios de una compilación),<br/>este ida y vuelta se acumula por cada archivo

Figura 5: Dónde se genera el coste del análisis. Por archivo es mínimo, pero con decenas de miles de archivos se vuelve dominante

Con esto como base, se pueden entender con precisión dos temas prácticos.

El significado técnico de las exclusiones. En el I/O dirigido a rutas que coinciden con la lista de exclusión, se omite el procesamiento de análisis del filtro. El filtro no desaparece de la pila; lo que ocurre en realidad es que la decisión de «no inspeccionar» se toma antes. Y hay otra limitación importante: la exclusión solo surte efecto en el filtro del propio producto que la tiene configurada. La configuración de exclusiones de Microsoft Defender solo cambia el análisis de WdFilter, y no tiene ningún efecto sobre el comportamiento de otros minifiltros coexistentes (antivirus de otros fabricantes, EDR, copia de seguridad, cifrado, etc.). Cuando «sigue lento a pesar de haber añadido la exclusión», sospeche de que otro habitante está consumiendo el tiempo (la comparación con fltmc del capítulo 7). Aunque el efecto es considerable, las exclusiones debilitan de forma segura la protección de esa ubicación. La documentación de Microsoft también advierte repetidamente que, como las exclusiones reducen la defensa, deben mantenerse al mínimo tras una evaluación de riesgos. ⁶ Tratamos la respuesta práctica a los falsos positivos y su impacto en el rendimiento en «Cuando su aplicación de Windows es tratada como virus».

Dev Drive, la nueva respuesta. Es un volumen dedicado diseñado para cargas de trabajo de desarrollo (gran cantidad de archivos pequeños), en el que Microsoft Defender funciona en modo de rendimiento (análisis asíncrono). Se presenta como una alternativa más segura a la exclusión de carpetas: por defecto no se le adjuntan filtros adicionales, aunque también se advierte con firmeza contra operar retirando todos los filtros. ⁷ Es la solución que Microsoft recomienda actualmente para quienes quieren «acelerar la compilación, pero les da miedo excluir».

7. Procedimiento para investigar «solo ese entorno va lento»

Para terminar, reunimos en un único procedimiento las herramientas que hemos ido acumulando a lo largo de la serie.

flowchart TB
    accTitle: Procedimiento para aislar la lentitud de acceso a archivos causada por filtros
    accDescr: Diagrama de decisión que parte del síntoma de lentitud en un entorno concreto, revisa la columna Duration de Procmon para identificar la operación lenta, compara fltmc instances entre entornos para encontrar diferencias de filtros, y concluye en considerar exclusiones o Dev Drive si la diferencia de filtros es la causa, o sospechar de causas distintas a los filtros en caso contrario
    S["Síntoma: la misma aplicación es lenta<br/>en el acceso a archivos solo en un entorno concreto"]
    P1["Revisar la columna Duration en Procmon<br/>para ver en qué operación<br/>(¿IRP_MJ_CREATE? ¿WRITE?) se consume el tiempo"]
    Q1{"¿Es lenta de forma uniforme<br/>una operación concreta?"}
    F1["Comparar fltmc instances<br/>con un entorno rápido<br/>y ver las diferencias de configuración de filtros"]
    Q2{"¿La diferencia de filtros<br/>es la causa?"}
    A1["Configuración de exclusiones (con evaluación de riesgo)<br/>o considerar Dev Drive / consultar al proveedor"]
    A2["Sospechar de algo distinto a los filtros:<br/>caché (4.ª entrega), fragmentación o MFT (5.ª entrega),<br/>destino de red (UNC), el propio dispositivo"]
    S --> P1 --> Q1
    Q1 -->|"Sí"| F1 --> Q2
    Q2 -->|"Sí"| A1
    Q2 -->|"No"| A2
    Q1 -->|"No (esporádica)"| A2

Figura 6: Cómo aislar la lentitud causada por los filtros. La clave está en el «tiempo por operación» y en las «diferencias de configuración de filtros entre entornos»

Hay dos puntos clave. Primero, Procmon dispone del tiempo transcurrido (Duration) por cada operación. Si logra descomponer «es lento» en «qué operación es lenta», la búsqueda del culpable ya está a medio camino. Segundo, la diferencia entre entornos suele deberse a diferencias en la configuración de filtros. Máquina de desarrollo frente a producción, PC propio frente a PC del cliente: basta con poner en paralelo la salida de fltmc para que aparezcan los candidatos sospechosos.

Los primeros tres pasos si nunca ha usado Procmon. La columna Duration no se muestra por defecto, así que anotamos aquí solo las operaciones necesarias para no quedarse atascado.

1. Inicie Procmon.exe como administrador.
2. Abra menú Options > Select Columns… y marque Duration en la lista de columnas.
3. En menú Filter > Filter… (Ctrl+L), indique Process Name / is / el nombre del .exe en cuestión / Include, pulse el botón Add y después OK (si no pulsa Add, la condición no se aplicará).

Después, haga clic en la columna Duration para ordenar, y las operaciones que más tiempo consumen se agruparán arriba. Para totales por proceso o por archivo, también puede usar menú Tools > File Summary. El manejo general de ProcMon está recopilado en «Guía práctica de Process Monitor (ProcMon)».

8. El cierre de la serie — el mapa de las seis entregas

Con esto hemos abierto todos los recuadros del mapa que dibujamos en la primera entrega. Reunámoslo todo en una sola imagen.

flowchart TB
    accTitle: Mapa completo de las seis entregas de la serie Las profundidades del I/O en Windows
    accDescr: Diagrama que sitúa a la aplicación en la parte superior y muestra el recorrido a través del I/O síncrono y asíncrono, IOCP y el thread pool de .NET, el Administrador de I/O y el IRP, los filtros y minifiltros, NTFS en colaboración con el Cache Manager, y finalmente la pila de almacenamiento y el dispositivo, con la finalización volviendo a IOCP y de ahí a la aplicación
    APP["Aplicación<br/>ReadFile / WriteFile / async-await"]
    API["2.ª entrega: I/O síncrono y asíncrono<br/>Modos del handle y OVERLAPPED"]
    IOCP["3.ª entrega: IOCP y el thread pool de .NET<br/>Recepción de la finalización y ejecución de la continuación"]
    IOM["1.ª entrega: Administrador de I/O e IRP<br/>Resolución de nombres, los tres objetos, la pila de dispositivos"]
    FLT["6.ª entrega: Filtros y minifiltros<br/>FltMgr, altitude, pre/post"]
    CACHE["4.ª entrega: Cache Manager<br/>Vistas de 256 KB, lazy writer, Fast I/O<br/>(trabaja en colaboración con NTFS)"]
    NTFS["5.ª entrega: NTFS<br/>MFT, streams, enlaces, los dos journals"]
    HW["Pila de almacenamiento y dispositivo"]
    APP --> API
    API --> IOM
    IOCP -. "La finalización vuelve aquí" .-> APP
    IOM --> FLT
    FLT --> NTFS
    NTFS -. "El I/O con caché habilitada colabora<br/>(el sistema de archivos invoca la función de caché)" .- CACHE
    NTFS --> HW
    HW -. "Interrupción → finalización (1.ª entrega)" .-> IOCP

Figura 7: El mapa de toda la serie. El Cache Manager no es una «capa por la que se pasa», sino un compañero que colabora con el sistema de archivos; cuando hay un fallo de caché, NTFS emite la solicitud hacia el almacenamiento

• 1.ª entrega: Panorama general — toda lectura y escritura se convierte en un IRP
• 2.ª entrega: Síncrono/asíncrono — el verdadero significado de OVERLAPPED
• 3.ª entrega: IOCP — el sótano de async/await
• 4.ª entrega: Caché — cuándo llega su WriteFile al disco
• 5.ª entrega: NTFS — entender el sistema de archivos a partir de la MFT
• 6.ª entrega: Filtros y minifiltros (este artículo) — por qué Procmon y el análisis antivirus pueden interceptar el I/O

9. Resumen — a modo de cierre de la serie

Este es el resumen de la última entrega.

• Interceptar el I/O es un punto de extensión reconocido oficialmente por el sistema operativo, y el estándar actual es el registro de callbacks en FltMgr (minifiltros). El orden queda determinado de forma determinista por la altitude, cuyos números asigna y administra Microsoft. ²⁴⁵
• El funcionamiento se basa en los callbacks pre/post. Se puede dejar pasar, denegar, sustituir o reescribir, y también se está presente en Fast I/O. Procmon, Defender y OneDrive son todos habitantes de este mismo mecanismo. ¹¹¹¹⁰
• Una exclusión equivale a omitir el análisis, y es una contrapartida frente a la protección. Para los volúmenes de desarrollo existe una opción más segura: Dev Drive (análisis asíncrono). ⁶⁷
• «Solo ese entorno va lento» se aísla a partir de el Duration de Procmon y las diferencias de configuración de fltmc: las herramientas de la serie se convierten, tal cual, en el procedimiento de investigación.

Y si tuviéramos que resumir la conclusión de toda la serie en una sola línea, sería esta: el I/O de Windows es un diseño coherente en el que el destino se determina mediante un espacio de nombres, las solicitudes se convierten en paquetes (IRP) que fluyen entre capas, y cada capa puede elegir entre «ver, retener o sustituir». Bajo esa única línea que es File.ReadAllText funciona, cada vez, toda la estructura de estas seis entregas. En lugar de memorizar el comportamiento de las API, poder deducir «esto tiene que ser así» a partir de este mapa: eso es lo que esperábamos que se llevara de esta serie. Gracias por acompañarnos en este largo viaje.

Artículos relacionados

• Las profundidades del I/O en Windows (1.ª entrega) — Toda lectura y escritura se convierte en un IRP: panorama general del sistema de I/O
• Las profundidades del I/O en Windows (4.ª entrega) — Cache Manager: cuándo llega su WriteFile al disco
• Las profundidades del I/O en Windows (5.ª entrega) — La estructura interna de NTFS: entender el sistema de archivos a partir de la MFT
• Guía práctica de Process Monitor (ProcMon) — Identifique en 10 minutos «la configuración no se lee» o «ACCESS DENIED»
• Cuando su aplicación de Windows es tratada como virus — Cómo responder a los falsos positivos de Microsoft Defender y convivir con su impacto en el rendimiento
• Process Explorer / Handle / VMMap en la práctica — Rastree cuelgues, fugas y «el archivo está en uso» a partir del estado en este mismo instante
• Lista mínima de comprobaciones de seguridad para aplicaciones de Windows

Áreas de consultoría relacionadas

En KomuraSoft LLC nos encargamos de investigar problemas de rendimiento y fallos en aplicaciones empresariales de Windows relacionados con controladores de filtro, como «solo es lento en un entorno concreto» o «el software de seguridad interfiere con nuestra aplicación».

• Desarrollo de aplicaciones Windows
• Investigación de fallos y análisis de causas
• Consultoría técnica
• 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.

¿En qué se diferencian los controladores de filtro del sistema de archivos y los minifiltros?

Ambos son «controladores que interceptan las solicitudes de I/O dirigidas al sistema de archivos», pero pertenecen a generaciones distintas de interceptación. Los filtros heredados (legacy) más antiguos apilaban su propio objeto de dispositivo directamente en la pila de dispositivos del sistema de archivos; como la posición dependía del orden de carga, era difícil garantizar el orden, y una vez cargados no se podían descargar de forma segura, entre otros problemas. Los minifiltros, el estándar actual, registran callbacks en el Filter Manager (FltMgr) incluido en Windows, indicando «quiero que me llames antes y después de esta operación». La posición queda determinada de forma determinista por un número llamado altitude, se pueden cargar en cualquier momento y, si el filtro implementa un callback de descarga, incluso se pueden retirar mientras el sistema está en funcionamiento. Prácticamente todos los filtros modernos —antivirus, cifrado, herramientas de monitorización, sincronización en la nube— están implementados como minifiltros.

¿Por qué el software antivirus puede inspeccionar todos los accesos a archivos?

Porque el sistema operativo ofrece oficialmente un punto de extensión para ello. Un minifiltro puede registrar en el Filter Manager código que se invoca antes (callback pre) y después (callback post) de operaciones como abrir, leer o escribir un archivo. El filtro antivirus se sitúa en la banda de altitude reservada para Anti-Virus (320000-329999) y, por ejemplo, justo después de que se complete la apertura de un archivo (post-create), puede analizar su contenido y, si detecta un problema, cancelar esa apertura para que el acceso falle. Como vimos en la primera entrega de la serie, todo el I/O de archivos fluye por la pila de dispositivos, así que basta con situarse en un punto fijo de ese camino para poder inspeccionar todos los accesos. No es un truco: es un mecanismo integrado en el diseño del sistema operativo.

¿Qué hace técnicamente la configuración de exclusiones (exclusión de carpetas) del antivirus?

Hace que, para el I/O dirigido a rutas que coinciden con la lista de exclusión, el filtro de ese producto omita su procesamiento de análisis. El filtro en sí no desaparece de la pila; lo más cercano a la realidad es que la decisión de «esta ruta no se inspecciona» se toma en una etapa más temprana. Una limitación importante es que la exclusión solo surte efecto en el propio producto que tiene configurada esa exclusión. Por ejemplo, la configuración de exclusiones de Microsoft Defender solo cambia el análisis del filtro de Defender (WdFilter) y no afecta al comportamiento de otros minifiltros coexistentes, como el antivirus de otro fabricante, un EDR o una herramienta de copia de seguridad. Cada producto necesita su propia configuración de exclusiones, así que si «sigue lento a pesar de haber excluido», la causa puede estar en otro filtro. Además, como advierte repetidamente la documentación de Microsoft, las exclusiones debilitan la protección en esa ubicación, por lo que deben mantenerse al mínimo junto con una evaluación de riesgos. Para uso de desarrollo, también vale la pena considerar Dev Drive (modo de rendimiento = análisis asíncrono), diseñado como alternativa segura a la exclusión de carpetas.

¿Cómo registra Process Monitor absolutamente todo el I/O?

Porque el propio Procmon, al iniciarse, se registra en el Filter Manager como un minifiltro dentro de la banda de altitude de Activity Monitor (monitorización de actividad). Si ejecuta fltmc desde un símbolo del sistema con privilegios de administrador mientras Procmon está en ejecución, puede comprobar que aparece en la lista un filtro cuyo nombre empieza por PROCMON. Al estar presente como minifiltro en los callbacks pre/post de las operaciones de I/O de todos los volúmenes, puede registrar sin omisiones qué proceso realizó qué operación sobre qué archivo. Que términos como IRP o Fast I/O, vistos a lo largo de la serie, aparezcan tal cual en la interfaz de Procmon se debe precisamente a que observa desde el propio camino por el que discurre el I/O.

Si la compilación en una máquina de desarrollo es lenta, ¿hay que sospechar de los controladores de filtro?

Sí, merece la pena sospechar de ellos. Una compilación es un cúmulo de creación, lectura, escritura y eliminación de un gran número de archivos pequeños, y cada una de esas operaciones pasa por el conjunto de filtros (en especial el análisis antivirus), por lo que es la carga de trabajo en la que el coste de los filtros suele hacerse más evidente. El procedimiento básico de investigación consiste en revisar la columna Duration en Procmon para ver en qué operación se consume el tiempo, y comparar con fltmc instances las diferencias de configuración de filtros entre entornos. Como medidas, cabe considerar la configuración de exclusiones tras evaluar el riesgo, así como el uso de Dev Drive, diseñado específicamente para volúmenes de desarrollo. En Dev Drive, el antivirus funciona en modo de rendimiento (análisis asíncrono), y Microsoft lo presenta como una alternativa más segura que la configuración de exclusiones.

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.