Pourquoi les opérations sur fichiers sous /mnt/c sont-elles lentes dans WSL2 ?

Parce que l'accès depuis le noyau Linux de WSL2 au système de fichiers côté Windows passe par un partage de fichiers qui traverse une frontière d'OS. Les opérations sur le système de fichiers Linux (un disque virtuel ext4) sont rapides, donc la règle est de garder les fichiers de projet du même côté d'OS que les outils qui travaillent dessus.

Une utilisation mémoire importante du processus vmmem est-elle une fuite ?

Dans la plupart des cas, ce n'est pas une fuite. La mémoire de WSL2 croît et décroît avec l'usage, et la mémoire que les processus ont libérée est renvoyée à Windows sous le réglage pageReporting, qui est activé par défaut. Les pages de cache de fichiers, elles aussi, sont récupérées automatiquement par WSL actuel via autoMemoryReclaim dans .wslconfig (la valeur par défaut est dropCache). Dans les environnements où ces réglages ont été désactivés, ou sur un WSL plus ancien, la mémoire peut rester jusqu'à la sortie de la machine virtuelle ; dans ce cas, fixez une limite supérieure avec le réglage memory, ou renvoyez-la avec wsl --shutdown.

Comment Windows Sandbox peut-il démarrer un Windows complet à partir de quelques centaines de mégaoctets de disque ?

Grâce à un mécanisme appelé image de base dynamique. Il partage les fichiers d'OS immuables depuis le Windows déjà installé sur l'hôte, et conserve une copie propre du petit nombre de fichiers mutables. Cela lui permet d'assembler une image complète amorçable sans stocker une copie entière de Windows.

Les conteneurs sont-ils plus sûrs que les machines virtuelles ?

Cela dépend du mode d'isolation. Les conteneurs à isolation de processus partagent le noyau avec l'hôte, et Microsoft ne considère pas ceci comme une frontière de sécurité robuste. Lorsque vous manipulez du code adverse, vous avez besoin de l'isolation Hyper-V, qui donne à chaque conteneur son propre noyau dédié.

Les profondeurs de la virtualisation Windows (partie 3) — Des machines virtuelles qui démarrent en quelques secondes : pourquoi WSL2, Windows Sandbox et les conteneurs sont si légers

22 Aug 2026 04:00 · Go Komura · Windows, Virtualisation, WSL2, Windows Sandbox, Conteneurs, Hyper-V

Lorsque vous créez une machine virtuelle Windows dans le Gestionnaire Hyper-V, elle met des dizaines de secondes à démarrer et monopolise plusieurs gigaoctets de mémoire. Pourtant, sur le même PC, taper wsl renvoie un interpréteur Linux en quelques secondes, et Windows Sandbox ouvre aussi un bureau jetable en quelques secondes.¹

Les deux reposent sur le même hyperviseur Windows (partie 1, « Où s’exécute réellement votre Windows ? »). Dans la partie 2, nous avons vu que ce fondement peut créer une isolation plus forte que le noyau. Alors pourquoi l’un est-il lourd et l’autre léger ?

La question à laquelle le dernier volet de la série répond n’est qu’une.

Les machines virtuelles complètes sont lourdes — alors pourquoi WSL2 et Windows Sandbox sont-ils si légers ?

Le public visé est constitué des développeurs et des opérateurs qui utilisent WSL2, Windows Sandbox et les conteneurs Windows pour le développement et la validation, et veulent comprendre leur légèreté et leurs contraintes depuis les mécanismes. Les prérequis sont Windows 10/11 ; parcourir la section Windows Sandbox exige une édition Pro, Enterprise ou Education (Home et Windows Server n’ont pas cette fonctionnalité). Le bagage est la notion de partitions de la partie 1. La difficulté est intermédiaire.

1. La conclusion, d’abord

Une machine virtuelle légère garde la ligne d’isolation (un noyau dédié et une frontière d’hyperviseur) et allège la « copie d’un OS invité complet ». Sandbox partage le Windows de l’hôte lui-même ; WSL2 remplace l’invité par un Linux petit et conçu exprès ; et dans les deux cas la mémoire n’est pas une réservation fixe mais se prête et s’emprunte dynamiquement avec l’hôte.

La source du poids d’une machine virtuelle complète n’est pas l’isolation elle-même mais la duplication. Une autre image d’OS sur disque, l’équivalent d’un autre OS de pages en RAM, et un autre boot complet chaque fois que vous démarrez. Les machines virtuelles légères coupent cette duplication avec deux politiques : « partager ce qu’il est sûr de partager » (Sandbox) et « si vous ne pouvez pas le partager, le reconstruire petit » (WSL2).

flowchart TB
    accTitle: Trois types de partage qui soutiennent les machines virtuelles légères
    accDescr: L'image d'OS qu'une machine virtuelle complète dupliquait est coupée par le partage dans Sandbox et par le rétrécissement dans WSL2 ; la mémoire qui est une allocation fixe par défaut（la mémoire dynamique est l'exception）devient un prêt et un emprunt dynamiques avec l'hôte ; le démarrage est remplacé par un noyau léger et une configuration minimale ; seule la frontière d'isolation demeure
    heavy["Machine virtuelle complète : duplication"] --> d1["Disque : copie d'image d'OS"]
    heavy --> more{"Mémoire ou démarrage ?"}
    more --> d2["Mémoire : fixe par défaut"]
    more --> d3["Démarrage : boot complet"]
    d1 -->|remplacé par| s1["Partager（Sandbox）"]
    s1 -.-> s1b["ou rétrécir（WSL2）"]
    d2 -->|remplacé par| s2["Prêt dynamique de l'hôte"]
    d3 -->|remplacé par| s3["Noyau léger + min."]

Figure 1 : le squelette de la réponse à « le même hyperviseur, pourtant léger » est qu’ils ont cessé de dupliquer, non qu’ils ont cessé d’isoler.

Ci-dessous nous regardons WSL2, Windows Sandbox et les conteneurs dans cet ordre, et quel type de duplication chacun d’eux coupe.

2. Ce qu’une machine virtuelle complète porte

Comme ligne de base de comparaison, voici ce qu’une machine virtuelle traditionnelle porte.

