Accéder aux dumps WER dans C:\ProgramData\Microsoft\Windows\WER\ReportArchive pour diagnostiquer w3wp.exe sur une VM Azure

Sur une VM Azure, un pool d’applications IIS (w3wp.exe) plante et WER dépose des dumps inaccessibles dans C:\ProgramData\Microsoft\Windows\WER\ReportArchive. Ce guide explique comment reprendre l’accès, extraire les .dmp, rediriger les prochains dumps et les analyser proprement.

Sommaire

Problématique

Vous observez des arrêts intermittents de w3wp.exe (IIS) avec des événements Application Error et Windows Error Reporting (WER) dans l’Observateur d’événements. Les messages confirment la création d’un fichier de vidage mémoire (dump) et de métadonnées, mais les artefacts sont stockés dans un sous-dossier de ReportArchive auquel l’administrateur local n’a pas accès. Malgré une prise de possession apparente et l’octroi du Contrôle total, l’accès reste refusé. En environnement joint à un domaine (Azure AD DS ou AD DS on‑prem), des stratégies peuvent réappliquer des ACL restrictives ou empêcher la substitution du propriétaire, d’où la persistance du blocage.

Pourquoi l’accès est restreint dans WER\ReportArchive

ACL très restrictives par défaut : WER protège ses archives. Les identités SYSTEM et TrustedInstaller disposent du contrôle complet. Les administrateurs locaux peuvent être exclus des DACL héritées lorsque WER crée des sous‑dossiers d’incident.
Politiques et durcissements : une GPO peut forcer la réécriture du propriétaire (Overwrite owner), désactiver l’héritage, ou imposer une DACL modèle sur ProgramData. Des solutions de durcissement (FSRM, solutions EDR) peuvent aussi restaurer des ACL ou bloquer l’accès direct.
Contexte de sécurité : même si takeown/icacls affichent « Réussi », une stratégie de domaine ou un service « protecteur » peut réappliquer des droits au prochain traitement WER, rendant l’accès à nouveau impossible.

Structure typique de ReportArchive

Comprendre ce que vous cherchez aide à valider que vous avez bien récupéré tous les artefacts utiles.

Élément	Exemple	Contenu / utilité
Sous‑dossier d’incident	`AppCrash_w3wp.exe_123456789abcdef0123456789abcdef01234567_00000000_0b4c02e7`	Un dossier par événement de crash ou hang.
Dump complet	`memory.dmp` ou `FullDump.dmp`	Capture mémoire exhaustive du processus. Poids important, analyse riche.
Mini‑dump	`minidump.dmp`	Pile d’appels et contexte minimal. Suffisant pour la plupart des crashs simples.
Métadonnées WER	`Report.wer`, `WERInternalMetadata.xml`	Détails sur le module fautif, l’exception, les versions, les horodatages.
Fichiers annexes	`triage.txt`, journaux .txt	Informations d’environnement, extractions de registres, etc.

Feuille de route rapide

Avant de tout modifier, suivez ce chemin court pour maximiser vos chances de récupération propre et répétable :

Vérifiez les stratégies effectivement appliquées (gpresult, rsop.msc), et si possible, travaillez avec un compte Administrateur local hors domaine.
Tentez la prise de possession et l’octroi des droits via l’interface graphique puis via la ligne de commande.
Si l’accès échoue, ouvrez un shell en SYSTEM pour copier les fichiers vers un répertoire accessible.
Redirigez les prochains dumps hors de WER (LocalDumps, ProcDump ou politique WER d’entreprise).
Analysez les fichiers .dmp avec WinDbg pour identifier la cause première.

Procédure graphique pour reprendre la main

Cette méthode convient si l’environnement n’impose pas une restauration automatique des ACL.

Clic droit sur C:\ProgramData\Microsoft\Windows\WER\ReportArchive → Propriétés → onglet Sécurité → Avancé.
Modifier le propriétaire → choisir votre compte ou le groupe Administrators → cocher Remplacer le propriétaire des sous‑conteneurs et objets.
Appliquer, fermer la boîte de dialogue, la rouvrir.
Dans Autorisations, ajouter votre compte/groupe et cocher Contrôle total. Valider sur l’ensemble des sous‑dossiers.

