DISM vs SFC : L’ordre de réparation qui fait gagner des heures

Le seul modèle mental dont vous avez besoin : ce que DISM et SFC touchent réellement

SFC (System File Checker) vérifie et répare les fichiers système protégés dans votre installation Windows en cours d’exécution. Il compare ce qui est sur le disque avec des versions connues comme étant bonnes — mais ces versions connues viennent de quelque part. Ce « quelque part » est le magasin de composants Windows (WinSxS) et ses métadonnées de maintenance.

DISM (Deployment Image Servicing and Management) est la chaîne d’outils de maintenance que Windows utilise pour entretenir et réparer l’image elle-même — en particulier le magasin de composants dont SFC dépend. Si le magasin de composants est endommagé ou manque de payloads, SFC peut détecter la corruption et quand même échouer à la réparer parce que sa source de réparation est compromise.

Voici votre modèle central :

• DISM répare la source de réparation. Pensez : « soigner l’entrepôt ».
• SFC répare les fichiers déployés. Pensez : « remplacer ce qui est déjà sur les étagères ».

Si vous lancez SFC en premier alors que le magasin de composants est HS, vous pouvez vous retrouver dans une boucle infinie de « corruption trouvée » sans réparation durable. Ce n’est pas que SFC est mauvais. C’est que vous lui avez demandé de reconstruire une maison en utilisant des briques sorties d’un four fissuré.

Et oui, DISM peut aussi entretenir des images hors ligne (WIM montés, répertoires Windows hors ligne). SFC peut faire quelques vérifications hors ligne aussi. Cette distinction compte quand vous secourez une machine qui démarre à peine ou quand vous réparez des images golden VDI à grande échelle.

Une citation opérationnelle qui mérite un post-it sur votre chariot KVM :

« L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan

Ne « comptez pas sur l’espoir » pour que SFC répare magiquement ce dont DISM est responsable. Utilisez les outils dans l’ordre que leurs dépendances exigent.

L’ordre de réparation qui fait gagner des heures (et pourquoi)

L’ordre par défaut pour un système en cours d’exécution

1. Vérification d’état DISM (signal rapide)
2. DISM RestoreHealth (répare le magasin de composants)
3. SFC /scannow (répare les fichiers système protégés)
4. Redémarrage si quelque chose a été réparé
5. Relancer SFC si nécessaire (oui, parfois deux fois)

Pourquoi cet ordre fonctionne : la capacité de SFC à réparer dépend d’un magasin de composants fonctionnel. DISM répare ce magasin en utilisant Windows Update, WSUS, ou une source spécifiée (WIM/ESD). Ce n’est qu’après que le magasin est sain que vous devez demander à SFC de remplacer des fichiers.

Quand vous devriez déroger à la règle

Rarement, mais voici les vrais cas :

• Vous suspectez seulement quelques fichiers corrompus (par ex., une DLL) et vous avez besoin d’un point de données rapide. Lancer SFC d’abord peut confirmer la corruption rapidement, mais n’en restez pas là si SFC ne peut pas réparer.
• Vous êtes hors ligne sans média source et DISM ne peut rien réparer sans lui. SFC peut encore réparer certains fichiers si le magasin est partiellement intact. Ce n’est pas idéal ; c’est du triage.
• Votre client Windows Update est cassé et DISM dépend de lui comme source. Dans ce cas, vous indiquerez à DISM une source locale de toute façon (et l’exécuterez toujours avant SFC).

Voici la règle que j’applique en production : Si SFC dit avoir trouvé de la corruption mais n’a pas pu la réparer, arrêtez de relancer SFC comme si vous jouiez au loto. Passez à DISM.

Petite blague #1 : relancer sfc /scannow cinq fois ne le rend pas plus correct ; cela vous rend juste plus optimiste que votre comité de changements.

Faits et historique : pourquoi les réparations Windows ressemblent à ça

La maintenance Windows est la raison pour laquelle ces outils existent et aussi la raison pour laquelle ils semblent parfois conçus par un comité allergique aux réponses simples. Quelques faits et points historiques qui expliquent le comportement actuel :

