SFC affiche « Windows Resource Protection found corrupt files but was unable to fix some of them » : comment interpréter le message, lire CBS.log et quoi faire (Windows 10/11)

Après un SFC /scannow, Windows affiche « Windows Resource Protection found corrupt files but was unable to fix some of them ». Voici comment lire correctement CBS.log, comprendre ce faux positif fréquent, et appliquer en toute sécurité les vérifications réellement utiles.

Sommaire

Contexte et diagnostic en une phrase

Si le journal CBS.log contient [SR] Repair complete – SFC was successful. No corrupt files were found and no replacements were made., alors votre système est considéré comme sain : le message inquiétant vu dans la console est un texte générique qui ne reflète pas l’état réel.

Symptômes typiques

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

Vous avez peut‑être enchaîné plusieurs commandes :

DISM /Online /Cleanup-Image /RestoreHealth (ou des variantes hors ligne avec /Source:install.wim) qui se terminent par « The operation completed successfully ».
Un nouveau SFC /scannow qui réaffiche le même avertissement.

La clé pour trancher n’est pas le message à l’écran, mais ce que dit réellement CBS.log.

Procédure rapide : vérifier le verdict dans `CBS.log`

Ouvrez PowerShell (Exécuter en tant qu’administrateur).
Exécutez :

findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log &gt; "%userprofile%\Desktop\sfcdetails.txt"
notepad "%userprofile%\Desktop\sfcdetails.txt"

Interprétez le fichier sfcdetails.txt :

Si vous voyez [SR] Repair complete suivi de SFC was successful. No corrupt files were found and no replacements were made. → aucune corruption active. Vous pouvez ignorer l’avertissement de la console.
Si vous voyez des lignes [SR] Cannot repair member file ... ou Hashes for file member do not match → poursuivez avec la section « Mesures supplémentaires » plus bas.

Pourquoi ce message apparaît‑il alors que tout va bien ?

Sur Windows 10/11, SFC peut imprimer un texte d’avertissement par défaut quand :

Un fichier système temporaire était verrouillé pendant la première passe, puis a été vérifié sur une seconde passe interne.
Le magasin de composants (WinSxS) a été nettoyé récemment : quelques entrées sont « en attente » au moment du scan.
Des composants optionnels (polices, langues, drivers non‑critiques) diffèrent mais n’affectent pas l’intégrité du noyau.

Dans ces cas, CBS.log arbitre : s’il conclut « SFC was successful », le système est intact.

Tableau d’interprétation rapide

Ce que vous voyez	Signification	Action recommandée
Console : « found corrupt files… » Journal : `[SR] Repair complete / SFC was successful`	Faux positif / message générique	Aucune action. Refaire un scan dans quelques jours si vous voulez être rassuré.
`[SR] Cannot repair member file "xxx"`	Fichier système non réparé par SFC	Lancer `DISM /RestoreHealth`, puis `SFC /scannow`.
DISM : « The operation completed successfully »	Magasin de composants restauré	Relancer `SFC /scannow` pour réparer/valider les fichiers.
`[SR] Repaired file ...`	Un ou plusieurs fichiers ont été remplacés	Redémarrer si demandé, contrôler à nouveau.

Mesures supplémentaires (facultatives mais sûres)

Si vous souhaitez boucler le contrôle proprement — même si tout indique que la machine est saine — effectuez ce trio, dans cet ordre :

DISM /Online /Cleanup-Image /ScanHealth (analyse rapide)
DISM /Online /Cleanup-Image /RestoreHealth (réparation du magasin WinSxS)
SFC /scannow (vérification/auto‑réparation finale)

Puis, validez l’état du disque système :

chkdsk C: /scan

Remarque : /scan est non bloquant et sans risque. Les options /f ou /r planifient une réparation au redémarrage et ne sont à utiliser que si /scan signale des erreurs.

Lecture avancée de `CBS.log` : reconnaître les cas réels de corruption

Voici un condensé des messages [SR] que vous pourriez rencontrer et leur interprétation :

[SR] Verify and Repair Transaction completed. All files and registry keys listed in this transaction have been successfully repaired : la transaction a tout réparé ; OK.
[SR] Cannot repair member file "xxx", version yyy : fichier non réparé par SFC ; généralement corrigé après DISM /RestoreHealth.
[SR] Source file in store is also corrupted : le magasin de composants est touché ; DISM à exécuter avec une source saine.

Bien utiliser DISM avec une source `install.wim`/`.esd`

Si l’image en ligne était réellement endommagée, vous avez la bonne approche avec /Source:<chemin>. Les points essentiels :

La source (install.wim ou install.esd) doit correspondre à la même version et édition que votre Windows (ex. Windows 11 Pro 22H2).
Identifiez l’index à utiliser dans le WIM/ESD avant la restauration.

Exemples de commandes utiles :

DISM /Get-WimInfo /WimFile:E:\sources\install.wim

REM > Supposons que l'édition visée corresponde à l'index 6
DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:E:\sources\install.wim:6 /LimitAccess

