Réparer Windows avec PowerShell : exécuter SFC/DISM correctement

SFC vs DISM : ce que chacun répare réellement

SFC (System File Checker) vérifie et répare les fichiers système protégés de Windows à partir du magasin de composants. Pensez-y ainsi : « Est-ce que C:\Windows\System32\something.dll correspond à ce que Windows considère comme correct ? » Si ce n’est pas le cas, SFC tente de le remplacer.

DISM (Deployment Image Servicing and Management) répare le magasin de composants lui-même (WinSxS) et prend également en charge les images hors ligne. Si le magasin est corrompu ou qu’il manque des éléments, SFC ne peut pas récupérer de remplacements propres — alors il se plaint, boucle, ou « répare » dans un état partiellement cassé.

Approche en production : considérez DISM comme réparant l’entrepôt des paquets ; considérez SFC comme réparant les fichiers sur les étagères. Si l’inventaire de l’entrepôt est faux, les étagères ne resteront jamais correctes.

Règle générale qui tient la route :

• Si Windows est démarré et que vous suspectez une corruption : DISM d’abord, puis SFC.
• Si vous avez déjà exécuté SFC et qu’il ne peut pas réparer : arrêtez de le relancer et passez à DISM.
• Si DISM ne trouve pas de sources : vous avez besoin d’un média d’installation correspondant (WIM/ESD) ou d’un chemin WSUS/Windows Update fonctionnel.

Une citation à graver sur tous les canaux d’incident :

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

Voici votre première petite blague : SFC est l’interne qui vérifie chaque fichier ; DISM est le chariot élévateur qui répare l’entrepôt. Ne demandez pas à l’interne de reconstruire l’entrepôt.

Méthode de diagnostic rapide (vérifiez ceci en premier)

Ceci est la procédure de triage « j’ai 10 minutes avant la fin de la fenêtre de changement ». Vous essayez d’identifier le goulet d’étranglement : disque, pile de servicing, sources manquantes, ou simplement un symptôme trompeur.

1) Confirmez que vous êtes élevé et sur la bonne machine

Si vous êtes en session distante ou confronté à des bizarreries UAC, la moitié de vos commandes vont mentir par omission.

2) Vérifiez l’espace disque libre et les signes évidents de I/O

Le servicing a besoin d’espace. Sur des systèmes encombrés, DISM échoue avec des erreurs qui ressemblent à une corruption mais qui signifient en réalité « nulle part où placer les éléments réparés ». Vérifiez aussi que le disque n’est pas en train de mourir lentement.

3) Demandez à DISM si le magasin de composants est réparable

Utilisez les vérifications de santé DISM pour décider si vous effectuez une réparation rapide, une réparation basée sur des sources, ou une récupération hors ligne.

4) Si DISM demande des sources, décidez immédiatement du chemin source

Windows Update via Internet, WSUS, ou ISO local ? Ne devinez pas. Choisissez et engagez-vous.

5) Ensuite seulement lancez SFC

SFC est l’étape finale pour la réparation en ligne. S’il échoue après un nettoyage DISM propre, vous avez soit des dommages hors ligne, des pilotes de filtre tiers, soit un problème plus profond de la pile de servicing.

Faits et historique intéressants (pour comprendre les journaux)

• SFC remonte aux concepts de protection de Windows 98/2000 : l’idée centrale — les fichiers système ne doivent pas être écrasés à la légère — existe depuis des décennies, évoluant de Windows File Protection vers Windows Resource Protection.
• WinSxS n’est pas un cache de doublons « sans raison » : c’est un magasin de composants côte à côte qui prend en charge le servicing, les retours en arrière et plusieurs versions de composants. Il semble gaspilleur jusqu’à ce que vous tentiez de patcher des millions de machines de façon fiable.
• DISM a remplacé des outils de servicing plus anciens (comme PEIMG et Package Manager) à mesure que Windows a évolué vers un modèle unifié pour les images en ligne et hors ligne.
• « Les fichiers source n’ont pas pu être trouvés » signifie souvent « la version ne correspond pas », pas que vous n’avez pas de source. Une machine Windows 11 23H2 ne sera pas satisfaite par une ISO 22H2 prise au hasard.
• Les Servicing Stack Updates (SSU) sont particuliers : ils mettent à jour la mécanique qui installe les mises à jour. Si la mécanique est cassée, les mises à jour et réparations deviennent un cercle vicieux.
• CBS.log est la scène du crime : SFC écrit les détails via le moteur Component-Based Servicing. La sortie à l’écran est volontairement vague ; la véritable histoire est dans les journaux.
• Les vérifications DISM sont peu coûteuses comparées aux réparations : /CheckHealth est rapide ; /ScanHealth est plus approfondi et plus lent ; /RestoreHealth est la tentative de réparation effective.
• Les pilotes de filtre tiers peuvent saboter les réparations : antivirus, DLP, chiffrement et outils « endpoint » accrochent souvent les opérations fichiers d’une manière qui rend SFC/DISM instables.