Astuce : sur certains serveurs, l’héritage est désactivé à la racine du dossier d’incident. Activez l’héritage ou propagez explicitement l’entrée Full control sur les éléments existants et futurs.

Procédure en ligne de commande

Exécutez une Invite de commandes ou PowerShell en tant qu’administrateur.

REM Prendre possession récursive
takeown /f "C:\ProgramData\Microsoft\Windows\WER\ReportArchive" /r /d y

REM Octroyer le contrôle total aux Administrators (et à votre compte si besoin)
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive" /grant Administrators:F /t

REM Facultatif : activer l'héritage si désactivé
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive" /inheritance:e

REM Vérifier les ACL effectives
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive"

Limite courante : si une GPO réapplique des ACL, le succès rapporté par icacls est temporaire. Dès qu’un service WER régénère ou « retouche » le dossier, vos autorisations sautent à nouveau.

Quand les droits semblent appliqués mais l’accès reste refusé

Dans un environnement joint à un domaine ou durci, utilisez ces vérifications et contournements :

Objectif	Outil	Commande / Action	Ce qu’il faut observer
Inspecter les GPO appliquées	Invite admin	`gpresult /h C:\Temp\gp.html`	Politiques WER, restrictions sur ProgramData, règles d’héritage/possession.
RSOP ciblé	`rsop.msc`	Exécuter, naviguer vers Composants Windows > WER	Paramètres Corporate Windows Error Reporting, désactivation WER UI, répertoires.
Isoler l’influence du domaine	Compte local	Connexion avec un administrateur local non géré	Si l’accès fonctionne, une GPO domaine est en cause.
Tester un autre admin	Compte Builtin Administrator	Connexion et test d’accès	Écarte un profil corrompu ou des restrictions par groupe.

Copier les dumps avec un shell en SYSTEM

Le compte SYSTEM dispose d’un accès natif aux dossiers WER. Ouvrez un shell SYSTEM puis copiez vers un emplacement accessible.

REM Ouvrir un CMD interactif en SYSTEM (outil Sysinternals requis sur le serveur)
psexec -i -s cmd

REM Depuis ce shell SYSTEM, copiez les artefacts vers un dossier libre
mkdir D:\Dumps
xcopy /E /I /H "C:\ProgramData\Microsoft\Windows\WER\ReportArchive" "D:\Dumps\WERBackup"

REM Ou avec PowerShell
powershell -NoLogo -NoProfile -Command ^
"Copy-Item 'C:\ProgramData\Microsoft\Windows\WER\ReportArchive*' 'D:\Dumps\WERBackup' -Recurse -Force"

Conseil : si un outil de sécurité surveille ProgramData, copiez d’abord les fichiers vers un disque de données (par ex. D:\) puis isolez‑les pour l’analyse.

Rediriger la capture des prochains crashs hors de WER

Évitez à l’avenir ReportArchive en configurant une destination maîtrisée.

LocalDumps

Créez la clé HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps pour une configuration globale, ou ajoutez un sous‑dossier w3wp.exe pour cibler uniquement IIS. Paramètres utiles :

Nom	Type	Valeur recommandée	Effet
`DumpFolder`	REG_EXPAND_SZ	`D:\Dumps`	Chemin d’écriture des dumps.
`DumpType`	DWORD	`2`	`1`=mini, `2`=complet.
`DumpCount`	DWORD	`10`	Nombre maximum de dumps conservés.
`CustomDumpFlags`	DWORD	optionnel	Affinage des mini‑dumps (piles, handles, etc.).

Exemples de configuration :

REM Global (tous les processus)
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpFolder /t REG_EXPAND_SZ /d "D:\Dumps" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpType   /t REG_DWORD     /d 2 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpCount  /t REG_DWORD     /d 10 /f

REM Spécifique à w3wp.exe
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe" /v DumpFolder /t REG_EXPAND_SZ /d "D:\Dumps" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe" /v DumpType   /t REG_DWORD     /d 2 /f