Une image d’OS indépendante. Elle détient chaque fichier de l’OS invité à l’intérieur d’un disque virtuel. Même si l’hôte a le même Windows, elle ne le partage pas.
Une allocation mémoire grossière. Le défaut d’une machine virtuelle traditionnelle est d’allouer la mémoire de l’hôte à une taille statique. Des mécanismes tels que Hyper-V Dynamic Memory peuvent faire croître et décroître l’allocation dans une plage configurée, mais les moyens de s’ajuster aux changements de demande sont limités.²
Un boot complet à usage général. Le microprogramme, le chargeur d’amorçage et l’ensemble des services démarrent dans la même séquence que sur une machine physique.

flowchart TB
    accTitle: Les trois charges qu'une machine virtuelle complète porte
    accDescr: Une machine virtuelle complète porte une image d'OS indépendante, une allocation mémoire statique par défaut, et un boot complet à usage général, et ceux-ci apparaissent comme des coûts en disque, RAM et temps de démarrage
    fullvm["Machine virtuelle complète"] --> b1["Image d'OS indépendante"]
    fullvm --> more{"Mémoire ou boot ?"}
    more --> b2["Mémoire statique par défaut"]
    more --> b3["Boot à usage général"]
    b1 -.-> c1["Disque en plus pour une copie"]
    b2 -.-> c2["Retient aussi la RAM inutilisée"]
    b3 -.-> c3["Prend des dizaines de secondes"]

Figure 2 : la décomposition du coût d’une machine virtuelle complète se paie non pour l’isolation mais pour la généralité et la duplication.

Ce ne sont pas des défauts ; c’est le prix de la généralité « vous pouvez mettre n’importe quoi dans l’invité ». Pour un usage tel qu’exécuter un vieux Linux à côté de Windows Server, cette généralité est la valeur. Mais pour un usage tel que « je veux exécuter le même OS (ou un OS prédéterminé) que l’hôte, tout de suite, pour le développement ou la validation », la plus grande partie est un bagage superflu. Les machines virtuelles légères déposent ce bagage en rétrécissant le but.

3. WSL2 — une machine virtuelle utilitaire avec un noyau conçu exprès

3.1. Structure : une machine virtuelle gérée et les distributions à l’intérieur

WSL2 est un mécanisme qui exécute un véritable noyau Linux à l’intérieur d’une machine virtuelle utilitaire légère.³ Il y a trois points.

Le noyau est véritable, mais c’est un produit spécialisé. C’est un noyau Linux que Microsoft construit à partir de la branche Stable, déjà réglé en taille et en performances pour WSL2. Sur le standard actuel, WSL distribué via Microsoft Store, le noyau est mis à jour avec le paquet WSL lui-même et appliqué avec wsl --update (sur l’ancienne distribution inbox, il venait via Windows Update).⁴ Parce que c’est un véritable noyau, la compatibilité des appels système est complète, et des outils tels que Docker s’exécutent tels quels.
La machine virtuelle est en coulisse. Créer, démarrer et arrêter la machine virtuelle est géré par WSL ; l’utilisateur ouvre simplement un interpréteur. Il n’y a pas d’écran de réglages de machine virtuelle ni d’attente ressentie pour un boot.⁴
Une distribution est un conteneur à l’intérieur de la machine virtuelle. Des distributions telles qu’Ubuntu et Debian s’exécutent comme des conteneurs isolés à l’intérieur d’une seule machine virtuelle gérée. Elles partagent l’espace de noms réseau et le noyau, tandis que des espaces de noms tels que PID, montage et utilisateur sont séparés.³

flowchart TB
    accTitle: Architecture de WSL2
    accDescr: Un Windows hôte et une machine virtuelle utilitaire légère se tiennent côte à côte sur l'hyperviseur ; un noyau Linux construit par Microsoft s'exécute à l'intérieur de la machine virtuelle ; et chaque distribution s'exécute comme un conteneur isolé à l'intérieur de celle-ci
    hv["Hyperviseur"] --> host["Windows hôte"]
    hv --> uvm["Machine virtuelle utilitaire légère"]
    uvm --> lk["Noyau Linux（build Microsoft ; mis à jour avec wsl --update）"]
    lk --> u1["Ubuntu（conteneur）"]
    lk --> u2["Debian（conteneur）"]
    host <-->|"Interop（commandes, fichiers, réseau）"| uvm

Figure 3 : la réponse à « WSL2 est-il une machine virtuelle ? » est « oui, mais une machine virtuelle gérée, en coulisse », et même si vous installez plusieurs distributions il n’y a toujours qu’une machine virtuelle.

Au moment où vous tapez wsl, l’envers ressemble à ceci.

flowchart TB
    accTitle: De l'exécution de la commande wsl à un interpréteur qui revient en quelques secondes
    accDescr: Si la machine virtuelle utilitaire ne tourne pas lorsque wsl est exécuté, la machine virtuelle légère et le noyau Linux démarrent ; si elle tourne déjà ils sont réutilisés ; et un interpréteur revient dans le conteneur de la distribution
    cmd["Exécuter wsl"] --> vmq{"La machine virtuelle utilitaire tourne-t-elle déjà ?"}
    vmq -->|Non| bootvm["Démarrer la MV légère et le noyau（quelques secondes）"]
    vmq -->|Oui| reuse["Réutiliser la machine virtuelle déjà en cours"]
    bootvm --> shell["Un interpréteur revient dans le conteneur"]
    reuse --> shell

Figure 4 : l’attente n’est qu’un démarrage minimal de machine virtuelle, et c’est là que déposer le bagage d’un boot complet se voit.

3.2. E/S de fichiers : de quel côté vous les mettez en fait une chose différente

Le sujet qui revient toujours dans les discussions de performances de WSL2 est l’endroit où vous mettez les fichiers.

Les opérations sur les fichiers côté Linux (le disque virtuel ext4) sont rapides. C’est parce que le noyau Linux parle à son propre système de fichiers directement, et des accélérations jusqu’à 20× par rapport à WSL1 pour l’extraction d’archives tar, et de 2 à 5× pour git clone et npm install, ont été rapportées.⁴
Les opérations sur les fichiers côté Windows (/mnt/c et analogues) deviennent lentes parce qu’elles passent par un partage de fichiers qui traverse une frontière d’OS. Les performances de système de fichiers inter-OS sont le seul grand point où WSL2 est moins bon que WSL1.⁴