Préparatifs : conditions qui favorisent les réparations

Avant de lancer des commandes, prenez 2 minutes pour préparer le terrain. C’est là que naissent la plupart des tickets « DISM a échoué ».

Exécuter dans le bon shell, élevé

Utilisez Windows Terminal ou PowerShell en tant qu’administrateur. Si vous êtes dans un environnement contraint (outils distants, Just Enough Administration, serveurs durcis), confirmez que vous avez les droits pour opérer sur l’image.

Avoir suffisamment d’espace libre

En règle générale : conservez au moins 10–15 Go libres sur le volume système pour un servicing confortable. Les disques pleins entraînent des opérations partielles et des erreurs trompeuses.

Rendre explicite le chemin Windows Update / WSUS

DISM peut récupérer le contenu de réparation depuis Windows Update sauf si une stratégie le bloque. En entreprise, les politiques bloquent souvent l’accès et WSUS n’héberge pas les payloads « Features on Demand ». C’est ainsi que vous obtenez des codes d’erreur qui ressemblent à de la corruption mais sont en réalité « source inaccessible ».

Prévoir des redémarrages

Le servicing peut préparer des actions en attente. Si un redémarrage est en attente, traitez-le tôt. Ne lancez pas cinq tentatives de réparation empilées sur un redémarrage en attente puis ne vous étonnez pas que les journaux ressemblent à des spaghettis.

Tâches pratiques de réparation (commandes, sorties, décisions)

Ci-dessous figurent des tâches réelles à exécuter depuis un PowerShell élevé. Chacune inclut (1) la commande, (2) ce que signifie une sortie typique, et (3) la décision à prendre ensuite.

Task 1: Confirm elevation and context

cr0x@server:~$ powershell -NoProfile -Command "[Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent() | % { $_.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) }"
True

Sens : True signifie que vous êtes élevé. False signifie stop : SFC/DISM sera partiel, échouera ou mentira.

Décision : Si False, rouvrez PowerShell « Exécuter en tant qu’administrateur » (ou corrigez votre politique de remoting/JEA).

Task 2: Quick disk space sanity check

cr0x@server:~$ powershell -NoProfile -Command "Get-PSDrive -Name C | Select-Object Name,Used,Free | Format-List"
Name : C
Used : 178.42 GB
Free : 24.88 GB

Sens : Si l’espace libre est faible (quelques Go), les réparations peuvent échouer de manière imprévisible.

Décision : Si faible, libérez de l’espace d’abord (supprimez les fichiers temporaires, déplacez des données, ou étendez le disque). Ne « tentez quand même » pas et n’aggravez pas le problème.

Task 3: Check for pending reboot (servicing often requires it)

cr0x@server:~$ powershell -NoProfile -Command "Test-Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending'"
True

Sens : True indique qu’un redémarrage est en attente.

Décision : Redémarrez maintenant si possible. Si vous ne pouvez pas, attendez-vous à ce que DISM/SFC se comportent de façon étrange et consignent des « opérations en attente ».

Task 4: DISM quick check (is corruption already flagged?)

cr0x@server:~$ dism /online /cleanup-image /checkhealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

No component store corruption detected.
The operation completed successfully.

Sens : « No corruption detected » est un bon signe. Cela ne prouve pas que le système est sain ; cela signifie que DISM ne pense pas que le magasin est corrompu.