1. SFC précède la maintenance moderne des composants. Il remonte à l’ère de la protection des fichiers de Windows (Windows 2000/XP) où les fichiers système étaient protégés et remplacés à partir de copies en cache.
2. DISM a remplacé d’anciens outils d’imagerie. Avant DISM, il y avait des outils comme ImageX pour gérer les WIM ; DISM est devenu le couteau suisse pour l’entretien des images et des fonctionnalités.
3. Le magasin de composants (WinSxS) n’est pas « juste des duplicatas ». C’est un magasin côte-à-côte qui prend en charge la maintenance, les retours arrière et plusieurs versions de composants.
4. La « corruption du magasin de composants » est souvent une corruption des métadonnées. Il ne s’agit pas toujours de binaires manquants ; parfois l’état des manifests/catalogues de maintenance est incohérent.
5. Les mises à jour de la pile de maintenance importent. La pile de maintenance est la machinerie qui applique les mises à jour. Lorsqu’elle est cassée, les réparations peuvent échouer d’une manière qui paraît sans rapport.
6. DISM peut utiliser Windows Update comme source de réparation. C’est pratique — et aussi la raison pour laquelle des chemins de mise à jour cassés, des points de terminaison bloqués ou une mauvaise configuration WSUS peuvent faire échouer les réparations.
7. Les sources WIM vs ESD ne sont pas interchangeables sans précautions. Le média d’installation peut contenir install.wim ou install.esd ; les index diffèrent selon l’édition, et le mauvais index produit « source files could not be found ».
8. Certaines erreurs sont de la politique, pas de la corruption. Si une stratégie de groupe empêche le contact avec Windows Update, DISM peut échouer même sur un système sain si vous vous attendez à ce qu’il récupère des payloads en ligne.
9. Les logs SFC sont volontairement verbeux. Le journal CBS capture les opérations de maintenance et peut se lire comme un roman écrit par un pilote d’impression. Filtrer fait partie du travail.

Méthode de diagnostic rapide : trouvez le goulot d’étranglement avant de « tester des choses »

C’est la partie où vous gagnez le plus de temps. Ne commencez pas par les réparations. Commencez par les contraintes : réseau, disponibilité de la source, incompatibilité d’édition, santé du disque, et si vous réparez bien la bonne installation Windows.

Première étape : confirmez que le problème est réellement une corruption

• Si Windows Update échoue, récupérez l’erreur et déterminez s’il s’agit d’un problème réseau/politique ou d’une corruption de composants.
• Si des applications plantent, confirmez si l’intégrité des fichiers système est impliquée (journaux d’événements, WER, résultats DISM/SFC).

Deuxième étape : confirmez que votre chemin de source de réparation est viable

• En ligne : la machine atteint-elle Windows Update ou WSUS ? La stratégie bloque-t-elle l’accès ?
• Hors ligne : avez-vous l’ISO correcte correspondant à la build/édition/langue ? Connaissez-vous le bon index d’image ?

Troisième étape : vérifiez la santé du disque et l’espace libre

• Un espace disque faible peut faire échouer DISM et la maintenance de manière chaotique.
• Les erreurs disque peuvent se faire passer pour de la « corruption » à répétition.

Quatrième étape : lancez des vérifications DISM avant une réparation complète

• /CheckHealth est rapide et vous indique si une corruption est signalée.
• /ScanHealth est plus lent mais donne un meilleur signal.

Cinquième étape : réparez le magasin de composants (DISM), puis réparez les fichiers système (SFC)

• DISM d’abord. Toujours, sauf si vous êtes littéralement incapable de le faire.
• SFC ensuite. Vérifiez les résultats. Redémarrez si des réparations ont eu lieu.

Sixième étape : ce n’est qu’ensuite que vous envisagez une escalade

• Réparation par mise à niveau sur place (in-place upgrade).
• Reimage connu bon (surtout pour des flottes).
• Remplacement matériel si le disque ou la RAM est suspecte.

Tâches pratiques : 12+ exécutions de commandes, sorties et décisions

