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.
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
SYSTEMetTrustedInstallerdisposent 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/icaclsaffichent « 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
SYSTEMpour 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
.dmpcomme sensibles. Excluez le répertoireD:\Dumpssi 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 :
.symfixconfigure un chemin de symboles par défaut. Ajoutez des symboles privés de vos applications si nécessaire. - Modules :
lmliste 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 <adresse> ; 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
.dmpavec 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 yicacls "<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.