Décision : Si vous traquez des anomalies de fichiers système, continuez avec SFC. Si vous traquez des échecs de mises à jour, envisagez quand même /ScanHealth.

Task 5: DISM deeper scan (more authoritative)

cr0x@server:~$ dism /online /cleanup-image /scanhealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

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

Sens : « Repairable » signifie que DISM a trouvé une corruption et pense pouvoir la réparer.

Décision : Exécutez /RestoreHealth. S’il indique « not repairable », arrêtez et planifiez une réparation hors ligne ou une mise à niveau sur place.

Task 6: DISM repair using Windows Update (default online path)

cr0x@server:~$ dism /online /cleanup-image /restorehealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

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

Sens : C’est le signal « entrepôt réparé ».

Décision : Lancez maintenant SFC. Si SFC ne peut toujours pas réparer, vous avez probablement des problèmes de système de fichiers, des outils endpoint agressifs, ou une corruption hors ligne.

Task 7: SFC repair pass (after DISM)

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. For example C:\Windows\Logs\CBS\CBS.log

Sens : SFC a trouvé des discordances et les a corrigées. Vous n’avez pas fini tant que le système ne se comporte pas et que les mises à jour ne s’installent pas, mais vous pouvez respirer plus facilement.

Décision : Redémarrez si possible. Puis relancez SFC une fois de plus ; « no integrity violations » est votre certificat de santé.

Task 8: SFC verification run (confirm clean state)

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 did not find any integrity violations.

Sens : C’est le résultat souhaité après les réparations.

Décision : Si les symptômes persistent, arrêtez d’imputer la cause à la « corruption » et enquêtez sur les pilotes, les profils, les politiques ou le composant spécifique en échec.

Task 9: When DISM fails with “source files could not be found”

cr0x@server:~$ dism /online /cleanup-image /restorehealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

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.

Sens : DISM n’a pas pu récupérer le payload requis. Causes courantes : WSUS ne le fournit pas ; l’accès à Windows Update est bloqué ; le système est hors ligne ; ou vous avez besoin d’une ISO correspondante.

Décision : Basculez vers une source connue bonne (ISO montée avec la build correspondante) et réessayez avec /Source et /LimitAccess.

Task 10: Mount an ISO and identify the right index to use

cr0x@server:~$ powershell -NoProfile -Command "Mount-DiskImage -ImagePath 'C:\ISO\Win11_23H2_English_x64.iso'; (Get-Volume -DiskImage (Get-DiskImage -ImagePath 'C:\ISO\Win11_23H2_English_x64.iso')).DriveLetter"
E

cr0x@server:~$ dism /get-wiminfo /wimfile:E:\sources\install.wim
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

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

Index : 1
Name : Windows 11 Home
Description : Windows 11 Home

Index : 6
Name : Windows 11 Pro
Description : Windows 11 Pro

The operation completed successfully.

Sens : Vous avez besoin de l’index correspondant à l’édition installée (Home/Pro/Enterprise). Utiliser le mauvais index peut échouer ou « réussir » sans fournir réellement les bons composants.

Décision : Déterminez votre édition (tâche suivante), puis choisissez l’index correct.

Task 11: Confirm installed edition/build (match your source)

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber"
WindowsProductName : Windows 11 Pro
WindowsVersion     : 23H2
OsBuildNumber      : 22631

Sens : Votre média ISO doit correspondre à la famille de version/build et à l’édition. Un décalage est une cause classique de 0x800f081f.

Décision : Utilisez l’index « Pro » (issu de la sortie précédente : index 6) et assurez-vous que l’ISO correspond au même canal de publication.

Task 12: DISM repair using a local WIM source (reliable in locked-down networks)

cr0x@server:~$ dism /online /cleanup-image /restorehealth /source:wim:E:\sources\install.wim:6 /limitaccess
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

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

Sens : Vous avez réparé en utilisant un média local, pas Windows Update.

Décision : Lancez SFC ensuite. Si SFC échoue toujours, vous avez probablement des problèmes de système de fichiers ou des outils endpoint agressifs.

Task 13: If your ISO has install.esd, use it as a source