Donc la règle est : « mettez les fichiers de projet du même côté d’OS que les outils qui opèrent dessus ».⁴ Un dépôt que vous manipulez avec des outils de construction Linux va côté Linux ; une solution que vous construisez dans Visual Studio va côté Windows.

flowchart TB
    accTitle: La fourche des chemins d'E/S de fichiers WSL2
    accDescr: L'accès au disque virtuel ext4 côté Linux est direct depuis le noyau Linux et donc rapide ; l'accès aux fichiers côté Windows passe par un partage de fichiers qui traverse une frontière d'OS et est donc lent
    io["Opérations sur fichiers dans WSL2"] --> place{"De quel côté est le fichier ?"}
    place -->|"Côté Linux（home, etc.）"| ext4["E/S directes vers le disque virtuel ext4"]
    place -->|"Côté Windows（/mnt/c, etc.）"| p9["Via un partage qui traverse l'OS"]
    ext4 --> fast["Rapide（exemples jusqu'à 20× vs WSL1）"]
    p9 --> slow["A tendance à être lent"]
    slow -.-> fix["Correction : mettre le fichier du côté qui l'utilise"]

Figure 5 : ce qui est lent, c’est le chemin, pas WSL2, donc changer l’endroit où vous mettez les fichiers fait souvent disparaître le problème de performances.

3.3. Mémoire : elle croît, elle décroît, mais elle ne rend pas toujours tout

L’utilisation mémoire de WSL2 (vous la voyez comme le processus vmmem dans le Gestionnaire des tâches) n’est pas une réservation fixe ; elle croît et décroît avec l’usage. La mémoire que les processus ont libérée est automatiquement renvoyée à Windows sous le réglage pageReporting, qui est activé par défaut.⁵ Les pages détenues comme cache de fichiers ne revenaient auparavant pas à Windows jusqu’à la sortie de la machine virtuelle.⁴ Dans WSL actuel, le réglage expérimental .wslconfig autoMemoryReclaim (la valeur par défaut est dropCache) récupère aussi le cache automatiquement.⁵ Dans les environnements où ce réglage est disabled, ou sur un WSL plus ancien, le cache d’une longue session peut rester jusqu’à la sortie de la machine virtuelle et peut faire pression sur la mémoire de l’hôte.

flowchart TB
    accTitle: Comment la mémoire de WSL2 croît, décroît et est renvoyée
    accDescr: La croissance de la demande à l'intérieur de WSL2 élève l'utilisation mémoire de la machine virtuelle ; les pages libérées par les processus sont renvoyées à Windows sous pageReporting, activé par défaut ; le cache de fichiers est récupéré automatiquement par autoMemoryReclaim par défaut ; mais sur un réglage désactivé ou un WSL plus ancien il reste jusqu'à la sortie de la machine virtuelle, et wsl --shutdown renvoie tout
    grow["La demande mémoire croît dans WSL2"] --> vm["L'usage de vmmem croît"]
    vm --> freed{"Cette page a-t-elle été libérée ?"}
    freed -->|"Libérée par le processus（pageReporting activé）"| ret["Renvoyée automatiquement à Windows"]
    freed -->|Détenue comme cache de fichiers| amr["autoMemoryReclaim la récupère（défaut）"]
    amr -.-> old2["Si désactivé ou WSL ancien, elle reste jusqu'à la sortie"]
    old2 --> sd["wsl --shutdown renvoie tout"]

Figure 6 : ce qui ressemble à « elle n’a fait que croître » est surtout le cache (et, lorsque pageReporting est désactivé, les pages libérées par les processus aussi), donc connaissez le chemin de retour avant de décider que c’est une fuite.

Si vous voulez une limite supérieure explicite, %UserProfile%\.wslconfig peut contrôler la mémoire globale de la machine virtuelle, le nombre de processeurs et le swap.⁵

# %UserProfile%\.wslconfig
[wsl2]
memory=8GB
processors=4
swap=2GB

Après avoir changé les réglages, redémarrez la machine virtuelle avec wsl --shutdown pour qu’ils prennent effet. Cette allocation dynamique — « la limite supérieure est un réglage, l’usage réel suit la demande » — est poussée encore plus loin dans le sujet suivant, Windows Sandbox.

4. Windows Sandbox — réutiliser le Windows de l’hôte

4.1. Image de base dynamique : un Windows complet en 500 Mo

Windows Sandbox est un bureau Windows jetable isolé par l’hyperviseur. Fermez-le et tout disparaît ; la fois suivante, il démarre en quelques secondes depuis un état propre.¹

La première énigme est le disque. Il peut démarrer un Windows complet, pourtant l’image de base de Sandbox n’est que d’environ 500 Mo après installation, et 30 Mo compressée à la distribution.² Le secret est l’image de base dynamique.

La plupart des fichiers d’OS sont immuables, donc les copies de l’hôte peuvent être partagées telles quelles.
Le petit nombre de fichiers mutables ne peut pas être partagé, donc une copie propre d’eux est conservée à l’intérieur de l’image de base.
Au démarrage, les fichiers immuables de l’hôte plus les copies locales des fichiers mutables sont combinés pour assembler une image Windows complète.²

Autrement dit, Sandbox ne télécharge ni ne stocke une copie de Windows ; il réutilise le Windows déjà installé sur l’hôte pour démarrer.

flowchart TB
    accTitle: Comment une image de base dynamique est assemblée
    accDescr: Les fichiers d'OS immuables du Windows hôte sont partagés ; seuls les fichiers mutables sont détenus comme copie propre dans l'image de base ; et les deux sont combinés pour assembler l'image Windows complète de Sandbox
    hostw["Le Windows complet de l'hôte"] --> imm["Fichiers d'OS immuables（la majorité）"]
    hostw --> mut["Fichiers d'OS mutables（une minorité）"]
    imm -->|Partagés tels quels| img["Image de boot de Sandbox"]
    mut -->|Garder une copie propre| img
    img --> boot["Démarre comme un Windows complet"]
    img -.-> size["Seuls environ 500 Mo doivent être stockés"]

Figure 7 : la forme d’abandonner la duplication disque n’est pas « posséder un autre Windows » mais « l’assembler à partir du Windows de l’hôte ».