Ces tâches sont écrites comme un runbook d’astreinte : exécutez une commande, lisez la sortie, prenez une décision. Les commandes sont montrées dans un format de console standardisé. L’invite hôte est arbitraire ; les commandes sont l’essentiel.

Tâche 1 : Vérification rapide du flag du magasin de composants (DISM CheckHealth)

cr0x@server:~$ DISM /Online /Cleanup-Image /CheckHealth
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

No component store corruption detected.
The operation completed successfully.

Ce que cela signifie : DISM ne voit pas de flag de corruption dans le magasin. Cela ne prouve pas que le système est parfait, mais c’est un indice fort que vous pourriez courir après autre chose (politique, disque, pilotes).

Décision : Si les symptômes persistent, exécutez /ScanHealth et SFC ; sinon orientez-vous vers les journaux/dépannage des mises à jour.

Tâche 2 : Analyse plus approfondie pour la corruption (DISM ScanHealth)

cr0x@server:~$ DISM /Online /Cleanup-Image /ScanHealth
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

[==========================100.0%==========================]
The component store is repairable.
The operation completed successfully.

Ce que cela signifie : Une corruption existe et DISM pense pouvoir la réparer.

Décision : Exécutez /RestoreHealth ensuite. Ne perdez pas de temps à relancer SFC de façon répétée pour l’instant.

Tâche 3 : Réparer le magasin de composants (DISM RestoreHealth)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Ce que cela signifie : Le magasin de composants est réparé.

Décision : Lancez maintenant SFC pour réparer les fichiers système endommagés ou non conformes.

Tâche 4 : Réparer les fichiers système protégés (SFC scannow)

cr0x@server:~$ sfc /scannow
Beginning system scan. This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection found corrupt files and successfully repaired them.
For online repairs, details are included in the CBS log file located at
windir\Logs\CBS\CBS.log.

Ce que cela signifie : SFC a remplacé/réparé certains fichiers en utilisant le magasin maintenant sain.

Décision : Redémarrez. Puis éventuellement relancez SFC pour confirmer « no integrity violations ».

Tâche 5 : Quand SFC ne peut pas réparer (le point clé de bifurcation)

cr0x@server:~$ sfc /scannow
Beginning system scan. This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection found corrupt files but was unable to fix some of them.
For online repairs, details are included in the CBS log file located at
windir\Logs\CBS\CBS.log.

Ce que cela signifie : SFC a confirmé la corruption mais n’a pas pu tout réparer — généralement parce que le magasin de composants est malsain ou manque de payloads.

Décision : Exécutez DISM /RestoreHealth (avec une source si nécessaire). Puis relancez SFC.

Tâche 6 : DISM échoue car il ne trouve pas les fichiers source (schéma 0x800f081f)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

Error: 0x800f081f

The source files could not be found.
Use the "Source" option to specify the location of the files that are required to restore the feature.

Ce que cela signifie : DISM ne peut pas récupérer ou localiser les payloads. C’est souvent un problème réseau/politique (WSUS/WU bloqué) ou vous avez besoin d’un ISO local.

Décision : Fournissez un média d’installation valide (WIM/ESD) correspondant à la build et à l’édition, ou réparez la connectivité de la source de mise à jour.

Tâche 7 : Identifier les index d’image du média d’installation (WIM/ESD) avant d’utiliser /Source

cr0x@server:~$ DISM /Get-WimInfo /WimFile:D:\sources\install.wim
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Details for image : D:\sources\install.wim

Index : 1
Name : Windows 10 Home
Description : Windows 10 Home
Size : 15,123,456,789 bytes

Index : 6
Name : Windows 10 Pro
Description : Windows 10 Pro
Size : 15,987,654,321 bytes

The operation completed successfully.

Ce que cela signifie : Le média d’installation contient plusieurs éditions ; chacune a un index.

Décision : Utilisez l’index qui correspond à l’édition installée (par ex. Pro). Un mauvais index = mauvais composants = échec de DISM.