cr0x@server:~$ dism /get-wiminfo /wimfile:E:\sources\install.esd
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Details for image : E:\sources\install.esd

Index : 6
Name : Windows 11 Pro
Description : Windows 11 Pro

The operation completed successfully.

cr0x@server:~$ dism /online /cleanup-image /restorehealth /source:esd:E:\sources\install.esd:6 /limitaccess
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

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

Sens : L’ESD fonctionne ; il est simplement plus compressé. DISM le prend en charge avec le préfixe approprié.

Décision : Même chose : exécutez SFC, redémarrez, vérifiez.

Task 14: Extract the SFC story from CBS.log (stop reading the entire novel)

cr0x@server:~$ powershell -NoProfile -Command "Select-String -Path $env:windir'\Logs\CBS\CBS.log' -Pattern '\[SR\]' | Select-Object -Last 20"
2026-02-05 09:12:41, Info                  CSI    0000032f [SR] Repairing corrupted file \??\C:\Windows\System32\example.dll from store
2026-02-05 09:12:42, Info                  CSI    00000330 [SR] Verify and Repair Transaction completed. All files and registry keys listed in this transaction have been successfully repaired

Sens : Les lignes avec [SR] sont liées à SFC. Vous pouvez voir exactement ce qui a été réparé (ou ce qu’il n’a pas pu réparer).

Décision : Si vous voyez « cannot repair member file » de façon répétée, retournez à la qualité de la source DISM ou envisagez une réparation hors ligne.

Task 15: Read DISM logs when the error code is vague

cr0x@server:~$ powershell -NoProfile -Command "Get-Content $env:windir'\Logs\DISM\dism.log' -Tail 30"
2026-02-05 09:04:17, Error                 DISM   DISM Package Manager: PID=1220 TID=2480 Failed finalizing changes. - CDISMPackageManager::Finalize(hr:0x800f081f)
2026-02-05 09:04:17, Error                 DISM   DISM Package Manager: PID=1220 TID=2480 The source files could not be found; using /Source is required.

Sens : Les journaux DISM indiquent souvent ce qu’il a tenté (Windows Update ? WSUS ? local ?) et où il a échoué.

Décision : S’il n’a jamais essayé Windows Update à cause d’une politique, corrigez la politique ou utilisez /Source. S’il a essayé une source et l’a rejetée, votre source ne correspond pas.

Task 16: Component store cleanup (useful, but don’t treat it like a cure)

cr0x@server:~$ dism /online /cleanup-image /startcomponentcleanup
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

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

Sens : Cela réduit les composants dépassés ; ça peut récupérer de l’espace disque et réduire la complexité du servicing avec le temps.

Décision : Exécutez ceci après que vous êtes en état sain, pas comme un remède de première ligne pour corruption.

Task 17: Detect file system corruption signs (because SFC can’t fix a lying disk)

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.

Sens : Si CHKDSK signale des erreurs, votre corruption peut être de niveau stockage. DISM/SFC ne peuvent pas surpasser des secteurs défectueux ou des métadonnées endommagées.

Décision : Si des erreurs existent : planifiez une réparation hors ligne (chkdsk /f nécessite un arrêt), vérifiez le SMART, et suspectez des problèmes matériels ou de disque virtuel.

Deuxième petite blague (et la dernière) : les barres de progression DISM sont comme les panneaux d’arrivée d’aéroport — optimistes, vagues, et parfois sans rapport avec la réalité.

Stratégies de réparation hors ligne et sans Internet

Parfois vous ne pouvez pas réparer une image en ligne : elle ne démarre pas de manière fiable, Windows Update est bloqué, le magasin de composants est trop dégradé, ou la machine est dans un réseau restreint. Ce n’est pas la fin ; cela change juste le plan.

Servicing hors ligne : pointer DISM vers un dossier Windows qui n’est pas en cours d’exécution

Si vous démarrez dans WinRE/WinPE ou si vous attachez le disque OS à un autre système, vous pouvez réparer l’image hors ligne. L’important est de savoir quelle lettre de lecteur correspond à quoi dans l’environnement de récupération.