Redémarrez le service IIS ou le serveur pour garantir la prise en compte, puis vérifiez la création de nouveaux dumps dans D:\Dumps.

ProcDump

ProcDump (Sysinternals) permet de capturer un dump au moment exact du crash, en dehors du pipeline WER.

REM Surveille w3wp.exe et génère un dump complet à la première exception non gérée
procdump -e -w w3wp.exe -ma D:\Dumps

REM Installer ProcDump comme post‑mortem debugger (tous les processus)
procdump -ma -i D:\Dumps

Bonnes pratiques : utilisez -ma pour un crash complexe, sinon préférez un mini‑dump (-mp ou DumpType=1) pour limiter l’empreinte disque. Vérifiez l’espace disponible avant d’activer un dump complet sur un serveur de production.

Redirection WER d’entreprise

La politique Corporate Windows Error Reporting permet de définir un répertoire local ou réseau pour l’archivage des rapports. Si une GPO l’impose déjà, coordonnez‑vous avec l’équipe GPO pour pointer vers un partage sécurisé auquel l’équipe de support a accès.

Contexte domaine et Azure

Join de domaine : si une GPO réinitialise l’owner ou l’héritage, travaillez avec un compte local hors domaine, ou déplacez temporairement la VM hors du domaine pour récupérer les artefacts, en respectant les politiques de sécurité de l’entreprise.
Audit et traçabilité : si la conformité l’exige, activez l’audit d’accès aux objets pour tracer les Access Denied et les réécritures d’ACL.
EDR/AV : certains outils classent les .dmp comme sensibles. Excluez le répertoire D:\Dumps si nécessaire pendant la collecte, puis réactivez les protections.

Nettoyage, réversibilité et sécurité

Restauration des ACL : après récupération, revenez à un état sécurisé.

REM Réactiver l’héritage et réinitialiser les ACL à l’état par défaut NTFS (à manier avec précaution)
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive" /inheritance:e
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive" /reset /t

Quota et nettoyage : fixez DumpCount et purge automatique pour éviter de saturer le disque. Archivez hors serveur les dumps utiles et supprimez‑les localement.
Confidentialité : un dump peut contenir des secrets (chaînes de connexion, tokens). Manipulez‑le selon les règles de l’entreprise et chiffrez les transferts.

Analyse des dumps w3wp avec WinDbg

Après extraction des fichiers, l’analyse doit être reproductible et documentée.

Ouverture et symboles

REM Lancez WinDbg Preview, puis dans la commande :
.symfix; .reload
!analyze -v

Symboles : .symfix configure un chemin de symboles par défaut. Ajoutez des symboles privés de vos applications si nécessaire.
Modules : lm liste les DLL chargées. Repérez les modules tiers IIS (ISAPI, filtres) susceptibles d’être fautifs.

Triage rapide

k                 ; pile d’appels
kv                ; pile avec paramètres
r                 ; registres
!peb              ; environnement du processus
!teb              ; thread environment block sur le thread courant

Clés de lecture :

Exception code : 0xC0000005 (Access Violation), 0xC0000409 (Stack Buffer Overrun), etc.
Module fautif : DLL tiers d’un module IIS, filtre http, ou bibliothèque d’un agent.
Thread fautif : regardez la pile du thread qui a levé l’exception et celles des threads gérant le GC/CLR si .NET est en jeu.

Spécificités .NET et ASP.NET

Pour une application ASP.NET classique (hébergée dans le CLR de Windows), chargez sos.dll :

.loadby sos clr       ; .NET Framework
!clrstack             ; pile managée
!pe                   ; dernière exception
!threads              ; état des threads managés
!dumpheap -stat       ; top des types alloués
!gcroot &lt;adresse&gt;     ; détecter des rétentions mémoire

Pour ASP.NET Core en mode in‑process sous IIS, la pile inclut aspnetcorev2_inprocess.dll ; les mêmes commandes aident à identifier une fuite ou une exception non gérée côté application.

Scénarios types et pistes de remédiation