Tâche 8 : Réparer en utilisant une source WIM locale (éviter la dépendance à Windows Update)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:6 /LimitAccess
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Ce que cela signifie : DISM a réparé en utilisant votre WIM fourni et n’a pas tenté Windows Update (/LimitAccess).

Décision : Lancez SFC ensuite. Si SFC ne peut toujours pas réparer, vous avez peut-être des problèmes de maintenance plus profonds, des problèmes disque, ou un média/build non apparié.

Tâche 9 : Utiliser ESD comme source (commun sur les ISO récents)

cr0x@server:~$ DISM /Online /Cleanup-Image /RestoreHealth /Source:ESD:D:\sources\install.esd:6 /LimitAccess
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Ce que cela signifie : Même concept que WIM, format de conteneur différent.

Décision : Si ESD échoue mais que WIM fonctionne (ou vice versa), votre média peut être incomplet ou l’index incorrect. Validez l’ISO et la sélection d’index.

Tâche 10 : Confirmer l’édition Windows (pour ne pas choisir le mauvais index)

cr0x@server:~$ DISM /Online /Get-CurrentEdition
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

Current edition is:

Current Edition : Professional

The operation completed successfully.

Ce que cela signifie : Votre édition installée est Professional.

Décision : Faites correspondre cela avec le nom d’index WIM/ESD (par ex., Windows 10 Pro). Ne devinez pas. Deviner conduit à « source files could not be found ».

Tâche 11 : Nettoyage du magasin de composants (seulement après que l’état est bon)

cr0x@server:~$ DISM /Online /Cleanup-Image /StartComponentCleanup
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

[==========================100.0%==========================]
The operation completed successfully.

Ce que cela signifie : Supprime les composants supersedés pour réduire la taille du magasin. Ce n’est pas une étape de réparation en soi, mais peut réduire les bizarreries futures de maintenance et récupérer de l’espace.

Décision : Utilisez-la après des réparations réussies, pas avant. Si le magasin est corrompu, le « nettoyage » peut compliquer la récupération en supprimant le matériel de retour arrière.

Tâche 12 : Réparation DISM hors ligne (quand Windows ne démarre pas correctement)

cr0x@server:~$ DISM /Image:E:\ /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:6 /LimitAccess
Deployment Image Servicing and Management tool
Version: 10.0.19041.1

Image Version: 10.0.19045.3803

[==========================100.0%==========================]
The restore operation completed successfully.
The operation completed successfully.

Ce que cela signifie : Vous avez réparé une installation Windows hors ligne située sur E:\.

Décision : Lancez ensuite SFC hors ligne contre ce même répertoire Windows, puis tentez le démarrage. Si cela échoue encore, vous vous dirigez vers une réparation par mise à niveau sur place ou un reimage.

Tâche 13 : Analyse et réparation SFC hors ligne (ciblant les bons répertoires)

cr0x@server:~$ sfc /scannow /offbootdir=E:\ /offwindir=E:\Windows
Beginning system scan. This process will take some time.

Beginning verification phase of system scan.
Verification 100% complete.

Windows Resource Protection found corrupt files and successfully repaired them.

Ce que cela signifie : SFC a réparé l’installation hors ligne. C’est l’équivalent « mode secours » du flux de travail normal.

Décision : Redémarrez dans l’OS réparé. Si le système démarre mais reste instable, vérifiez le disque et les journaux d’événements ; une corruption qui revient indique généralement un problème matériel ou de stockage.

Tâche 14 : Extraire les lignes SFC pertinentes du CBS.log (réduire le bruit)

cr0x@server:~$ findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log > %userprofile%\Desktop\sfc-details.txt

Ce que cela signifie : Filtre les entrées du journal CBS marquées par SFC (« [SR] ») dans un fichier plus petit que vous pouvez lire sans perdre votre volonté de vivre.

Décision : Si le journal référence de façon répétée le même fichier qui échoue à être réparé, suspectez un mauvais appariement store/source ou des fichiers verrouillés (puis relancez après un redémarrage ou en WinRE).

Tâche 15 : Valider l’espace libre (la maintenance a besoin d’espace pour respirer)