cr0x@server:~$ diskpart
Microsoft DiskPart version 10.0.22621.1

DISKPART> list vol

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info
  ----------  ---  -----------  -----  ----------  -------  ---------  --------
  Volume 0     D   WinRE        NTFS   Partition    980 MB  Healthy
  Volume 1     C   OS           NTFS   Partition    237 GB  Healthy

Décision : Identifiez le répertoire Windows hors ligne, par ex. C:\Windows dans WinRE (il peut être D: sur certains systèmes). Ensuite :

cr0x@server:~$ dism /image:C:\ /cleanup-image /scanhealth
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

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

Si vous avez un média d’installation local monté en E: :

cr0x@server:~$ dism /image:C:\ /cleanup-image /restorehealth /source:wim:E:\sources\install.wim:6 /limitaccess
Deployment Image Servicing and Management tool
Version: 10.0.22621.1

Image Version: 10.0.22631.3007

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

SFC hors ligne (utile après DISM sur une image hors ligne)

SFC peut cibler un répertoire Windows hors ligne avec des chemins explicites.

cr0x@server:~$ sfc /scannow /offbootdir=C:\ /offwindir=C:\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.

Décision : Si DISM+SFC hors ligne réussissent et que le système ne démarre toujours pas, vous avez probablement affaire à un problème de chargeur de démarrage/BCD, des pilotes, ou une mise à jour cassée nécessitant un retour en arrière — pas une corruption générique.

Quand les sources posent problème : la correspondance compte plus que « le plus récent »

Si vous ne faites qu’une chose correctement : faites correspondre le média d’installation à la build et à l’édition installées. Les gens aiment télécharger « l’ISO la plus récente ». C’est ainsi qu’on sème une soirée de perdue.

Approche pratique en entreprise :

• Maintenez une petite bibliothèque interne d’ISOs par canal de publication utilisé par votre parc.
• Consignez les numéros de build dans votre CMDB/inventaire.
• Quand DISM échoue, n’improvisez pas — récupérez l’image connue correspondante.

Erreurs fréquentes : symptôme → cause → correctif

Cette section est volontairement franche. La plupart des « mystères » SFC/DISM sont auto-infligés.

1) Symptom: “SFC found corrupt files but was unable to fix some of them.”

Cause racine : Corruption du magasin de composants ou payloads manquants. SFC tente de remplacer des fichiers depuis un entrepôt cassé.

Correctif : Exécutez dism /online /cleanup-image /restorehealth. S’il renvoie 0x800f081f, utilisez une ISO correspondante avec /source:wim:... /limitaccess. Puis relancez SFC.

2) Symptom: DISM fails with 0x800f081f “source files could not be found.”

Cause racine : Pas d’accès aux payloads Windows Update, WSUS manque les contenus Features on Demand, ou média source non correspondant.

Correctif : Utilisez un WIM/ESD local avec le bon index. Si une politique bloque WU, ajoutez /LimitAccess pour forcer le local uniquement et éviter de longs timeouts.

3) Symptom: DISM runs forever at 20% or 62%.

Cause racine : Pas forcément bloqué — les phases DISM sont irrégulières. Mais cela peut aussi être un stockage lent, un antivirus scannant chaque fichier, ou un blocage de la pile de servicing.

Correctif : Vérifiez la latence disque (Gestionnaire des tâches, compteurs perf), désactivez temporairement le scan endpoint si la politique le permet, et surveillez dism.log pour l’avancement. Si aucun mouvement dans le journal, redémarrez et réessayez une fois ; puis basculez vers le servicing hors ligne.

4) Symptom: SFC keeps “repairing” the same files after every reboot.

Cause racine : Quelque chose réécrit les fichiers système : outils tiers de « tuning », pilotes obsolètes, produits de sécurité, ou gestion de configuration défaillante.

Correctif : Inspectez les entrées [SR] du CBS pour les noms de fichiers ; corrélez avec les logiciels installés et les mises à jour de pilotes. Supprimez le responsable. Relancez DISM+SFC pour stabiliser.

5) Symptom: “The component store is not repairable.”

Cause racine : Dégâts sévères du magasin de composants, souvent aggravés par des mises à jour échouées ou une corruption du stockage.