Cette composition est ce qui rend le cycle de vie suivant possible. Ce qui est jeté, c’est l’état local à l’intérieur de Sandbox. Si vous avez mappé un dossier inscriptible depuis l’hôte dans le fichier de configuration .wsb, les changements y restent sur l’hôte.⁶

flowchart TB
    accTitle: Le cycle de vie de Windows Sandbox
    accDescr: Le démarrage prépare un Windows propre en quelques secondes ; après validation d'application ou expériences vous le fermez et tout l'état à l'intérieur de Sandbox est jeté afin que la fois suivante démarre aussi propre ; mais les changements d'un dossier hôte mappé comme inscriptible restent
    launch["Démarrer（quelques secondes）"] --> clean["Un Windows propre"]
    clean --> work["Validation d'application ou expériences"]
    work --> close2["Fermer"]
    close2 --> discard["Jeter tout l'état à l'intérieur de Sandbox"]
    discard -.-> mapped["Les changements d'un dossier mappé restent sur l'hôte"]
    discard -->|Démarrage suivant| launch

Figure 8 : pouvoir revenir au propre à chaque fois, c’est parce que la partie mutable est une copie jetable, et la jeter fait partie de la conception.

4.2. Direct map : le même ntdll.dll est la même page physique

Non seulement le disque mais la RAM est partagée aussi. Parce que Sandbox exécute la même image d’OS que l’hôte, une technique appelée « direct map » est utilisée afin que, pour les binaires d’OS, il utilise les mêmes pages de mémoire physique que l’hôte. Lorsque ntdll.dll est chargé en mémoire à l’intérieur de Sandbox, il pointe vers la même page physique que le même binaire déjà chargé sur l’hôte. Sans exposer les secrets de l’hôte au danger, il atteint une empreinte mémoire bien plus petite qu’une machine virtuelle traditionnelle.²

« Partager la même page physique entre plusieurs utilisateurs » — c’est la même idée que le partage de DLL via les objets section, que nous avons suivi dans la partie 3 de la série mémoire (« Section Objects and Copy-on-Write »). Ce mécanisme était un partage entre processus ; Sandbox le fait à travers une frontière de machine virtuelle.

flowchart TB
    accTitle: Partage de pages physiques via le direct map
    accDescr: Une application sur l'hôte et une application à l'intérieur de Sandbox partagent la même page de mémoire physique pour des binaires d'OS tels que ntdll, réduisant l'utilisation mémoire
    happ["Une application sur l'hôte"] --> hva["Adresse virtuelle côté hôte"]
    sapp["Une application dans Sandbox"] --> sva["Adresse virtuelle côté Sandbox"]
    hva --> phys["La même page physique（binaires d'OS tels que ntdll.dll）"]
    sva --> phys
    phys -.-> save["Pas besoin de dupliquer l'équivalent RAM de l'OS"]

Figure 9 : le direct map est l’idée du partage de pages qui a été utilisée entre processus, appliquée à travers une frontière de machine virtuelle.

4.3. Prêter et emprunter de la mémoire : plus comme un processus que comme une machine virtuelle

Contre l’allocation mémoire statique d’une machine virtuelle traditionnelle, la technologie de conteneurs sur laquelle Sandbox s’assoit décide l’allocation de ressources dynamiquement en coopération avec l’hôte. Si l’hôte manque de mémoire, il peut récupérer de la mémoire depuis le conteneur de la même façon qu’il la récupère depuis un processus ordinaire.² Hyper-V Dynamic Memory aussi fait croître et décroître l’allocation d’une machine virtuelle dans une plage configurée, mais Sandbox va plus loin : la différence est qu’il prête et emprunte sur le même terrain que la gestion mémoire de l’hôte.

flowchart TB
    accTitle: Coopération mémoire entre l'hôte et Sandbox
    accDescr: Le défaut d'une machine virtuelle traditionnelle est une allocation exclusive de taille statique avec des moyens d'ajustement limités ; Sandbox devient une cible de récupération en réponse à la pression mémoire de l'hôte et prête et emprunte de la mémoire sur le même terrain que les processus ordinaires
    pressure["La pression mémoire de l'hôte monte"] --> from{"D'où récupérons-nous ?"}
    from --> proc["Working Sets des processus ordinaires"]
    from --> sbx["L'usage de Sandbox（conteneur）"]
    proc --> relief["De la mémoire libre est sécurisée"]
    sbx --> relief
    relief -.-> contrast["Une machine virtuelle traditionnelle a des moyens limités"]

Figure 10 : dans le prêt et l’emprunt de mémoire, Sandbox se tient du côté processus plutôt que du côté machine virtuelle, et offre de la mémoire lorsque l’hôte est en difficulté.

Dans la partie 1, nous avons dit « les performances d’une machine virtuelle dépendent aussi du côté hôte », mais avec les machines virtuelles légères nous faisons un pas de plus : l’allocation de la mémoire elle-même est un travail conjoint avec l’hôte. La raison pour laquelle Sandbox peut être utilisé avec le sentiment d’« une autre application » plutôt que d’« un produit de virtualisation lourd », c’est cette coopération.

La procédure concrète pour utiliser Sandbox afin de valider une application métier est couverte dans l’article antérieur « Accélérer la validation des applications avec Windows Sandbox ». Cet article est le mécanisme en dessous.

5. Conteneurs — où vous tracez la ligne d’isolation

5.1. Isolation de processus et isolation Hyper-V

Les conteneurs Windows ont deux modes d’isolation à l’exécution. L’image est partagée ; vous choisissez avec un drapeau au démarrage.⁷

Isolation de processus : plusieurs conteneurs partagent le noyau avec l’hôte et s’isolent via une virtualisation par espace de noms du système de fichiers, du registre, des ports réseau, de l’espace d’identifiants de processus, de l’espace de noms de l’Object Manager, etc. C’est essentiellement la même approche que les conteneurs Linux.
Isolation Hyper-V : chaque conteneur s’exécute à l’intérieur d’une machine virtuelle hautement optimisée et a ce qui est en pratique un noyau dédié. La présence de la machine virtuelle met une isolation de niveau matériel entre les conteneurs et l’hôte.⁷

L’isolation via les espaces de noms peut être décrite comme une version approfondie de la technique que nous avons vue dans l’article sur la virtualisation du registre (« Redirection et virtualisation du registre sous Windows ») — « montrer une réalité différente sous la même API ».