cr0x@server:~$ fsutil volume diskfree C:
Total # of free bytes        : 10737418240
Total # of bytes             : 255852544000
Total # of avail free bytes  : 10737418240

Ce que cela signifie : Environ 10 Go libre. C’est limite mais souvent acceptable. La maintenance peut nécessiter plusieurs Go selon les opérations en attente.

Décision : Si l’espace libre est faible (quelques Go sur Windows moderne), nettoyez avant les réparations — surtout avant les installations de fonctionnalités et les mises à jour cumulatives.

Tâche 16 : Vérifier le disque pour des problèmes de système de fichiers (quand la corruption revient)

cr0x@server:~$ chkdsk C: /scan
The type of the file system is NTFS.
Volume label is OS.

Stage 1: Examining basic file system structure ...
  512000 file records processed.
File verification completed.
Windows has scanned the file system and found no problems.
No further action is required.

Ce que cela signifie : NTFS semble cohérent. Cela ne prouve pas que le matériel du disque est parfait, mais réduit les chances que vous répariez sur du sable mouvant.

Décision : Si CHKDSK signale des erreurs, corrigez-les d’abord (éventuellement hors ligne). Relancer DISM/SFC sur un système de fichiers corrompu, c’est comme passer la serpillière pendant une fuite de plomberie.

Petite blague #2 : DISM bloqué à 20 % est la façon de Windows d’enseigner la patience sans la courtoisie d’un syllabus.

Trois mini-récits d’entreprise (réalistes, anonymisés, douloureux)

Mini-récit n°1 : L’incident causé par une mauvaise hypothèse

La file d’assistance a commencé à se remplir de « Outlook plante au lancement » et « Teams ne se met pas à jour ». Pas une seule machine. Des dizaines. Le lien commun n’était pas évident car la flotte couvrait plusieurs sites et modèles matériels.

Un ingénieur a fait l’hypothèse classique : « C’est une mauvaise mise à jour de l’application. » Ils ont rétrogradé Office sur quelques machines. Pas de changement. Ils ont modifié les politiques antivirus. Pas de changement. Puis ils ont exécuté sfc /scannow sur une machine, ont vu « fichiers corrompus réparés », et ont déclaré victoire. Le lendemain, les mêmes machines étaient à nouveau en panne.

Ce qui se passait réellement : un sous-ensemble de machines avait un magasin de composants cassé dû à un changement partiellement appliqué de la pile de maintenance combiné à une source interne de mises à jour instable. SFC a pu réparer certains fichiers mais continuait de puiser des remplacements dans un magasin qui n’était pas cohérent, si bien que le système retombait dans un état mauvais après des opérations de maintenance.

La correction n’a pas été héroïque. Elle a été disciplinée. Ils ont d’abord stabilisé le chemin de source des mises à jour, puis exécuté DISM /RestoreHealth en utilisant une ISO locale avec /LimitAccess pour éviter le chemin réseau défaillant, et seulement ensuite ont lancé SFC. Les machines ont cessé de rechuter. L’hypothèse erronée n’était pas « SFC est inutile ». L’hypothèse erronée était « les plantages d’applications sont forcément des problèmes d’applications ». Dans l’écosystème Windows, les plantages d’applications sont souvent la fumée, pas le feu.

Mini-récit n°2 : L’optimisation qui s’est retournée contre eux

Une équipe d’ingénierie desktop voulait accélérer le déploiement des correctifs et réduire l’usage disque. Ils ont poussé une politique agressive de nettoyage des composants sur les endpoints. L’idée était raisonnable : empêcher WinSxS de gonfler, réduire la pression de stockage et obtenir une conformité plus rapide.

Ça a marché — jusqu’à ce que ça ne marche plus. Une vague de machines a commencé à échouer lors d’installations de fonctionnalités à la demande et certaines mises à jour cumulatives. DISM /RestoreHealth s’est mis à se plaindre de fichiers source manquants plus souvent. La politique de nettoyage avait réduit la disponibilité locale des composants supersedés, ce qui est acceptable quand Windows Update fonctionne bien, mais leur environnement avait une histoire de mise à jour en split-brain : certains sites utilisaient WSUS, d’autres étaient directs, et certains étaient derrière un contrôle d’egress strict.