Correctif : Tentez DISM hors ligne avec une source correcte. Si toujours non réparable, votre chemin pragmatique est une réparation sur place (in-place upgrade) ou une ré-imagerie. Ne passez pas des jours à vouloir être un héros.

6) Symptom: DISM says successful but Windows Update still fails.

Cause racine : Toutes les erreurs de mise à jour ne sont pas causées par la corruption du magasin. Cela peut être la pile de servicing, des actions en attente, ou des problèmes de métadonnées WSUS.

Correctif : Vérifiez les clés de redémarrage en attente, consultez les événements WindowsUpdateClient, et confirmez l’applicabilité des SSU/LCU. Utilisez les journaux DISM et les journaux d’événements pour trouver le paquet réellement en échec.

7) Symptom: SFC fails immediately or reports it cannot perform the requested operation.

Cause racine : Windows Modules Installer (TrustedInstaller) désactivé, Windows Resource Protection cassé, ou erreurs système de fichiers.

Correctif : Assurez-vous que le service TrustedInstaller n’est pas désactivé ; vérifiez chkdsk ; puis lancez DISM. Si les services de servicing sont endommagés, envisagez une réparation hors ligne.

8) Symptom: Repairs work on laptops but not on servers (or vice versa).

Cause racine : Différents canaux de servicing, politiques différentes (WSUS), baselines différentes, ou produits endpoint différents.

Correctif : Standardisez les sources par famille d’OS. Documentez explicitement si DISM est autorisé à atteindre Windows Update. Ne supposez pas la parité entre parcs.

Trois mini-récits d’entreprise issus du terrain

Incident 1: The wrong assumption (WSUS means DISM will find sources)

Une organisation financière disposait d’un parc Windows 10 stable géré par WSUS. Les mises à jour étaient « gérées », ce qui en langage d’entreprise signifie « personne ne se rappelle pourquoi c’était configuré ainsi ». Un sous-ensemble de machines a commencé à échouer lors des mises à jour cumulatives après un cycle de patch routinier. Le support technique a lancé SFC à plusieurs reprises, obtenu le classique « unable to fix some files », puis escaladé.

Le sysadmin de garde a fait la bonne chose et a essayé DISM. Il a échoué avec 0x800f081f. L’hypothèse immédiate fut : « Mais nous avons WSUS. Il devrait avoir les bits. » Cette hypothèse est un piège. WSUS héberge couramment des mises à jour, mais pas nécessairement les payloads complets et le contenu Features on Demand que DISM attend pour la restauration du magasin de composants.

Ils ont perdu une journée à essayer différentes séquences, différents redémarrages, et beaucoup d’optimisme. La réparation fut embarrassante une fois qu’ils ont affronté la réalité : monter un média d’installation correspondant, exécuter DISM avec une /Source locale et /LimitAccess, puis exécuter SFC.

Ce qui a changé après l’incident n’était pas seulement un runbook. Ils ont ajouté une exigence stricte : chaque build OS prise en charge devait avoir une ISO correspondante en interne, et les tickets devaient inclure le numéro de build et l’édition. Le mode de défaillance a disparu parce qu’ils ont cessé de traiter « mises à jour gérées » comme synonyme de « sources de réparation disponibles ».

Incident 2: The optimization that backfired (aggressive cleanup during patch windows)

Une grande entreprise est devenue obsédée par l’espace disque après quelques pannes de serveurs causées par des volumes C: pleins. Quelqu’un a déployé une politique de « nettoyage » : exécuter régulièrement un nettoyage des composants et supprimer les fichiers temporaires pendant les fenêtres de maintenance. Sur le papier, sensé. En pratique, ils l’ont combiné avec du patching et des reports de redémarrage.

Lors d’une fenêtre de patch, un ensemble de serveurs applicatifs a commencé à signaler des anomalies de servicing. DISM devenait lent, parfois en timeout. SFC a commencé à trouver des corruptions à répétition. L’équipe était convaincue d’un malware ou d’un problème de baie de stockage.

