Toutes vos applis Microsoft Store refusent de s’ouvrir sous Windows 11 23H2 avec l’erreur « Bad Image » ? La cause : le package Microsoft.VCLibs.140.00 corrompu (DLL à 0 octet). Voici une procédure fiable pour réparer sans réinstaller Windows.
Symptômes et message d’erreur
Sur Windows 11 23H2, toutes les applications UWP/Microsoft Store (Bloc‑notes/Notepad, Photos, Calculatrice, Microsoft Store, etc.) ne se lancent plus. À chaque tentative d’ouverture, une boîte de dialogue « Bad Image » s’affiche, par exemple :
...\Microsoft.VCLibs.140.00_14.0.33519.0_x64_...\VCRUNTIME140_1_APP.dll
is either not designed to run on Windows or it contains an error.
Status 0xc0000020
En inspectant le dossier du package, on découvre que des fichiers essentiels comme VCRUNTIME140_APP.dll ou MSVCP140_APP.dll pèsent 0 octet — signes clairs d’un package tronqué.
Les tentatives classiques échouent typiquement : réinstallation des redistribuables VC++ « Desktop », DISM /Online /Cleanup-Image /RestoreHealth, sfc /scannow. C’est normal : ces actions ne réparent pas les frameworks AppX/MSIX gérés par le Microsoft Store.
Pourquoi cela arrive
Les apps modernes (UWP/Store) s’appuient sur des framework packages — dont Microsoft.VCLibs.140.00 — déposés dans C:\Program Files\WindowsApps. Lors d’une mise à jour interrompue (coupure réseau/énergie, verrouillage antivirus, disque saturé ou lent), l’extraction des fichiers peut échouer : on se retrouve avec des DLL à 0 octet. Résultat : au lancement, Windows charge un binaire invalide et renvoie 0xc0000020 (Invalid Image).
Important : les redistribuables VC++ classiques (MSI/EXE) ciblent les applis Win32/desktop et n’ont aucun effet sur les applis Store. Les applis UWP consomment un runtime distinct : Microsoft.VCLibs.140.00 (et parfois Microsoft.VCLibs.140.00.UWPDesktop), déployé par le Store.
Réparation express : résumé de la procédure
La stratégie gagnante consiste à casser la référence au package corrompu puis à laisser Windows/Store réinstaller une copie saine.
| Étape | Action | But / résultat |
|---|---|---|
| Confirmer la corruption | dir "C:\Program Files\WindowsApps\Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe" /a | Vérifier que les DLL critiques sont à 0 octet. |
| Forcer Windows à recréer le package | Télécharger l’outil AdvancedRun (NirSoft). Ouvrir une Invite de commandes en contexte TrustedInstaller. Exécuter :cmdcd /d "C:\Program Files\WindowsApps"ren Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe VCLibs.OLD Redémarrer Windows. | Le renommage « casse » la référence au package. Au prochain démarrage, Windows/Store détecte l’absence et prépare une restauration. |
| Réinstaller VCLibs 140 | Méthode A (hors‑ligne) : exécuter le .Appx correspondant (Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe.Appx) et cliquer Installer.Méthode B (Store) : lancer Microsoft Store ; il réinstalle automatiquement le package sain. | Des DLL valides (taille non nulle) sont copiées ; les applis UWP redémarrent normalement. |
| Vérifier | Ouvrir Notepad, Photos, Calculatrice… | Plus d’erreur « Bad Image » ; tout se lance. |
Étapes détaillées et bonnes pratiques
1) Identifier rapidement la version et l’architecture
Deux approches permettent de cibler le bon dossier :
- À partir du message d’erreur : la boîte « Bad Image » expose le chemin contenant la version et l’architecture (
_x64__,_x86__,_arm64__). - En PowerShell (en tant qu’Administrateur) :
Get-AppxPackage -AllUsers -Name Microsoft.VCLibs.140.00 |
Select-Object Name, PackageFullName, Version, Architecture
Si vous voyez aussi Microsoft.VCLibs.140.00.UWPDesktop, notez sa version : certaines applis desktop packagées l’utilisent.
2) Confirmer la corruption (DLL à 0 octet)
Ouvrez une invite Administrateur et listez le dossier WindowsApps ciblé :
dir "C:\Program Files\WindowsApps\Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe" /a
Vérifiez la taille des fichiers MSVCP140_APP.dll, VCRUNTIME140_APP.dll, VCRUNTIME140_1_APP.dll. S’ils sont à 0 octet, la panne est bien localisée.
3) Obtenir un shell « TrustedInstaller » pour renommer
Le dossier WindowsApps est protégé (propriétaire : TrustedInstaller). Un simple Administrateur ne pourra ni renommer ni remplacer. Utilisez un utilitaire dédié (par exemple AdvancedRun) pour lancer cmd.exe en TrustedInstaller. Alternatives connues : NSudo, PowerRun. Ne prenez pas possession du dossier ; c’est risqué et inutile.
- Ouvrez AdvancedRun → Run As : TrustedInstaller.
- Command :
cmd.exe. - Dans la console :
cd /d "C:\Program Files\WindowsApps"ren Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe VCLibs.OLD
Astuce : si la version diffère, appuyez sur TAB après Microsoft.VCLibs.140.00_ pour l’autocomplétion. En cas d’« Accès refusé », assurez‑vous d’être bien en TrustedInstaller ou démarrez en Mode sans échec puis recommencez.
4) Redémarrer puis réinstaller le package
Après le renommage, redémarrez. Deux chemins possibles :
- Hors‑ligne (Appx local) : double‑cliquez le .Appx correspondant à votre architecture (x64/x86/arm64) et à la famille
Microsoft.VCLibs.140.00. Confirmez l’installation. - Via Microsoft Store : ouvrez le Store. Si la réparation ne démarre pas d’elle‑même, déclenchez la mise à jour de n’importe quelle app ; le framework VCLibs sera rapatrié en dépendance.
Vous préférez PowerShell ? Placez‑vous dans le dossier où se trouve le .Appx :
PowerShell -NoProfile -ExecutionPolicy Bypass
Add-AppxPackage -Path .\Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe.Appx
Options utiles si la version installée est supérieure (downgrade bloqué) :
Add-AppxPackage -Path .\Microsoft.VCLibs.140.00_<version>_x64__8wekyb3d8bbwe.Appx `
-ForceUpdateFromAnyVersion -ForceApplicationShutdown
5) Vérifications post‑réparation
- Relistez le dossier WindowsApps : les DLL ne doivent plus être à 0 octet.
- Ouvrez Notepad, Photos, Calculatrice, Microsoft Store.
- Contrôlez la version réellement en place :
Get-AppxPackage -AllUsers -Name Microsoft.VCLibs.140.00 |
Select-Object PackageFullName, Version, Architecture
Tableau d’aide au choix du package
| Type de machine | Dossier WindowsApps (exemple) | Package à installer | Remarques |
|---|---|---|---|
| PC x64 (la majorité) | ..._x64__8wekyb3d8bbwe | Microsoft.VCLibs.140.00_..._x64__8wekyb3d8bbwe.Appx | Installez aussi la variante .UWPDesktop si des apps desktop packagées la réclament. |
| PC x86 (rare) | ..._x86__8wekyb3d8bbwe | Microsoft.VCLibs.140.00_..._x86__8wekyb3d8bbwe.Appx | Sur un OS 32 bits uniquement. |
| PC ARM64 | ..._arm64__8wekyb3d8bbwe | Microsoft.VCLibs.140.00_..._arm64__8wekyb3d8bbwe.Appx | Privilégiez ARM64 même si certaines apps x64 fonctionnent en émulation. |
Méthodes alternatives (si le renommage échoue)
Réparation via réinitialisation du Microsoft Store
Cette méthode ne résout pas des fichiers à 0 octet dans la plupart des cas, mais elle peut accélérer la régénération des packages :
- Réinitialiser le cache du Store :
Win+R→wsreset.exe(patienter jusqu’à l’ouverture du Store). - Réinitialiser l’app Microsoft Store : Paramètres → Applications → Microsoft Store → Options avancées → Réparer puis Réinitialiser.
Réinstaller via PowerShell avec détection automatique
Le script ci‑dessous vérifie l’existence des DLL à 0 octet pour Microsoft.VCLibs.140.00 et, si besoin, propose l’installation depuis un .Appx situé dans le dossier courant :
$pkg = Get-AppxPackage -AllUsers -Name Microsoft.VCLibs.140.00
$base = "C:\Program Files\WindowsApps\$($pkg.PackageFullName)"
$files = @("MSVCP140_APP.dll","VCRUNTIME140_APP.dll","VCRUNTIME140_1_APP.dll")
$zero = $false
foreach ($f in $files) {
$p = Join-Path $base $f
if (Test-Path $p) {
$len = (Get-Item $p).Length
if ($len -eq 0) { $zero = $true; Write-Host "Fichier vide: $p" -ForegroundColor Red }
}
}
if ($zero) {
Write-Host "Des DLL sont à 0 octet. Restaurez le package depuis le .Appx correspondant." -ForegroundColor Yellow
# Exemple d'installation locale :
# Add-AppxPackage -Path .\Microsoft.VCLibs.140.00_<version>_x64__8wekyb3d8bbwe.Appx
} else {
Write-Host "Aucune DLL à 0 octet détectée." -ForegroundColor Green
}
Note : ce script n’effectue pas le renommage ni l’élévation TrustedInstaller — il documente l’état et automatise l’installation si le .Appx est prêt.
Safe Mode / Environnement de récupération
Si un processus verrouille le dossier, démarrez en Mode sans échec (Paramètres → Récupération → Démarrage avancé) et répétez l’opération de renommage via un shell TrustedInstaller. Avec BitLocker activé, ayez la clé de récupération à portée si vous intervenez depuis l’Environnement de récupération Windows (WinRE).
Ce qui ne marche (presque) jamais
- Réinstaller les « Microsoft Visual C++ Redistributable » (x86/x64). Utile pour les apps Win32, sans effet sur les apps Store.
sfc /scannowetDISM /RestoreHealth. Ces outils vérifient les composants Windows, pas les packages AppX/MSIX de l’utilisateur.- Prendre possession de
WindowsAppspour « forcer » un remplacement. C’est risqué, et cela complique les mises à jour futures. Préférez le contexte TrustedInstaller.
Diagnostic avancé
Événements AppXDeploymentServer
Les déploiements AppX sont journalisés. Ouvrez Observateur d’événements → Journaux des applications et services → Microsoft → Windows → AppXDeployment‑Server → Operational. Recherchez des erreurs autour du moment de la panne (ID d’événement 404, 465, 597, etc.).
Vérifier la santé du disque
Des écritures corrompues peuvent venir d’un disque instable. En invite Admin :
chkdsk C: /scan
Sur SSD NVMe, mettez à jour le firmware si le fabricant le propose. Gardez ≥ 15 % d’espace libre pour laisser respirer les mises à jour Store/MSIX.
Cas particuliers et pièges fréquents
- Plusieurs versions de VCLibs présentes : Windows conserve parfois des versions en side‑by‑side. Renommez uniquement la version dont les fichiers sont à 0 octet (celle citée dans l’erreur).
- Architecture ARM64 : n’installez pas la version x64 du .Appx sur une machine ARM64 ; le Store gère l’émulation, mais le framework doit correspondre à l’architecture.
- Antivirus un peu trop zélé : pendant la réinstallation du package, désactivez temporairement l’analyse en temps réel si elle bloque l’écriture dans
WindowsApps, puis réactivez‑la immédiatement. - Échec sur
.UWPDesktop: si certaines applis desktop packagées continuent d’échouer, inspectez et, au besoin, réinstallez aussiMicrosoft.VCLibs.140.00.UWPDesktop. - Environnement multi‑utilisateur : les frameworks sont consommés par tous les comptes. Prévenez les utilisateurs d’une brève indisponibilité pendant la réparation.
FAQ
Q : Puis‑je supprimer le dossier corrompu au lieu de le renommer ?
R : Évitez la suppression directe. Le renommage est suffisant pour invalider la référence et facilite un retour arrière si nécessaire.
Q : La version affichée dans l’erreur ne correspond à aucune dans WindowsApps.
R : Filtrez par nom : dir "C:\Program Files\WindowsApps\Microsoft.VCLibs.140.00_*" /ad. Il se peut qu’une version plus récente soit installée ; si elle est saine, réinstallez l’app fautive depuis le Store pour la lier à la bonne révision.
Q : Que faire si aucune des méthodes ne fonctionne ?
R : Créez un point de restauration, puis tentez : réinitialiser les apps clés (Paramètres → Applications → Applications installées → app → Options avancées → Réinitialiser). En dernier recours, une réparation de Windows 11 par mise à niveau sur place conserve vos données et reconstruit les composants du Store.
Référence rapide des commandes utilisées
:: Lister le contenu (fichiers cachés) du package suspect
dir "C:\Program Files\WindowsApps\Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe" /a
:: Passer dans WindowsApps et renommer (contexte TrustedInstaller)
cd /d "C:\Program Files\WindowsApps"
ren Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe VCLibs.OLD
:: Installer depuis un package .Appx local (PowerShell)
Add-AppxPackage -Path .\Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe.Appx
:: Forcer la mise à jour depuis n'importe quelle version (si conflit)
Add-AppxPackage -Path .\Microsoft.VCLibs.140.00__x64__8wekyb3d8bbwe.Appx -ForceUpdateFromAnyVersion
:: Vérifier la version réellement installée
Get-AppxPackage -AllUsers -Name Microsoft.VCLibs.140.00 |
Select-Object PackageFullName, Version, Architecture
:: (Optionnel) Cache Store
wsreset.exe Prévention et hygiène système
- Ne coupez pas les mises à jour du Store (évitez de forcer l’arrêt ou de débrancher le PC pendant une mise à jour).
- Surveillez l’espace disque : gardez au moins 15–20 % libres sur
C:. - Programmez des sauvegardes (Historique des fichiers ou image système) avant des mises à jour massives.
- Vérifiez la santé du stockage régulièrement (
chkdsk /scan). Un SSD fatigué favorise les écritures tronquées. - Tenez à jour le firmware SSD/contrôleur NVMe et les pilotes chipset/stockage.
Checklist de résolution
- ⛳ Les applis Store plantent avec « Bad Image » → suspectez Microsoft.VCLibs.140.00.
- 🔎 Confirmez : DLL à 0 octet dans
WindowsApps. - 🛡️ Ouvrez un cmd en TrustedInstaller.
- ✏️ Renommez le dossier de la version corrompue.
- 🔁 Redémarrez et réinstallez le .Appx (ou via le Store).
- ✅ Vérifiez l’ouverture des applis et la taille des DLL.
Notes techniques complémentaires
- Code d’erreur 0xc0000020 : « Invalid Image Format » — binaire endommagé ou incomplet.
- Origine fréquente : update Store interrompue, antivirus verrouillant le dossier au mauvais moment, extinction brutale, manque d’espace.
- Les redistribuables VC++ « classiques » n’ont aucun effet sur les apps UWP : elles utilisent VCLibs géré par le Store.
- Alternative PowerShell :
Add-AppxPackage -Path .\Microsoft.VCLibs.140.00_14.0.33519.0_x64__8wekyb3d8bbwe.Appx. - Accès au dossier WindowsApps : nécessite TrustedInstaller. Évitez de bricoler les ACL.
- Prévention : ne pas interrompre les updates Store, maintenir des sauvegardes, vérifier la santé du disque.
En appliquant ce guide, vous réparez la dépendance Microsoft.VCLibs.140.00 au cœur du problème. La clé est de forcer Windows à oublier le package corrompu (renommage) puis de laisser le Store ou un .Appx propre remettre les DLL en place.