Les profondeurs de l'I/O Windows (partie 6, dernière partie) — Pilotes filtres et minifiltres : pourquoi Procmon et les antivirus peuvent intercepter vos E/S

Ceci est le dernier volet de la série « Les profondeurs de l’I/O Windows ».

Depuis que la partie 1 a dessiné, dans le schéma de la pile de périphériques, une case intitulée « filtre de système de fichiers (antivirus, chiffrement, Procmon, etc.) », ceux qui s’insèrent entre les couches n’ont cessé de refaire surface tout au long de cette série. La raison pour laquelle Procmon peut enregistrer toutes les E/S (partie 1). « L’accès aux fichiers n’est lent que dans cet environnement-là » (partie 2). Le point d’analyse qui fait démarrer un téléchargement OneDrive dès l’instant où il est ouvert (partie 5). Cette fois, nous nous attaquons enfin de front au mécanisme même de cette intercalation — les pilotes de filtre de système de fichiers et les minifiltres — et refermons toutes les intrigues laissées en suspens par la série.

1. La conclusion, d’abord

• « S’immiscer dans les E/S » est un point d’extension officiellement reconnu par l’OS. Un filtre de système de fichiers peut observer, réécrire, refuser ou traiter à la place une requête adressée au système de fichiers (chapitre 2).¹
• Le standard actuel, ce sont les minifiltres. Pour résoudre les problèmes de la méthode héritée qui s’insérait directement dans la pile de périphériques (ordre non garanti, déchargement impossible), la génération suivante enregistre désormais des rappels auprès du Filter Manager (FltMgr) fourni avec Windows (chapitre 2).²³
• Le mécanisme repose sur des rappels pre/post. Avant et après chaque opération, ils sont appelés dans l’ordre d’enregistrement, c’est-à-dire par ordre d’altitude. Laisser passer, compléter, refuser, réécrire — les « choix du pilote » vus dans la partie 1 s’appliquent tels quels (chapitre 3).²
• L’altitude détermine l’ordre. Des plages de numéros sont attribuées par groupe d’usage (Activity Monitor : 360000-389999, Anti-Virus : 320000-329999, etc.), et un numéro unique est attribué à chaque instance attachée à un volume (chapitre 4).⁴⁵
• Les résidents de votre PC se voient avec fltmc. Procmon (seulement pendant son exécution), l’antivirus, le filtre cloud de OneDrive — tous apparaissent ici, côte à côte (chapitre 5).
• L’exclusion configurée dans un antivirus signifie « omettre le scan de ce produit lui-même » et n’affecte aucun autre minifiltre. L’exclusion est un compromis qui affaiblit la protection ; pour les volumes de développement, Dev Drive (scan asynchrone) offre une option plus sûre (chapitre 6).⁶⁷
• L’investigation de « ça ne rame que dans cet environnement » part de la colonne Duration de Procmon et de la comparaison de la composition avec fltmc (chapitre 7).

2. L’histoire de ceux qui s’insèrent — des filtres hérités à FltMgr

Un pilote de filtre de système de fichiers est un pilote capable d’intercepter les requêtes adressées au système de fichiers (ou au volume qui se trouve en dessous). Il peut enregistrer une requête, la surveiller, en modifier le contenu, et même la refuser ou la traiter à sa place — c’est le socle de logiciels comme les antivirus, le chiffrement, la sauvegarde ou la gestion hiérarchisée du stockage.¹

L’ancienne méthode d’implémentation (les filtres hérités) consistait à empiler directement son propre objet périphérique sur la pile de périphériques vue dans la partie 1. Le mécanisme était simple, mais posait en pratique toutes sortes de problèmes : l’ordre d’empilement dépendait de l’ordre de chargement et était donc difficile à garantir, il n’était pas possible de se retirer une fois empilé (pas de déchargement possible), et cela devenait un terreau fertile pour des bugs d’incompatibilité entre filtres.