En réalité, c’était une contention de servicing auto-infligée. Le nettoyage tournait pendant que les mises à jour se préparaient, avec l’antivirus analysant le tumulte résultant. Le magasin de composants n’était pas tant « corrompu » que constamment en mouvement, avec des opérations en attente et une activité fichier intense. Ils avaient optimisé pour « moins d’espace utilisé » et par erreur supprimé la maintenance prévisible.

La correction fut ennuyeuse : séparer les étapes de maintenance. Patch, redémarrage, validation. Ensuite seulement exécuter le nettoyage des composants, et seulement quand la pression disque l’exigeait. Les performances se sont stabilisées, les outils de réparation ont arrêté de timeout, et la classe d’incidents a disparu.

Incident 3: The boring but correct practice (log-first, source-controlled runbooks)

Une entreprise de santé avait un contrôle strict des changements et une équipe sécurité qui détestait les correctifs ad hoc. Leur équipe plateforme Windows a construit un runbook ressemblant à un playbook SRE : préflight checks, points de décision, et commandes exactes. Il était versionné et mis à jour après chaque revue d’incident.

Un jour, un lot de kiosques a commencé à échouer au lancement d’applications après une mise à jour. Les techniciens ont suivi le runbook : vérifier l’espace libre, vérifier le redémarrage en attente, DISM scan, DISM restore, SFC, puis extraire les lignes [SR] du CBS.log. Au lieu de « essayer des trucs », ils sont revenus avec des preuves : DISM échouait l’acquisition de sources à cause d’une politique, et l’index source ne correspondait pas à l’édition installée.

L’équipe plateforme n’a pas eu besoin d’ouvrir une session en remote et de deviner. Ils ont poussé une ISO correspondante sur un partage de fichiers, ajusté le runbook pour inclure la vérification de l’édition, et corrigé le parc. Personne n’a célébré parce que c’était routinier, ce qui est le plus grand compliment en opérations.

La leçon : la pratique peu sexy — journaux d’abord, étapes répétables, sources connues bonnes — bat l’héroïsme. À chaque fois.

Listes de contrôle / plan étape par étape

Checklist A: Standard online repair (recommended default)

1. Ouvrir PowerShell en tant qu’administrateur.
2. Confirmer l’espace libre (viser 10–15 Go+ sur C:).
3. Vérifier le redémarrage en attente ; redémarrer si possible.
4. Exécuter dism /online /cleanup-image /checkhealth.
5. Si quelque chose semble suspect ou si les mises à jour échouent, exécuter /scanhealth.
6. Exécuter dism /online /cleanup-image /restorehealth.
7. Exécuter sfc /scannow.
8. Redémarrer.
9. Exécuter sfc /scannow à nouveau pour confirmer « no integrity violations ».
10. Si toujours cassé, extrayez les lignes pertinentes du CBS.log et lisez dism.log avant d’essayer autre chose.

Checklist B: Locked-down enterprise (no Windows Update access)

1. Confirmer l’édition et la build OS (Get-ComputerInfo).
2. Monter l’ISO correspondante à cette release et édition.
3. Obtenir les indexes WIM/ESD (dism /get-wiminfo).
4. Exécuter dism /online /cleanup-image /restorehealth /source:wim:...:INDEX /limitaccess (ou équivalent ESD).
5. Exécuter SFC.
6. Si les échecs persistent, consultez CBS/DISM et envisagez une réparation hors ligne.

Checklist C: Offline repair (system unstable or won’t boot)

1. Démarrer en WinRE/WinPE.
2. Identifier la lettre du volume OS (diskpart ou vérifications dir).
3. Monter le média d’installation correspondant.
4. Exécuter DISM contre l’image hors ligne : dism /image:X:\ /cleanup-image /restorehealth /source:wim:....
5. Exécuter SFC hors ligne avec /offbootdir et /offwindir.
6. Redémarrer et valider.
7. Si toujours en échec : planifier une réparation sur place ou une ré-imagerie. Le temps est une ressource aussi.

Operational guardrails (what to avoid)