Quand la source n’était pas joignable, les machines avaient moins de solutions de repli locales. Les réparations qui réussissaient autrefois hors ligne nécessitaient maintenant une source externe correcte, et tout le monde ne l’avait pas. Le temps de support a explosé. L’« optimisation » a déplacé le coût de l’espace disque vers le temps humain — la ressource la plus chère du bâtiment.

L’équipe a annulé le calendrier de nettoyage le plus agressif, documenté quand exécuter /StartComponentCleanup, et standardisé un processus de source ISO locale pour les sites distants. La leçon n’était pas « ne jamais nettoyer ». C’était « n’optimisez pas au point de supprimer vos chemins de récupération à moins que votre source de vérité soit vraiment fiable ».

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société de services financiers (anonymisée, mais vous voyez le genre) avait une pipeline d’image master stricte pour le VDI. Chaque mois : patcher l’image de base, valider, sceller, publier. Ennuyeux. Prévisible. Un peu déprimant. Aussi : incroyablement efficace.

Un mois, après avoir patché, des instances VDI aléatoires ont commencé à échouer au lancement d’apps avec d’étranges erreurs de DLL. Les ingénieurs soupçonnaient la nouvelle mise à jour cumulative. L’équipe sécurité soupçonnait les contrôles endpoints. Tout le monde soupçonnait tout le monde. Pendant ce temps, les traders voulaient leur bureau hier.

La pratique ennuyeuse de l’équipe VDI était simple : ils exécutaient toujours des vérifications d’état DISM et SFC sur l’image golden avant de la sceller, et ils archivait la sortie et des extraits CBS avec les artefacts de build. Cette fois, DISM /ScanHealth a signalé une corruption réparable sur l’image avant qu’elle soit largement publiée.

Ils ont réparé l’image avec DISM en utilisant une source contrôlée, relancé SFC jusqu’à ce qu’il indique aucune violation d’intégrité, puis publié. La panne est restée limitée. Le post-mortem a été court. Leur runbook « ennuyeux » a empêché le classique problème de flotte : livrer la corruption comme une fonctionnalité.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : SFC dit avoir réparé des fichiers, mais les problèmes reviennent après des mises à jour

Cause racine : Le magasin de composants est toujours malsain, ou le chemin de mise à jour réintroduit l’état mauvais (maintenance échouée, opérations en attente, source cassée).

Correction : Exécutez DISM /ScanHealth et /RestoreHealth (utilisez une source connue bonne si votre chemin de mise à jour est douteux), puis exécutez SFC à nouveau. Confirmez la stabilité de la source de mise à jour.

2) Symptom : « Windows Resource Protection found corrupt files but was unable to fix some of them »

Cause racine : SFC ne trouve pas de bons remplaçants dans le magasin de composants, ou des fichiers sont verrouillés/en attente de remplacement.

Correction : DISM /RestoreHealth d’abord. Redémarrez. Relancez SFC. Si échec, exécutez SFC hors ligne depuis WinRE.

3) Symptom : Erreur DISM 0x800f081f (« source files could not be found »)

Cause racine : Payloads manquants et aucune source valide disponible ; ISO/build/édition incorrecte ; politique bloque Windows Update ; WSUS sans contenu.

Correction : Utilisez /Source:WIM: ou /Source:ESD: avec le bon index, ajoutez /LimitAccess, et assurez-vous que l’ISO correspond suffisamment à la build/édition/langue installées.

4) Symptom : DISM « bloqué » à un pourcentage pendant longtemps

Cause racine : Il effectue du travail (vérification de hachage, analyse de composants) avec de mauvaises performances disque, un antivirus qui scanne, ou une forte contention.

Correction : Attendez un délai raisonnable, mais vérifiez la santé du disque et l’espace libre. Réduisez temporairement l’impact du scan endpoint si votre politique le permet. Ne tuez pas DISM prématurément à moins d’aimer un état de maintenance à moitié appliqué.