Windows a donc introduit le Filter Manager (FltMgr). FltMgr lui-même se tient dans la pile en tant que filtre fourni avec l’OS, et chaque fonctionnalité de filtre s’implémente comme un minifiltre qui enregistre des rappels auprès de FltMgr.²

flowchart TB
    subgraph OLD["Méthode héritée"]
        L1["Filtre hérité A"]
        L2["Filtre hérité B"]
        LFS1["Système de fichiers"]
        L1 --> L2
        L2 --> LFS1
        NOTE1["Ordre laissé au hasard du chargement<br/>Déchargement sûr impossible"]
    end
    subgraph NEW["Méthode minifiltre (standard actuel)"]
        FM["Filter Manager (FltMgr)<br/>Fourni avec l'OS. Seul lui se tient dans la pile"]
        M1["Minifiltre A (altitude haute)"]
        M2["Minifiltre B (altitude basse)"]
        LFS2["Système de fichiers"]
        FM -. "Enregistrement de rappel" .- M1
        FM -. "Enregistrement de rappel" .- M2
        FM --> LFS2
        NOTE2["Ordre déterminé de façon déterministe par l'altitude<br/>Chargement possible à tout moment<br/>(le déchargement aussi, pour les filtres compatibles)"]
    end

Figure 1 : le changement de génération. On passe de la méthode « empiler » sur la pile à la méthode « enregistrer » auprès de FltMgr

Les avantages du modèle minifiltre sont officiellement documentés — on peut le charger à tout moment, contrôler l’ordre, et même décharger un filtre en cours de fonctionnement s’il implémente un rappel de déchargement (un filtre qui ne l’implémente pas, ou qui le refuse, ne peut pas être retiré).³ Pour coexister avec les filtres hérités, FltMgr peut se tenir à plusieurs endroits de la pile sous forme de plusieurs « frames », et un minifiltre a la garantie de revenir à la même position (la même altitude) même après un déchargement suivi d’un rechargement.² Pratiquement tous les logiciels antivirus, de surveillance et de synchronisation actuels sont des minifiltres.

3. Le fonctionnement des minifiltres — les rappels pre/post

Un minifiltre déclare à FltMgr « quelles opérations l’intéressent ». Par exemple, il peut ne s’intéresser qu’à IRP_MJ_CREATE (ouvrir) et IRP_MJ_WRITE (écrire). Ensuite, chaque fois que l’une de ces opérations circule, le rappel pre (avant l’opération) et le rappel post (après l’opération) sont appelés.

sequenceDiagram
    participant IOM as Gestionnaire d'E/S
    participant FM as FltMgr
    participant A as Minifiltre A<br/>(altitude haute)
    participant B as Minifiltre B<br/>(altitude basse)
    participant FS as NTFS

    IOM->>FM: Requête (IRP_MJ_CREATE, etc. — le monde de la partie 1)
    FM->>A: rappel pre
    FM->>B: rappel pre
    FM->>FS: Vers le système de fichiers
    FS-->>FM: Résultat du traitement
    FM-->>B: rappel post
    FM-->>A: rappel post
    FM-->>IOM: Achèvement (retour au déroulement de complétion de la partie 1)

Figure 2 : les rappels pre/post. À l’aller, l’appel se fait par ordre d’altitude décroissante ; au retour, dans l’ordre inverse

Que peut-on faire dans chaque rappel ? On retrouve la même structure que les « trois choix du pilote » de la section 4.3 de la partie 1, mais offerte via une API plus sûre.

flowchart TB
    PRE["Le rappel pre a été appelé"]
    Q{"Que faire de cette opération ?"}
    PASS["Laisser passer<br/>(déclarer aussi que le post n'est pas nécessaire, le cas échéant)"]
    DENY["Refuser<br/>Retourner immédiatement un accès refusé, etc.<br/>ex. : détection de virus, écriture interdite"]
    DONE["Compléter soi-même<br/>ex. : un filtre cloud récupère<br/>le contenu réel et le fournit"]
    MOD["Modifier les paramètres ou le contenu avant de laisser passer<br/>ex. : filtre de chiffrement"]
    PRE --> Q
    Q --> PASS
    Q --> DENY
    Q --> DONE
    Q --> MOD