• Ne lancez pas SFC dix fois en espérant qu’il « finira par réparer ». Ce n’est pas de la persistance ; c’est du déni.
• Ne mélangez pas nettoyage, patching et réparations dans la même fenêtre de maintenance à moins d’aimer les résultats ambigus.
• Ne supposez pas que votre ISO « presque correcte » fonctionnera. Le servicing est pointilleux parce qu’il doit l’être.
• N’ignorez pas la santé du stockage. La corruption a souvent un complice matériel.

FAQ

1) Should I run SFC or DISM first?

Sur une installation Windows en cours d’exécution : DISM d’abord, puis SFC. DISM répare le magasin de composants dont dépend SFC.

2) What does “Windows Resource Protection found corrupt files” actually mean?

Cela signifie que des fichiers sur le disque ne correspondaient pas aux versions protégées attendues. S’il indique qu’il les a réparés, il a copié des versions connues bonnes depuis le magasin de composants (ou des remplacements mis en attente) et a consigné les détails dans CBS.log.

3) If DISM says “No component store corruption detected,” can I stop?

Si votre seul objectif est la santé du magasin de composants, oui. Si vous avez des symptômes — plantages, comportement étrange du système — exécutez quand même SFC. DISM peut être propre alors que des fichiers système individuels sont incorrects.

4) Why does DISM fail with 0x800f081f even though I have an ISO?

Le plus souvent parce que l’ISO ne correspond pas à la famille de build installée ou que vous avez choisi le mauvais index (édition). Confirmez la build/édition, puis utilisez le bon index WIM/ESD dans /Source.

5) Is it safe to run DISM and SFC on production servers?

Généralement oui, mais traitez cela comme une maintenance : planifiez-la, surveillez les besoins de redémarrage et attendez-vous à un impact sur les performances. Sur des charges sensibles à la latence, exécutez pendant une fenêtre calme.

6) Do I need to disable antivirus or endpoint protection?

Pas par défaut. Mais si DISM/SFC sont extrêmement lents, échouent à répétition sur les mêmes fichiers, ou que les journaux montrent des problèmes d’accès, assouplir temporairement les analyses (conformément à la politique) peut aider. Documentez-le et réactivez immédiatement.

7) What’s the difference between DISM /CheckHealth and /ScanHealth?

/CheckHealth est rapide et vérifie si une corruption a déjà été signalée. /ScanHealth effectue une analyse plus approfondie pour détecter la corruption et peut prendre beaucoup plus de temps.

8) Can SFC/DISM fix Windows Update problems?

Parfois. Si les échecs de mise à jour sont causés par une corruption du magasin de composants, oui. Si la cause racine est les métadonnées WSUS, des restrictions de politique, une chaîne SSU cassée, ou des opérations en attente, il faudra diagnostiquer spécifiquement les mises à jour.

9) When should I stop trying and reimage or do an in-place repair?

Si DISM indique que le magasin de composants n’est pas réparable, ou si les réparations réussissent mais que le système reste instable avec des corruptions récurrentes, cessez de perdre du temps. DISM hors ligne avec une source correcte est votre ultime tentative technique avant une réparation sur place/re-imagerie.

10) Where do I look when the console output is unhelpful?

C:\Windows\Logs\CBS\CBS.log pour les détails SFC (filtrer [SR]). C:\Windows\Logs\DISM\dism.log pour les décisions DISM, la sélection des sources et les erreurs détaillées.

Conclusion : quoi faire ensuite

Si Windows se comporte mal et que vous suspectez une corruption, ne commencez pas par des rituels. Commencez par une séquence contrôlée.

1. Assurez-vous d’être élevé et d’avoir de l’espace disque.
2. Redémarrez si un drapeau de redémarrage est présent.
3. Exécutez les vérifications DISM, puis /RestoreHealth.
4. Exécutez sfc /scannow, redémarrez et confirmez l’état propre.
5. Si DISM ne trouve pas de sources, arrêtez d’improviser : montez un média d’installation correspondant et utilisez /Source avec le bon index.
6. Si les résultats restent mauvais, lisez CBS.log et dism.log avant de toucher à autre chose.

La bonne façon de « réparer Windows » n’est pas une commande magique. C’est d’exécuter la chaîne de réparation avec des entrées propres, d’examiner les preuves, et de prendre la décision suivante en fonction de ce que le système vous a effectivement dit.