Si vous avez un install.esd, la syntaxe est identique en remplaçant wim: par esd:. /LimitAccess force DISM à n’utiliser que votre source locale, sans passer par Windows Update.

Alternative : exécuter SFC en mode hors ligne

Rares sont les cas où des verrous empêchent SFC de remplacer un fichier. Vous pouvez alors scanner la partition Windows depuis l’environnement en ligne de commande hors OS :

sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows

À n’utiliser qu’en dernier recours ; la plupart des scénarios se résolvent avec DISM puis SFC dans l’OS en cours d’exécution.

Quand s’inquiéter réellement ?

Le journal contient [SR] Cannot repair ... pour les mêmes fichiers après plusieurs cycles DISM → SFC.
Windows Update échoue systématiquement, ou des fonctionnalités Windows (panneau « Fonctionnalités facultatives ») ne s’installent plus.
Des services critiques (explorateur, menu Démarrer, pile réseau) crashent en boucle.

Dans ces cas, consignez les messages [SR]/DISM, vérifiez le disque avec chkdsk (réparation si nécessaire), puis envisagez une réparation sur place (setup de la même version de Windows en « Conserver mes fichiers et applications »).

Bonnes pratiques pour éviter les faux positifs à l’avenir

Mises à jour régulières (Windows Update) : beaucoup de composants système se rajeunissent via des correctifs cumulés.
Limitez les nettoyages agressifs (suppression manuelle de dossiers WinSxS, scripts hasardeux). Laissez l’OS gérer son magasin.
Désactivez temporairement les antivirus tiers pendant un DISM/SFC si ceux‑ci injectent des pilotes de filtrage qui verrouillent des fichiers.
Évitez les WIM/ESD d’une autre édition (Home vs Pro, N vs non‑N) ou d’un autre canal (Insider vs stable).

Exemples complets prêts à copier‑coller

Exécutez ces blocs tels quels, en Admin :

:: 1) Contrôle magasin + réparation + SFC
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
SFC /scannow

:: 2) Extraction des événements SFC depuis CBS.log
findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log > "%userprofile%\Desktop\sfcdetails.txt"
notepad "%userprofile%\Desktop\sfcdetails.txt"

:: 3) Vérification disque rapide
chkdsk C: /scan

FAQ express

Le message « found corrupt files… » est‑il toujours synonyme de corruption ?
Non. Seul le journal CBS.log tranche. Si [SR] Repair complete et SFC was successful sont présents, vous êtes OK.

Pourquoi DISM réussit et SFC répète l’avertissement ?
Parce que le texte affiché par la console n’est pas toujours mis à jour à l’identique du verdict du journal. C’est un comportement connu sur certaines builds.

Dois‑je forcer chkdsk /f ?
Uniquement si chkdsk /scan signale des erreurs. Sinon, c’est inutile et vous perdriez du temps avec un redémarrage planifié.

Résumé exécutable

Lisez sfcdetails.txt. Si « SFC was successful », considérez l’alerte console comme un faux positif.
Au besoin : DISM /ScanHealth → DISM /RestoreHealth → SFC /scannow.
chkdsk C: /scan pour exclure un problème de disque.
Gardez Windows à jour. Nettoyez %windir%\Logs\CBS\ après résolution, pour éviter l’encombrement des journaux.

Conclusion

Dans le scénario décrit, il n’y a rien à corriger. Le journal CBS confirme que SFC n’a trouvé aucun fichier endommagé et n’a effectué aucun remplacement. Le message « Windows Resource Protection found corrupt files but was unable to fix some of them » peut être ignoré, tant que CBS.log n’indique pas de corruption concrète. Gardez ces réflexes : vérifier le journal, enchaîner DISM puis SFC si nécessaire, et ne pas confondre avertissement générique et véritable panne.

Annexe : paramètres DISM utiles

Option	Rôle	Quand l’utiliser
`/Online`	Cible l’OS en cours d’exécution	Cas général
`/Cleanup-Image`	Travaille sur l’image Windows (magasin WinSxS)	Avec `/ScanHealth` ou `/RestoreHealth`
`/ScanHealth`	Détecte des incohérences dans l’image	Pré‑diagnostic rapide
`/RestoreHealth`	Répare l’image en utilisant WU ou une source locale	Après détection de corruption
`/Source:wim\|esd:<chemin>:<index>`	Force l’utilisation d’une source saine	Quand WU ne peut pas réparer ou en environnement isolé
`/LimitAccess`	Désactive la récupération via WU	Sites sans Internet ou source contrôlée

Annexe : commandes SFC à connaître

SFC /scannow : analyse et réparation automatique des fichiers système.
SFC /verifyonly : analyse seule, plus rapide, aucun remplacement.
SFC /scannow /offbootdir=C:\ /offwindir=C:\Windows : exécution hors ligne.

En bref : si CBS.log conclut « SFC was successful », votre machine est saine. Le message en console peut être mis de côté. Concentrez‑vous sur une vérification périodique et sur les mises à jour pour rester serein.

SFC affiche « Windows Resource Protection found corrupt files but was unable to fix some of them » : comment interpréter le message, lire CBS.log et quoi faire (Windows 10/11)