Figure 3 : les choix du rappel pre. « Observer, arrêter, se substituer, réécrire » sont tous possibles officiellement

Et c’est ici que se referme un fil laissé en suspens depuis la partie 4 — les minifiltres assistent aussi au fast I/O (le raccourci qui ne crée pas d’IRP). C’est parce que FltMgr fait aussi passer son mécanisme de rappel par le chemin du fast I/O, si bien que l’ère héritée où « emprunter le raccourci le rendait invisible » n’existe plus. C’est grâce à cette position que les journaux de Procmon affichent aussi des lignes FASTIO_.

4. L’altitude — le « niveau » qui détermine l’ordre

Lorsque plusieurs filtres s’intéressent à la même opération, qui la voit en premier est une question cruciale. Si l’antivirus ne la voit pas avant le chiffrement, il finit par scanner du texte chiffré ; et un outil de surveillance ne peut observer l’ensemble que s’il se trouve au-dessus de tous les autres.

C’est l’altitude qui détermine cet ordre. Un groupe d’ordre de chargement et une plage de numéros sont définis pour chaque type de filtre. Pour être précis, l’unité à laquelle une altitude est attachée n’est pas le pilote dans son ensemble, mais l’« instance » du minifiltre attachée à un volume. Le numéro est unique, et plus il est élevé, plus l’instance se situe haut dans la pile (côté application).⁴ Un même pilote peut définir plusieurs instances et apparaître à des altitudes différentes ; c’est pourquoi la liste de fltmc instances est organisée par instance.

flowchart TB
    APP["Côté application (nombres élevés)"]
    G1["FSFilter Activity Monitor : 360000-389999<br/>Observation et enregistrement des E/S (Procmon est ici)"]
    G2["FSFilter Undelete : 340000-349999<br/>Restauration de fichiers supprimés"]
    G3["FSFilter Anti-Virus : 320000-329999<br/>Détection et suppression de virus"]
    G4["FSFilter Replication : 300000-309999<br/>Réplication vers un site distant"]
    G5["FSFilter Continuous Backup : 280000-289999<br/>Sauvegarde continue"]
    G6["Plus bas encore : les bandes Content Screener /<br/>Quota Management / System Recovery /<br/>chiffrement, compression, etc. se poursuivent"]
    FS["Côté système de fichiers (nombres faibles)"]
    APP --> G1 --> G2 --> G3 --> G4 --> G5 --> G6 --> FS

Figure 4 : les plages d’altitude (extrait). Chaque usage a un « niveau où se tenir » qui lui est propre

Ce qui compte, c’est que ce numéro est attribué et géré par Microsoft.⁵ Un éditeur ne le choisit pas librement : il en fait la demande et le reçoit — c’est ce qui garantit, sur n’importe quel PC, l’ordre « la surveillance au-dessus de l’antivirus, l’antivirus au-dessus du chiffrement ». C’est la réponse apportée à la « loterie de l’ordre de chargement » de l’ère héritée.

Où faire la demande si vous développez vous-même un minifiltre. À l’intention des développeurs, voici juste la marche à suivre. Pour l’altitude, suivez la procédure décrite dans Request a Filter Altitude Identifier et envoyez une demande par e-mail en anglais à fsfcomm@microsoft.com, avec pour objet « Filter altitude request ». Vous devez y indiquer le nom de la société, un contact (un alias d’entreprise utilisable sur le long terme, pas une personne), le nom du produit, l’URL du produit, une description du filtre, le nom de fichier du pilote, le type de filtre, le type de démarrage, ainsi que le groupe d’ordre de chargement et l’altitude souhaités. Il est précisé qu’il faut compter environ 30 jours ouvrés de traitement, qu’il n’existe pas de guichet pour un traitement en urgence, et que le numéro attribué peut différer de celui demandé.⁸ Notez qu’une société qui possède déjà une altitude entière dans le même groupe d’ordre de chargement peut elle-même choisir une valeur décimale ajoutée à ce numéro (par exemple 325000.3), auquel cas il suffit d’en informer Microsoft par e-mail après coup.⁸