Symptôme	Indices dans le dump	Remèdes
Access Violation	Pile dans une DLL tierce native	Mettre à jour/retirer le module, activer Rapid‑Fail Protection, isoler dans un pool dédié.
OutOfMemory	Segments managés volumineux, `!dumpheap` montre de gros objets	Réparer la fuite, activer recycling par seuil mémoire, passer en 64 bits si encore en 32 bits.
Stack Overflow	Répétition récursive dans la pile	Corriger la récursion, ajouter de la validation d’entrée.
Deadlock/Hang	Multiples threads bloqués sur les mêmes verrous	Capturer un dump quand « figé » (`procdump -h`), revoir la contention et les verrous.

Questions fréquentes

Pourquoi takeown/icacls « réussissent » mais l’ouverture échoue ?
Parce qu’une GPO ou un agent réécrit les ACL ensuite, ou parce que l’héritage est désactivé dans les sous‑dossiers. Le shell SYSTEM permet de contourner temporairement et de copier les fichiers.

Faut‑il un dump complet pour chaque crash ?
Non. Commencez par un mini‑dump. Passez au dump complet si la pile n’est pas suffisante (optimisation, code natif profond, corruption mémoire).

Peut‑on analyser sur le serveur ?
Évitez en production. Copiez les dumps sur une station d’analyse équipée de WinDbg et des symboles adéquats.

Synthèse opérationnelle

Essayez la prise de possession et icacls. Si l’accès reste refusé, suspectez une GPO ou un durcissement.
Capturez les prochains dumps hors de ReportArchive : LocalDumps ou ProcDump.
Utilisez un shell SYSTEM ou un compte local hors domaine pour copier les artefacts existants vers un dossier dédié.
Analysez les .dmp avec WinDbg (!analyze -v) et complétez avec les extensions .NET si nécessaire.
Restaurez les ACL et nettoyez après investigation pour revenir à un état conforme et sécurisé.

Tableau récapitulatif des solutions

Objectif	Méthode	Commandes / Actions clés	Quand l’utiliser	Points d’attention
Prendre possession du dossier	Interface graphique	Propriétés → Sécurité → Avancé → Modifier le propriétaire, cocher Remplacer le propriétaire…	Premier essai sur un serveur non durci	Peut être annulé par une GPO ou un agent de sécurité
Attribuer Contrôle total	Interface graphique	Ajouter votre compte/groupe et activer Full control	Après prise de possession	Vérifier l’héritage et la propagation
Forcer via CLI	Invite admin	`takeown /f "<Chemin>" /r /d y` `icacls "<Chemin>" /grant Administrators:F /t`	Serveurs scriptables ou sans GUI	Peut être temporaire si une GPO réécrit les ACL
Vérifier les stratégies	GPO locale/centrale	`gpedit.msc`, contrôle GPO central	Avant toute modification durable	Documenter les changements et obtenir l’accord sécurité
Tester avec autre admin	Compte différent	Connexion sous un autre admin ou Builtin Administrator	Doute sur les droits du compte	Écarte un problème de profil
Isoler l’influence du domaine	Compte local / hors domaine	Travailler localement, voire retirer temporairement du domaine	Blocage persistant malgré `icacls`	Respecter les processus de changement et d’audit
Copier en SYSTEM	Shell `SYSTEM`	`psexec -i -s cmd`, copie vers `D:\Dumps`	Accès immédiat requis	Nécessite les outils Sysinternals sur le serveur
Rediriger les futurs dumps	LocalDumps	Clés de registre `LocalDumps`	Solution durable, sans dépendre de WER	Dimensionner l’espace disque et le nombre de dumps
Capturer au crash	ProcDump	`procdump -e -w w3wp.exe -ma D:\Dumps`	Reproduction dirigée, collecte fine	Contrôler l’impact et arrêter après collecte

En bref : si l’accès à ReportArchive vous résiste, ne perdez pas de temps à lutter contre les politiques — récupérez ce que vous pouvez en SYSTEM, puis déplacez durablement la capture de crash vers un répertoire maîtrisé (LocalDumps/ProcDump). Votre boucle de diagnostic sera plus rapide, plus sûre et reproductible.