5) Symptom : DISM réussit, SFC échoue toujours sur les mêmes fichiers

Cause racine : Mauvaise source de réparation (mismatch édition/index), drivers de filtrage tiers, ou la corruption est dans des zones que SFC ne corrige pas (ou des fichiers sont remplacés au démarrage).

Correction : Confirmez l’édition avec DISM /Get-CurrentEdition, confirmez l’index WIM, relancez avec la bonne source. Essayez SFC hors ligne. Si persistant, envisagez une réparation par mise à niveau sur place.

6) Symptom : Échec d’installation de fonctionnalité (NetFx3, RSAT, packs de langue) et DISM se plaint

Cause racine : Payloads non présents localement et Windows Update/WSUS ne peut pas les fournir ; le nettoyage des composants a supprimé les copies locales.

Correction : Fournissez une source correspondant à l’OS et utilisez /LimitAccess. Standardisez la distribution des payloads de fonctionnalités si vous êtes dans un réseau verrouillé.

7) Symptom : Les réparations réussissent mais les mises à jour échouent toujours

Cause racine : Toutes les erreurs de mise à jour ne sont pas de la corruption. Cela peut être la pile de maintenance, la politique, ou une régression d’une mise à jour spécifique.

Correction : Utilisez DISM/SFC pour éliminer les problèmes d’intégrité, puis dépannez Windows Update séparément (journaux d’événements, historique des mises à jour, politique). Ne continuez pas à réparer une image saine parce qu’une mise à jour est bloquée par la politique.

Listes de contrôle / plan pas à pas

Checklist A : Réparation standard en ligne (la plupart des cas)

1. Confirmez l’espace libre (visez plusieurs Go, plus c’est mieux).
2. Exécutez DISM /CheckHealth.
3. Si nécessaire, exécutez DISM /ScanHealth.
4. Exécutez DISM /RestoreHealth.
5. Exécutez sfc /scannow.
6. Redémarrez si quelque chose a été réparé.
7. Relancez sfc /scannow pour confirmer « no integrity violations ».
8. Si les mises à jour échouaient, retentez la mise à jour.

Checklist B : Réparation en ligne avec source contrôlée (WSUS/WU peu fiable ou bloqué)

1. Montez l’ISO correct (correspondant à la build/édition autant que possible).
2. Trouvez le bon index avec DISM /Get-WimInfo.
3. Exécutez DISM /RestoreHealth avec /Source et /LimitAccess.
4. Exécutez sfc /scannow.
5. Redémarrez et validez.

Checklist C : Réparation hors ligne depuis WinRE/PE (système instable ou non amorçable)

1. Identifiez la lettre du volume Windows dans l’environnement de récupération (ce n’est peut-être pas C:).
2. Exécutez DISM hors ligne contre /Image:<drive>:\ avec une source connue bonne.
3. Exécutez SFC hors ligne avec /offbootdir et /offwindir.
4. Redémarrez et validez.
5. Si la corruption revient rapidement, priorisez les diagnostics disque et mémoire.

Checklist D : Pratique pour les flottes (pour arrêter de dépanner machine par machine)

1. Standardisez les médias de réparation pour chaque build et édition d’OS que vous supportez.
2. Documentez le mappage d’index une fois ; ne le redécouvrez pas pendant les incidents.
3. Faites respecter l’ordre DISM-then-SFC dans les runbooks et scripts.
4. Collectez et centralisez les résultats (succès/échec + codes d’erreur clés) pour repérer les tendances.
5. Si vous voyez des 0x800f081f répétés, corrigez la distribution de la source de mise à jour ou rendez les sources ISO accessibles.

FAQ

1) Dois-je exécuter DISM ou SFC en premier ?

DISM en premier dans la plupart des cas : réparez le magasin de composants, puis exécutez SFC pour réparer les fichiers système protégés. La dépendance s’écoule ainsi.

2) Si DISM dit « No component store corruption detected », SFC est-il inutile ?