5. Présentation des résidents — votre PC vu par fltmc

Assez de théorie : passons au concret. Dans une invite de commandes avec des droits administrateur :

:: Liste des minifiltres enregistrés (avec leur altitude)
fltmc

:: Quels filtres sont attachés à quel volume
fltmc instances

:: Vu du côté des volumes
fltmc volumes

fltmc sans argument affiche la même liste que fltmc filters. La sortie comporte 4 colonnes, et la documentation Microsoft présente un exemple dans le même format.⁹

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

Ce qui précède est un extrait à but explicatif. La liste des noms et le nombre d’instances varient selon l’environnement, mais les valeurs d’altitude sont des valeurs fixes attribuées par Microsoft, on peut donc les recouper avec la liste publique évoquée au chapitre 4.

Voici ce que signifient les colonnes.

Rien qu’avec ces cinq lignes, on constate que bindflt et cldflt se trouvent dans la bande FSFilter Top la plus haute (400000-409999), WdFilter dans la bande Anti-Virus (320000-329999), et FileInfo dans la bande FSFilter Bottom la plus basse (40000-49999). La structure « chaque usage a un niveau où se tenir » vue au chapitre 4 se vérifie ainsi directement dans les chiffres. Et si vous relancez fltmc après avoir démarré Procmon, une ligne supplémentaire commençant par PROCMON apparaît dans la bande Activity Monitor (360000-389999).

La liste varie selon l’environnement, mais les résidents typiques sont tous des habitués de cette série.

• WdFilter — le minifiltre de Microsoft Defender. Il se trouve dans la bande Anti-Virus. Sur la plupart des PC, c’est un poste de contrôle par lequel passe forcément toute E/S de fichier.
• cldflt — le filtre de fichiers cloud. C’est l’exécutant de la fonction « fichiers à la demande » de OneDrive, qui prépare le contenu réel lorsqu’un point d’analyse (un espace réservé) vu dans la partie 5 est ouvert.¹⁰
• PROCMON24 (ou similaire) — un minifiltre temporaire de la bande Activity Monitor, qui n’apparaît que pendant l’exécution de Process Monitor. C’est là le secret qui permet à Procmon de voir toutes les E/S.¹¹ Essayez d’exécuter fltmc avant et après son démarrage pour comparer.
• Il y a aussi les logiciels de sauvegarde, les produits de chiffrement (prévention des fuites d’information), l’EDR, le stockage virtualisé, etc. — plus le PC est destiné à un usage professionnel, plus la population de résidents s’étoffe.

En reconsidérant, dans ce dernier volet, l’outil Procmon utilisé depuis la partie 1 — mais cette fois depuis l’extérieur de la boîte à outils —, on obtient une belle boucle : « l’observateur était lui aussi un résident du même mécanisme que ce qu’il observait ».

6. Où l’antivirus consomme-t-il du temps ?

Le plus grand impact pratique des filtres est le coût du scan antivirus. Voici, sous forme de schéma, où ce temps est dépensé (les détails varient selon le produit ; ce qui suit est une forme typique).