flowchart TB
    accTitle: Isolation de processus versus isolation Hyper-V
    accDescr: Sous l'isolation de processus, les conteneurs partagent le noyau avec l'hôte et s'isolent via les espaces de noms ; sous l'isolation Hyper-V, chaque conteneur a un noyau dédié à l'intérieur d'une machine virtuelle optimisée
    subgraph pi ["Isolation de processus"]
        c1["Conteneur A"] --> sk1["Noyau partagé avec l'hôte"]
        c2["Conteneur B"] --> sk1
    end
    subgraph hi ["Isolation Hyper-V"]
        c3["Conteneur C"] --> k3["Noyau dédié（dans une MV optimisée）"]
        c4["Conteneur D"] --> k4["Noyau dédié（dans une MV optimisée）"]
    end
    sk1 ~~~ c3

Figure 11 : même avec la même image de conteneur, que vous traciez la ligne d’isolation au-dessus du noyau ou scindiez le noyau lui-même est un choix que vous faites au démarrage.

5.2. Lequel pouvez-vous appeler une « frontière de sécurité »

La différence entre ces deux modes n’est pas seulement une histoire de performances. Microsoft ne considère pas un conteneur à isolation de processus comme une frontière de sécurité robuste. Les conteneurs qui sont maintenus (avec réponse aux vulnérabilités) comme frontière de sécurité sont les conteneurs isolés par hyperviseur, et l’isolation Hyper-V est ce que vous devez choisir dans un scénario multi-locataire adverse.⁸

La VBS que nous avons vue dans la partie 2 était aussi une conception qui suppose « le noyau peut être franchi » et se retire vers une frontière d’hyperviseur. Le même critère s’applique dans le monde des conteneurs. La ligne qui confine le code non fiable se trace à la frontière de l’hyperviseur, pas à l’intérieur d’un noyau partagé.

flowchart TB
    accTitle: Comment choisir l'isolation d'après le degré de confiance dans le code
    accDescr: Si la charge de travail est de confiance, prenez la densité et les performances avec l'isolation de processus ; si le code n'est pas de confiance ou est celui de quelqu'un d'autre, choisissez une frontière d'hyperviseur telle qu'un conteneur isolé Hyper-V, un Windows Sandbox durci avec le réseau désactivé, ou une machine virtuelle isolée
    trust{"Pouvez-vous faire confiance à ce code ?"} -->|Oui| dens["Isolation de processus（densité et vitesse）"]
    trust -->|Non / code d'autrui| bound["Choisir une frontière d'hyperviseur"]
    bound --> opt1["Conteneurs isolés Hyper-V"]
    bound --> opt2["Un Sandbox durci ou une MV isolée"]

Figure 12 : le mode d’isolation est une histoire de sécurité avant d’être une histoire de performances, et la confiance décide où vous tracez la ligne.

Soit dit en passant, exécuter un conteneur isolé Hyper-V à l’intérieur d’une machine virtuelle Hyper-V rend l’hyperviseur profond de deux couches — la virtualisation imbriquée. Un niveau d’imbrication est pris en charge en production sur les environnements qui remplissent les conditions (un processeur Intel avec un hôte Windows 10 / Windows Server 2016 ou ultérieur, ou un processeur AMD avec un hôte Windows 11 / Windows Server 2022 ou ultérieur, et la version de configuration de machine virtuelle correspondante dans chaque cas), et un prérequis supplémentaire est un réglage qui expose les extensions de virtualisation à la machine virtuelle extérieure (ExposeVirtualizationExtensions sur Set-VMProcessor dans Hyper-V). Exécuter WSL2 à l’intérieur d’une machine virtuelle est pris en charge de la même manière.⁹ Que vous puissiez utiliser WSL2 ou Docker dans une machine virtuelle de développement dans le cloud se décide aussi par le fait que cette taille et cette configuration de machine virtuelle exposent la virtualisation imbriquée.