Non. DISM vérifie le magasin ; SFC vérifie les fichiers système déployés. Vous pouvez avoir des problèmes au niveau fichier sans corruption du magasin. Exécutez SFC si les symptômes suggèrent des dommages aux fichiers système.

3) Pourquoi SFC dit-il avoir réparé des fichiers mais mon problème persiste ?

Soit le problème n’était pas causé par une corruption de fichiers système protégés, soit le système se re-corrompt à cause d’un stockage défaillant, d’un chemin de maintenance cassé, ou de drivers de filtrage tiers. Confirmez avec DISM et vérifiez la santé du disque.

4) Que signifie réellement l’erreur DISM 0x800f081f ?

DISM ne peut pas localiser les payloads requis. Cela peut être parce que Windows Update/WSUS n’est pas joignable, la politique le bloque, ou votre ISO/index fourni ne correspond pas à ce que DISM attend.

5) Ai-je besoin d’une ISO à chaque fois ?

Non. Si Windows Update/WSUS est sain et autorisé, DISM répare souvent en ligne sans média local. Dans les réseaux verrouillés, avoir l’ISO correcte sous la main fait la différence entre 10 minutes et un ping-pong de tickets.

6) Puis-je exécuter DISM et SFC sur un serveur en heures de production ?

Généralement oui, mais traitez cela comme une action de maintenance. C’est intensif en disque et CPU et peut concurrencer les charges. Sur les systèmes critiques, planifiez-le ou validez l’impact dans une fenêtre de maintenance.

7) Quelle est la différence entre /CheckHealth et /ScanHealth ?

/CheckHealth est rapide et indique si une corruption est signalée. /ScanHealth effectue une analyse plus approfondie et peut prendre plus de temps. Si vous avez besoin d’un signal réel, utilisez /ScanHealth.

8) Dois-je utiliser /StartComponentCleanup pour réparer une corruption ?

Non. Le nettoyage n’est pas un mécanisme de réparation. Exécutez-le après des réparations et quand vous êtes sûr de ne pas avoir besoin des composants de retour arrière. En abuser peut rendre la récupération hors ligne plus difficile.

9) Pourquoi DISM utilise WinSxS, et pourquoi ce dossier est-il énorme ?

WinSxS prend en charge la maintenance, les composants côte-à-côte et le retour arrière des mises à jour. Ce n’est pas juste du « gaspillage » ; c’est une partie du mécanisme de maintenance de Windows. Vous pouvez réduire sa taille en toute sécurité avec le nettoyage des composants, mais ne le traitez pas comme un cache à supprimer.

10) Quand dois-je arrêter de réparer et simplement réimager ?

Si la corruption revient après un cycle DISM+SFC réussi, ou si DISM ne peut pas réparer même avec des sources correctes, ou si des problèmes de disque/RAM sont suspectés. Pour les flottes, reimager est souvent moins coûteux que du dépannage artisanal.

Étapes suivantes que vous pouvez réellement faire aujourd’hui

Voici la posture opérationnelle pratique : utilisez DISM pour réparer le magasin de composants, puis utilisez SFC pour réparer le système en cours d’exécution. Lisez la sortie comme si elle vous disait quoi faire ensuite — parce que c’est le cas.

1. Au prochain ticket « Windows se comporte étrangement », exécutez DISM /CheckHealth et /ScanHealth avant de commencer à réinstaller des applications.
2. Si la corruption est réparable, exécutez DISM /RestoreHealth. Si vous obtenez 0x800f081f, arrêtez-vous et fournissez la source correcte.
3. Exécutez sfc /scannow, redémarrez et confirmez l’intégrité.
4. Si les mêmes machines rechutent, vérifiez la santé du disque et votre source de mise à jour. La corruption récurrente est généralement une cause système, pas de la « malchance ».
5. Pour les équipes : standardisez les sources ISO et le mappage d’index, et intégrez l’ordre DISM-then-SFC dans vos runbooks et scripts.

Faites-le dans le bon ordre et vous réparerez plus de machines avec moins d’héroïsme. Faites-le dans le mauvais ordre et vous apprendrez beaucoup sur les logs CBS — principalement à contrecœur.