sequenceDiagram
    participant App as Application
    participant AV as Minifiltre AV
    participant FS as NTFS

    App->>AV: Ouvrir un fichier
    Note over AV: pre-create : décision préalable sur le chemin ou la politique
    AV->>FS: Laisser passer (exécution de l'ouverture)
    FS-->>AV: Ouverture établie (post-create)
    Note over AV: Si le fichier n'a pas encore été scanné,<br/>le contenu est scanné ici<br/>et l'ouverture est annulée en cas de problème<br/>— principale cause de la lenteur à l'ouverture
    AV-->>App: Le handle est retourné si tout est en ordre
    App->>AV: Écriture, fermeture
    Note over AV: Les fichiers modifiés deviennent candidats<br/>à un nouveau scan, par exemple à la fermeture
    Note over App,FS: Pour un grand nombre de petits fichiers<br/>(fichiers intermédiaires de build, etc.),<br/>cet aller-retour s'accumule autant de fois qu'il y a de fichiers

Figure 5 : où le coût du scan se produit. Négligeable par fichier, il devient dominant dès qu’il y en a des dizaines de milliers

Cela posé, deux sujets pratiques peuvent maintenant être compris avec précision.

Le sens technique d’une exclusion. Pour une E/S dont le chemin correspond à la liste d’exclusion, le traitement de scan du filtre est omis. Le filtre ne disparaît pas de la pile ; ce qui se passe réellement, c’est que la décision « ne pas inspecter » intervient plus tôt. Et il y a une autre limite importante à connaître — une exclusion n’agit que sur le filtre du produit qui porte ce réglage lui-même. L’exclusion de Microsoft Defender ne change que le scan de WdFilter, et n’a strictement aucun effet sur le fonctionnement des autres minifiltres coexistant sur la machine (antivirus d’un autre éditeur, EDR, sauvegarde, chiffrement, etc.). Si « c’est resté lent malgré l’ajout d’une exclusion », soupçonnez qu’un autre résident consomme du temps (voir la comparaison fltmc du chapitre 7). L’effet est important, mais une exclusion affaiblit à coup sûr la protection à cet endroit. La documentation Microsoft avertit elle aussi, à plusieurs reprises, qu’une exclusion réduit la défense et doit donc rester minimale, après évaluation du risque.⁶ Le côté pratique de la gestion des faux positifs et de l’impact sur les performances est traité dans « Quand votre application Windows maison est signalée comme un virus ».

Dev Drive, une nouvelle réponse. C’est un volume dédié conçu pour les charges de travail de développement (un grand nombre de petits fichiers), sur lequel Microsoft Defender fonctionne en mode performance (scan asynchrone). Il est positionné comme une alternative plus sûre à l’exclusion de dossiers : par défaut, aucun filtre supplémentaire ne s’y attache, mais un avertissement ferme est aussi formulé contre le fait de retirer complètement tous les filtres pour l’exploiter.⁷ C’est la solution actuellement recommandée par Microsoft pour répondre à « je veux accélérer mes builds, mais l’exclusion me fait peur ».

7. La méthode d’investigation pour « ça ne rame que dans cet environnement »

Pour finir, rassemblons en une seule procédure les outils accumulés au fil de la série.

flowchart TB
    S["Symptôme : la même application, mais l'accès aux fichiers<br/>n'est lent que dans un environnement particulier"]
    P1["Regarder la colonne Duration dans Procmon<br/>pour voir quelle opération (IRP_MJ_CREATE ? WRITE ?)<br/>consomme le temps"]
    Q1{"Une opération particulière est-elle uniformément lente ?"}
    F1["Comparer fltmc instances avec un environnement rapide<br/>pour voir la différence de composition des filtres"]
    Q2{"La différence de filtre en est-elle la cause ?"}
    A1["Envisager l'exclusion (avec évaluation du risque)<br/>ou Dev Drive, ou consulter le fournisseur"]
    A2["Soupçonner autre chose que les filtres :<br/>le cache (partie 4), la fragmentation ou la MFT (partie 5),<br/>la destination réseau (UNC), le périphérique lui-même"]
    S --> P1 --> Q1
    Q1 -->|"Oui"| F1 --> Q2
    Q2 -->|"Oui"| A1
    Q2 -->|"Non"| A2
    Q1 -->|"Non (sporadique)"| A2

Figure 6 : isoler une lenteur causée par un filtre. La clé réside dans « le temps consommé par opération » et « la différence de composition des filtres entre environnements »

Il y a deux points clés. Premièrement, Procmon dispose d’un temps consommé (Duration) pour chaque opération. Décomposer « c’est lent » en « quelle opération est lente » accomplit déjà la moitié de l’enquête. Deuxièmement, la différence entre environnements est souvent une différence de composition des filtres. Machine de développement contre machine de production, PC interne contre PC chez le client — il suffit de mettre côte à côte les sorties de fltmc pour voir apparaître les candidats à suspecter.

Les trois premiers gestes si vous n’avez jamais touché à Procmon. La colonne Duration n’est pas affichée par défaut ; voici donc, pour ne pas rester bloqué ici, simplement la marche à suivre.

1. Lancez Procmon.exe en tant qu’administrateur.
2. Ouvrez Options > Select Columns… et cochez Duration dans la liste des colonnes.
3. Dans Filter > Filter… (Ctrl+L), saisissez Process Name / is / le nom de l’exe visé / Include, puis cliquez sur le bouton Add avant de valider avec OK (sans cliquer sur Add, la condition n’est pas prise en compte).

Cliquez ensuite sur l’en-tête de la colonne Duration pour trier : les opérations les plus coûteuses en temps remontent en haut. Pour une agrégation par processus ou par fichier, Tools > File Summary est également utile. L’ensemble des manipulations de ProcMon est réuni dans « Guide pratique de Process Monitor (ProcMon) ».

8. Le bouquet final de la série — la carte des 6 volets

Nous avons maintenant ouvert toutes les cases de la carte dessinée dans la partie 1. Rassemblons le tout en une seule image.

flowchart TB
    APP["Application<br/>ReadFile / WriteFile / async-await"]
    API["Partie 2 : E/S synchrones et asynchrones<br/>Mode du handle et OVERLAPPED"]
    IOCP["Partie 3 : IOCP et pool de threads .NET<br/>Réception de l'achèvement et exécution de la continuation"]
    IOM["Partie 1 : Gestionnaire d'E/S et IRP<br/>Résolution de noms, trois objets, pile de périphériques"]
    FLT["Partie 6 : Filtres et minifiltres<br/>FltMgr, altitude, pre/post"]
    CACHE["Partie 4 : Gestionnaire de cache<br/>Vues de 256 Ko, lazy writer, fast I/O<br/>(fonctionne en coopération avec NTFS)"]
    NTFS["Partie 5 : NTFS<br/>MFT, flux, liens, deux journaux"]
    HW["Pile de stockage et périphériques"]
    APP --> API
    API --> IOM
    IOCP -. "L'achèvement revient ici" .-> APP
    IOM --> FLT
    FLT --> NTFS
    NTFS -. "L'E/S mise en cache est coopérative<br/>(le système de fichiers appelle la fonction de cache)" .- CACHE
    NTFS --> HW
    HW -. "Interruption → achèvement (partie 1)" .-> IOCP

Figure 7 : la carte complète de la série. Le gestionnaire de cache n’est pas une « couche que l’on traverse » mais un partenaire qui coopère avec le système de fichiers ; en cas d’échec de cache, c’est NTFS qui émet la requête vers le stockage

• Partie 1 : la vue d’ensemble — chaque lecture et écriture devient un IRP
• Partie 2 : synchrone/asynchrone — ce que signifie vraiment OVERLAPPED
• Partie 3 : IOCP — le sous-sol d’async/await
• Partie 4 : le cache — quand votre WriteFile atteint-il réellement le disque ?
• Partie 5 : NTFS — comprendre le système de fichiers à travers la MFT
• Partie 6 : filtres et minifiltres (cet article) — pourquoi Procmon et le scan antivirus peuvent s’immiscer dans les E/S

9. Conclusion — le mot de la fin pour cette série

Voici le résumé de ce dernier volet.

• S’immiscer dans les E/S est un point d’extension officiellement reconnu par l’OS, et le standard actuel consiste à enregistrer des rappels auprès de FltMgr (les minifiltres). L’ordre est déterminé de façon déterministe par l’altitude, dont les numéros sont attribués et gérés par Microsoft.²⁴⁵
• Le mécanisme repose sur des rappels pre/post. On peut laisser passer, refuser, se substituer ou réécrire, et l’on assiste aussi au fast I/O. Procmon, Defender et OneDrive sont tous des résidents de ce même mécanisme.¹¹¹¹⁰
• Une exclusion équivaut à omettre le scan, ce qui constitue un compromis avec la protection. Pour les volumes de développement, Dev Drive (scan asynchrone) offre une option plus sûre.⁶⁷
• « Ça ne rame que dans cet environnement » s’isole à partir de la Duration de Procmon et de la différence de composition révélée par fltmc — les outils de la série deviennent directement la méthode d’investigation.

Et si l’on devait résumer la conclusion de toute la série en une seule phrase, ce serait celle-ci — l’E/S de Windows est une conception cohérente, où la destination se détermine dans un espace de noms, où la requête circule entre les couches sous forme de paquet (l’IRP), et où chaque couche peut choisir d’« observer, de prendre en charge ou de se substituer ». Sous une simple ligne File.ReadAllText, cette structure en six volets est à l’œuvre à chaque fois. Plutôt que de mémoriser le comportement d’une API, pouvoir déduire de cette carte que « cela doit se comporter ainsi » — c’est précisément la compétence que cette série a voulu vous transmettre. Merci de nous avoir accompagnés tout au long de ce long voyage.

Articles connexes

• Les profondeurs de l’I/O Windows (partie 1) — Chaque lecture et écriture devient un IRP : la vue d’ensemble du système d’E/S
• Les profondeurs de l’I/O Windows (partie 4) — Le gestionnaire de cache : quand votre WriteFile atteint-il réellement le disque ?
• Les profondeurs de l’I/O Windows (partie 5) — Structure interne de NTFS : comprendre le système de fichiers à travers la MFT
• Guide pratique de Process Monitor (ProcMon) — identifier en 10 minutes un « paramètre non pris en compte » ou un ACCESS DENIED
• Quand votre application Windows maison est signalée comme un virus — gérer les faux positifs de Microsoft Defender et composer avec l’impact sur les performances
• Process Explorer / Handle / VMMap en pratique — suivre les blocages, fuites et « fichier en cours d’utilisation » à partir de l’état de cet instant précis
• Liste de contrôle minimale de sécurité pour le développement d’applications Windows

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge l’investigation des problèmes de performance et des bugs liés aux pilotes de filtre dans les applications métier Windows, comme « c’est lent uniquement dans un environnement particulier » ou « le logiciel de sécurité interfère avec notre application ».

• Développement d’applications Windows
• Investigation de bugs et analyse des causes
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Quelle est la différence entre un pilote de filtre de système de fichiers et un minifiltre ?

Les deux sont des « pilotes qui s'immiscent dans les requêtes d'E/S adressées au système de fichiers », mais la façon dont ils s'immiscent appartient à des générations différentes. L'ancien filtre hérité empilait directement son propre objet périphérique sur la pile de périphériques du système de fichiers ; sa position dépendait de l'ordre de chargement, ce qui rendait l'ordre difficile à garantir, et il posait des problèmes comme l'impossibilité de le décharger en toute sécurité une fois chargé. Le minifiltre, standard actuel, fonctionne en enregistrant auprès du Filter Manager (FltMgr) fourni avec Windows un rappel demandant « d'être appelé avant et après cette opération ». Sa position est déterminée de façon déterministe par un numéro appelé altitude, il peut être chargé à n'importe quel moment, et un filtre qui implémente un rappel de déchargement peut même être retiré en cours de fonctionnement. Les antivirus, le chiffrement, les outils de surveillance, la synchronisation cloud et pratiquement tous les filtres modernes sont aujourd'hui implémentés comme des minifiltres.

Pourquoi un antivirus peut-il inspecter tous les accès aux fichiers ?

Parce que l'OS prévoit officiellement un point d'extension à cet effet. Un minifiltre peut enregistrer auprès du Filter Manager du code appelé avant (rappel pre) et après (rappel post) des opérations comme ouvrir, lire ou écrire un fichier. Le filtre d'un antivirus se situe dans la bande d'altitude Anti-Virus (320000-329999) et peut, par exemple, scanner le contenu juste après que l'ouverture du fichier a été établie (post-create), puis annuler cette ouverture pour faire échouer l'accès si un problème est détecté. Comme on l'a vu dans la partie 1 de la série, toute E/S de fichier circule le long de la pile de périphériques : se tenir à une position fixe sur ce chemin permet donc d'inspecter tous les accès. Ce n'est pas un détournement, mais un mécanisme intégré à la conception même de l'OS.

Que fait techniquement une exclusion (exclusion de dossier) configurée dans un antivirus ?

Elle fait omettre le traitement de scan effectué par le filtre de ce produit pour les E/S dont le chemin correspond à la liste d'exclusion. Le filtre lui-même ne disparaît pas de la pile ; la compréhension la plus proche de la réalité est que la décision « ne pas inspecter ce chemin » intervient plus tôt. Une limite importante : l'exclusion n'agit que sur le produit qui porte ce réglage lui-même. Par exemple, une exclusion configurée dans Microsoft Defender ne change que le scan du filtre de Defender (WdFilter), et n'affecte le fonctionnement d'aucun autre minifiltre coexistant, comme l'antivirus d'un autre éditeur, un EDR ou une sauvegarde. Une exclusion propre à chaque produit est nécessaire, et si « c'est resté lent malgré l'exclusion », un autre filtre peut en être la cause. De plus, comme la documentation Microsoft le rappelle à plusieurs reprises, une exclusion affaiblit la protection à cet endroit et doit donc rester minimale, en s'accompagnant d'une évaluation du risque. Pour un usage de développement, il vaut aussi la peine d'envisager Dev Drive (mode performance = scan asynchrone), conçu comme une alternative sûre à l'exclusion de dossiers.

Comment Process Monitor enregistre-t-il l'intégralité des E/S ?

Parce que Procmon lui-même s'enregistre, au démarrage, auprès du Filter Manager comme un minifiltre appartenant à la bande d'altitude Activity Monitor (surveillance d'activité). Si vous exécutez fltmc depuis une invite de commandes administrateur pendant que Procmon est lancé, vous pouvez constater qu'un filtre dont le nom commence par PROCMON apparaît dans la liste. En tant que minifiltre, il assiste aux rappels pre/post de toutes les opérations d'E/S sur tous les volumes, ce qui lui permet d'enregistrer sans exception quel processus a effectué quelle opération sur quel fichier. Si le vocabulaire des IRP et du fast I/O vu tout au long de la série apparaît tel quel dans l'affichage de Procmon, c'est précisément parce qu'il observe depuis une position située sur le chemin même emprunté par les E/S.

Faut-il soupçonner un pilote de filtre quand le build est lent sur une machine de développement ?

Cela vaut largement la peine d'être soupçonné. Un build est un amas de créations, de lectures, d'écritures et de suppressions d'un grand nombre de petits fichiers, dont chacune devient une cible d'inspection pour l'ensemble des filtres (en particulier le scan antivirus) : c'est donc la charge de travail où le coût des filtres se manifeste le plus facilement. La procédure de base consiste à examiner la colonne Duration dans Procmon pour voir sur quelle opération le temps est consommé, puis à comparer, avec fltmc instances, la différence de composition des filtres entre les environnements. Comme contre-mesures, on peut citer l'exclusion après évaluation du risque, ainsi que l'utilisation de Dev Drive, un volume conçu spécifiquement pour le développement. Sur Dev Drive, l'antivirus fonctionne en mode performance (scan asynchrone), une alternative que Microsoft positionne comme plus sûre que l'exclusion.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.