flowchart TB
    accTitle: La structure de la virtualisation imbriquée
    accDescr: Une machine virtuelle cloud s'assoit sur l'hyperviseur de l'hôte physique, et à l'intérieur un autre hyperviseur（l'imbrication prise en charge est d'un niveau）s'exécute pour soutenir WSL2 et les conteneurs isolés Hyper-V
    phys3["L'hyperviseur de l'hôte physique"] --> cvm["Machine virtuelle cloud（dev）"]
    cvm --> nhv["Hyperviseur dans la MV（niveau 1）"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Conteneur isolé Hyper-V"]
    nhv -.-> limit["L'imbrication prise en charge est d'un niveau"]

Figure 13 : la raison pour laquelle wsl s’exécute à l’intérieur d’une machine virtuelle cloud, c’est que la virtualisation imbriquée est officiellement prise en charge pour un niveau seulement.

5.3. Le spectre de l’isolation et de la légèreté

En alignant la distribution jusqu’ici sur un seul axe, cela ressemble à ceci.

flowchart TB
    accTitle: Le spectre de la force d'isolation et de la légèreté
    accDescr: Les conteneurs à isolation de processus sont les plus légers mais partagent le noyau ; WSL2, Sandbox et les conteneurs isolés Hyper-V sont des machines virtuelles légères avec un noyau dédié（Sandbox allège par le partage, WSL2 par un noyau conçu exprès） ; une machine virtuelle complète est la plus lourde mais à usage général
    ax["Léger ← → Lourd"] ~~~ p1
    p1["Conteneurs process-isolation"] --> p2["WSL2 / Sandbox / Hyper-V"]
    p2 --> p3["VM complète（copie entière）"]
    p1 -.-> n1["Frontière : espaces de noms"]
    p2 -.-> n2["Frontière : hyperviseur"]
    p3 -.-> n3["Frontière : hyperviseur + indép."]

Figure 14 : le groupe des machines virtuelles légères est la solution du milieu qui a gardé la frontière d’hyperviseur et coupé la duplication ; la façon de la couper se scinde en partage pour Sandbox et en noyau conçu exprès pour WSL2.

6. Voyez-le par vous-même

La légèreté et le partage sont des choses que vous pouvez observer sur une machine devant vous.

Le temps de démarrage et la montée et la descente de la mémoire (WSL2). Avec le Gestionnaire des tâches ouvert, essayez ce qui suit.

# Felt startup time (the first run starts the VM; the second and later are faster still)
Measure-Command { wsl -e true }

# Memory usage of the WSL2 VM (vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# End the whole VM and watch the memory come back
wsl --shutdown

Si vous faites une construction importante ou une opération sur fichiers à l’intérieur de WSL2, vmmem croît, et vous pouvez l’observer être renvoyé d’un coup avec wsl --shutdown.

La différence de vitesse selon l’endroit où vous mettez les fichiers (WSL2). Mettez le même dépôt côté Linux (~/repo) et côté Windows (/mnt/c/repo) et comparez le temps de git status ou d’une extraction, et la différence de la section 3.2 apparaît en chiffres.

Contexte pour le direct map (Sandbox). Démarrez Sandbox et regardez l’incrément de mémoire dans le Gestionnaire des tâches sur l’hôte. Que l’incrément reste bien plus petit que ce que « un autre Windows » vous ferait imaginer, c’est l’effet du partage qui raconte son histoire. Pour creuser plus loin dans la décomposition mémoire côté hôte, l’article sur les outils Sysinternals qui couvre comment utiliser RAMMap et VMMap (« Process Explorer / Handle / VMMap en pratique ») est utile. Ce sont toutefois des outils pour regarder la classification des processus et de la mémoire physique côté hôte ; ils n’observent pas directement le partage avec l’invité lui-même.

Modes d’isolation des conteneurs (Docker / conteneurs Windows). Si vous avez un environnement de conteneurs Windows, démarrez la même image avec docker run --isolation=process et --isolation=hyperv et comparez le temps de démarrage et l’apparence dans le Gestionnaire des tâches (sous l’isolation de processus, les processus à l’intérieur du conteneur apparaissent dans la liste des processus de l’hôte), et vous pouvez sentir où la ligne d’isolation siège.⁷ L’isolation de processus, toutefois, présuppose que les versions de l’hôte et de l’image correspondent, et sur un OS client elle est limitée à un usage de développement et de test. L’isolation Hyper-V autorise un ensemble plus large de combinaisons, donc faites la comparaison sur une paire compatible.¹⁰

7. Trois lectures erronées à éviter en pratique

7.1. « WSL2 est lent »

Ce qui est lent n’est pas WSL2 mais le chemin d’E/S de fichiers qui traverse une frontière d’OS. Il y a de nombreux cas où simplement déplacer le projet côté Linux rend le ressenti une chose différente.⁴ Inversement, mettre des fichiers que des outils Windows toucheront côté Linux est également défavorable pour la même raison. Jugez par « mettez-le du même OS que le côté qui l’utilise ».

7.2. « vmmem qui devient grand est une fuite mémoire »

La mémoire de WSL2 croît et décroît avec la demande, et les portions libérées sont renvoyées. Sur WSL actuel, le cache de fichiers est aussi récupéré automatiquement par autoMemoryReclaim (la valeur par défaut est dropCache), donc « il est resté grand » se résout souvent avec le temps.⁵ S’il reste encore, confirmez que autoMemoryReclaim n’a pas été réglé sur disabled et que pageReporting, qui est responsable du renvoi des portions libérées, n’a pas été désactivé (ou que vous n’êtes pas sur un WSL plus ancien), puis soit rendez la limite supérieure explicite avec memory dans .wslconfig, soit renvoyez tout avec wsl --shutdown à une frontière de session. La façon de penser pour distinguer une fuite d’une non-fuite est la même que dans le volet d’introduction de la série mémoire, « Que représente réellement la « mémoire utilisée » sous Windows ? ».

7.3. « C’est dans un conteneur, donc c’est sûr »

Un conteneur à isolation de processus partage le noyau, et selon le critère de Microsoft ce n’est pas une frontière de sécurité.⁸ Pour exécuter du code non fiable ou un spécimen, choisissez une isolation qui a une frontière d’hyperviseur, telle qu’un conteneur isolé Hyper-V, Windows Sandbox, ou une machine virtuelle dédiée. Une frontière d’hyperviseur, toutefois, n’est pas une exemption générale. Les réglages par défaut de Windows Sandbox ont la connectivité réseau activée, et peuvent exposer une application non fiable au réseau interne.¹ Si vous l’utilisez pour exécuter un spécimen, renforcez l’isolation en désactivant le réseau et la redirection du Presse-papiers dans le fichier de configuration .wsb, ou utilisez une machine virtuelle dédiée sur un réseau isolé.

8. Résumé — clore la série

Les points de la partie 3.

La légèreté d’une machine virtuelle légère est le résultat d’« arrêter de dupliquer », non d’« affaiblir l’isolation ».
WSL2 exécute un véritable noyau Linux dans une machine virtuelle utilitaire légère gérée, et les distributions sont isolées comme conteneurs à l’intérieur de cette machine virtuelle.³ La règle de performances est de mettre les fichiers sur l’OS qui les utilise, et la mémoire croît et décroît dynamiquement, la limite supérieure étant contrôlable dans .wslconfig.⁴⁵
Windows Sandbox partage les fichiers d’OS immuables de l’hôte via une image de base dynamique et partage aussi les pages physiques des binaires d’OS cibles via le direct map, donc il ne détient pas une copie d’un Windows complet.² Vous avez encore besoin d’environ 500 Mo pour les fichiers mutables, plus la mémoire des applications que vous exécutez à l’intérieur.
Le mode d’isolation des conteneurs se choisit au démarrage, et le côté que vous pouvez appeler une frontière de sécurité est l’isolation Hyper-V.⁷⁸

Et si nous mettons toute la série sur une page, cela ressemble à ceci.

Partie 1 : Il y a une couche d’hyperviseur sous Windows, et l’OS hôte lui-même s’exécute en tant que partition racine. L’arbitrage du processeur et de la mémoire (SLAT) se fait directement par cette couche, et les E/S des périphériques synthétiques sont médiatisées par la partition racine (VSP) au-delà de VMBus.
Partie 2 : Cette couche est utilisée non seulement pour isoler les machines virtuelles les unes des autres mais aussi pour tracer une frontière plus forte que le noyau (VTL) à l’intérieur du même OS. La sécurité par défaut de Windows 11 est construite au-dessus de ceci.
Partie 3 : Sur la même couche, couper la duplication est ce qui rend possible « une machine virtuelle qui démarre en quelques secondes ». La ligne d’isolation est gardée, et cela est devenu un outil quotidien.

flowchart TB
    accTitle: Une image de toute la série
    accDescr: L'hyperviseur directement sur le matériel est la partie 1 ; la scission de VTL0 et VTL1 à l'intérieur du Windows hôte est la partie 2 ; la légèreté de WSL2, Sandbox et de l'isolation Hyper-V sur la même couche est la partie 3 ; les conteneurs à isolation de processus partagent le noyau hôte ; Sandbox allège par le partage, WSL2 par un noyau conçu exprès
    hw3["Matériel"] --> hv3["Hyperviseur（partie 1）"]
    hv3 --> rp3["Windows hôte（VTL = partie 2）"]
    hv3 --> lw3["WSL2 / Sandbox / Hyper-V（p.3）"]
    rp3 --> pc3["Conteneurs process-isolation"]
    lw3 -.-> mech3["Sandbox partage ; WSL2 a un noyau dédié"]

Figure 15 : empilez les trois volets et vous avez le tableau d’ensemble du sol sous Windows actuel.

La virtualisation n’est plus une technologie de salle serveurs, ni une technologie seulement pour ceux qui dressent des machines virtuelles. Au sol sous votre Windows, elle soutient tranquillement à la fois la sécurité et l’expérience de développement — voilà où nous en sommes maintenant.

Domaines de conseil associés

KomuraSoft LLC prend en charge la mise en place d’environnements de développement qui utilisent WSL2 et les conteneurs, la conception d’environnements de validation d’applications Windows, et l’investigation des performances et de la compatibilité dans des environnements virtualisés.

Références

Microsoft Learn, Windows Sandbox. Sur le fait que Windows Sandbox démarre en quelques secondes comme machine virtuelle jetable et jette tout à la fermeture ; sur le fait d’exécuter un noyau séparé avec l’hyperviseur Microsoft pour l’isoler de l’hôte ; et sur le fait que la connectivité réseau est activée par défaut et désactivable dans le fichier de configuration. ↩ ↩² ↩³
Microsoft Learn, Windows Sandbox architecture. Sur le fait qu’une image de base dynamique assemble une image Windows complète à partir d’un partage des fichiers d’OS immuables de l’hôte plus une copie propre des fichiers mutables (environ 500 Mo après installation) ; sur le fait qu’un conteneur alloue dynamiquement en coopération avec l’hôte, contre l’allocation mémoire statique d’une machine virtuelle traditionnelle, de sorte que l’hôte peut récupérer de la mémoire ; et sur le fait que le direct map fait que des binaires d’OS tels que ntdll.dll utilisent les mêmes pages physiques que l’hôte. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, What is the Windows Subsystem for Linux?. Sur le fait que WSL2 exécute un noyau Linux à l’intérieur d’une machine virtuelle utilitaire légère ; sur le fait que chaque distribution s’exécute comme un conteneur isolé, partageant l’espace de noms réseau et le noyau tout en séparant des espaces de noms tels que PID, montage et utilisateur. ↩ ↩² ↩³
Microsoft Learn, Comparing WSL Versions. Sur le fait que le noyau WSL2 est construit par Microsoft à partir de la branche Stable ; sur le fait que WSL distribué via le Store reçoit des mises à jour comme paquet détaché de l’image d’OS et les applique avec wsl --update (sur l’ancienne distribution inbox, via Windows Update) ; sur des exemples de performances tels que jusqu’à 20× pour l’extraction d’archives tar ; sur le fait que WSL1 est plus rapide pour les performances de système de fichiers inter-OS, donc les fichiers doivent être placés sur l’OS qui les utilise ; et sur le fait que la mémoire croît et décroît avec les portions libérées renvoyées, tandis que le cache peut ne pas revenir jusqu’à la sortie de la machine virtuelle. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Microsoft Learn, Advanced settings configuration in WSL. Sur le fait de pouvoir régler le plafond mémoire global de la machine virtuelle WSL2, le nombre de processeurs, le swap et pageReporting (activé par défaut ; responsable de détecter et renvoyer la mémoire inutilisée) dans la section [wsl2] de .wslconfig ; et sur le fait que le réglage expérimental autoMemoryReclaim vaut par défaut dropCache, de sorte que la mémoire de cache est récupérée automatiquement. ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Use and configure Windows Sandbox. Sur le fait que MappedFolders dans le fichier de configuration .wsb peut partager un dossier hôte en lecture seule ou en écriture. ↩
Microsoft Learn, Isolation Modes. Sur le fait que l’isolation de processus des conteneurs Windows partage le noyau avec l’hôte et s’isole via les espaces de noms ; sur le fait que l’isolation Hyper-V a ce qui est en pratique un noyau dédié à l’intérieur d’une machine virtuelle optimisée ; et sur le fait que la même image est exécutable dans l’un ou l’autre mode via un drapeau au démarrage. ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Secure Windows containers. Sur le fait que seuls les conteneurs isolés par hyperviseur sont traités comme frontière de sécurité ; sur le fait que les conteneurs à isolation de processus ne sont pas considérés comme une frontière de sécurité robuste ; et sur le fait que l’isolation par hyperviseur est ce que vous devez choisir dans un scénario multi-locataire adverse. ↩ ↩² ↩³
Microsoft Learn, What is Nested Virtualization?. Sur le fait qu’exécuter des conteneurs isolés Hyper-V à l’intérieur d’une machine virtuelle Hyper-V (un niveau d’imbrication) est pris en charge en production ; sur le fait que les exigences sont un processeur Intel avec Windows Server 2016 / Windows 10 ou ultérieur, ou un processeur AMD avec Windows Server 2022 / Windows 11 ou ultérieur, plus la version de configuration de machine virtuelle correspondante dans chaque cas ; sur le fait qu’exposer les extensions de virtualisation à la machine virtuelle extérieure (ExposeVirtualizationExtensions) est un prérequis ; et sur le fait qu’exécuter WSL2 à l’intérieur d’une machine virtuelle Hyper-V est pris en charge. ↩
Microsoft Learn, Windows container version compatibility. Sur le fait que l’isolation de processus présuppose que les versions de l’hôte et de l’image de conteneur correspondent ; sur le fait que l’isolation Hyper-V peut exécuter une image d’une version d’OS différente de celle de l’hôte ; et sur le fait que l’isolation de processus sur un OS client est limitée à un usage de développement et de test. ↩

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

Les profondeurs de la virtualisation Windows (partie 1) — Où s'exécute réellement votre Windows ? L'hyperviseur et les partitions

Lorsque vous activez Hyper-V, le Windows hôte lui-même s'exécute au-dessus de l'hyperviseur, en tant que partition racine. Cet article ex...

Lire l’article

Les profondeurs de la virtualisation Windows (partie 2) — Une mémoire invisible même au noyau : comment fonctionnent VBS, HVCI et Credential Guard

Lors d'une installation propre sur un matériel compatible, VBS est activée par défaut et utilise l'hyperviseur et SLAT pour créer une iso...

Lire l’article

Accélérer la validation des applications avec Windows Sandbox

Comment utiliser Windows Sandbox pour isoler les problèmes de privilèges administrateur, reproduire des anomalies dans un environnement p...

Lire l’article

L'API du pool de threads Win32 — de la concurrence sans créer de threads, via CreateThreadpoolWork

Vous semez des appels CreateThread partout dans votre code natif ? Cet article explique l'API du pool de threads Win32 refondue sous Vist...

Lire l’article

Tubes nommés en pratique — l'IPC standard de Windows, de la conception à la sécurité

Guide pratique des tubes nommés, mécanisme standard de communication inter-processus sous Windows. Cet article organise, à partir des sou...

Lire l’article

Sujets associés

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

Thèmes techniques Windows

Portail des sujets sur le développement Windows, l'analyse des incidents et la valorisation des actifs existants.

Voir le sujet

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Développement d'applications Windows

Applications métier, intégration d'équipements et outils de communication, des besoins au développement.

Voir le service Nous contacter

Questions fréquentes

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

WSL2 est-il une machine virtuelle ?: Oui. WSL2 exécute un véritable noyau Linux construit par Microsoft à l'intérieur d'une machine virtuelle utilitaire légère. La machine virtuelle est gérée par WSL en coulisse, donc la conception ne fait jamais penser l'utilisateur aux réglages de machine virtuelle ni à l'attente d'un boot. Chaque distribution Linux s'exécute comme un conteneur isolé à l'intérieur de cette machine virtuelle gérée.
Pourquoi les opérations sur fichiers sous /mnt/c sont-elles lentes dans WSL2 ?: Parce que l'accès depuis le noyau Linux de WSL2 au système de fichiers côté Windows passe par un partage de fichiers qui traverse une frontière d'OS. Les opérations sur le système de fichiers Linux (un disque virtuel ext4) sont rapides, donc la règle est de garder les fichiers de projet du même côté d'OS que les outils qui travaillent dessus.
Une utilisation mémoire importante du processus vmmem est-elle une fuite ?: Dans la plupart des cas, ce n'est pas une fuite. La mémoire de WSL2 croît et décroît avec l'usage, et la mémoire que les processus ont libérée est renvoyée à Windows sous le réglage pageReporting, qui est activé par défaut. Les pages de cache de fichiers, elles aussi, sont récupérées automatiquement par WSL actuel via autoMemoryReclaim dans .wslconfig (la valeur par défaut est dropCache). Dans les environnements où ces réglages ont été désactivés, ou sur un WSL plus ancien, la mémoire peut rester jusqu'à la sortie de la machine virtuelle ; dans ce cas, fixez une limite supérieure avec le réglage memory, ou renvoyez-la avec wsl --shutdown.
Comment Windows Sandbox peut-il démarrer un Windows complet à partir de quelques centaines de mégaoctets de disque ?: Grâce à un mécanisme appelé image de base dynamique. Il partage les fichiers d'OS immuables depuis le Windows déjà installé sur l'hôte, et conserve une copie propre du petit nombre de fichiers mutables. Cela lui permet d'assembler une image complète amorçable sans stocker une copie entière de Windows.
Les conteneurs sont-ils plus sûrs que les machines virtuelles ?: Cela dépend du mode d'isolation. Les conteneurs à isolation de processus partagent le noyau avec l'hôte, et Microsoft ne considère pas ceci comme une frontière de sécurité robuste. Lorsque vous manipulez du code adverse, vous avez besoin de l'isolation Hyper-V, qui donne à chaque conteneur son propre noyau dédié.

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.

Voir le profil Nous contacter

Liens publics

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

Retour au blog

1. La conclusion, d’abord

2. Ce qu’une machine virtuelle complète porte

3. WSL2 — une machine virtuelle utilitaire avec un noyau conçu exprès

3.1. Structure : une machine virtuelle gérée et les distributions à l’intérieur

3.2. E/S de fichiers : de quel côté vous les mettez en fait une chose différente

3.3. Mémoire : elle croît, elle décroît, mais elle ne rend pas toujours tout

4. Windows Sandbox — réutiliser le Windows de l’hôte

4.1. Image de base dynamique : un Windows complet en 500 Mo

4.2. Direct map : le même ntdll.dll est la même page physique

4.3. Prêter et emprunter de la mémoire : plus comme un processus que comme une machine virtuelle

5. Conteneurs — où vous tracez la ligne d’isolation

5.1. Isolation de processus et isolation Hyper-V

5.2. Lequel pouvez-vous appeler une « frontière de sécurité »

5.3. Le spectre de l’isolation et de la légèreté

6. Voyez-le par vous-même

7. Trois lectures erronées à éviter en pratique

7.1. « WSL2 est lent »

7.2. « vmmem qui devient grand est une fuite mémoire »

7.3. « C’est dans un conteneur, donc c’est sûr »

8. Résumé — clore la série

Articles connexes

Domaines de conseil associés

Références

Articles associés

Les profondeurs de la virtualisation Windows (partie 1) — Où s'exécute réellement votre Windows ? L'hyperviseur et les partitions

Les profondeurs de la virtualisation Windows (partie 2) — Une mémoire invisible même au noyau : comment fonctionnent VBS, HVCI et Credential Guard

Accélérer la validation des applications avec Windows Sandbox

L'API du pool de threads Win32 — de la concurrence sans créer de threads, via CreateThreadpoolWork

Tubes nommés en pratique — l'IPC standard de Windows, de la conception à la sécurité

Sujets associés

Thèmes techniques Windows

Services liés à ce sujet

Développement d'applications Windows

Questions fréquentes

Profil de l’auteur

Go Komura