No puedo abrir WER\ReportArchive en Windows Server: cómo recuperar el dump de w3wp.exe en IIS (VM de Azure) y evitar el bloqueo de permisos

¿No puedes abrir C:\ProgramData\Microsoft\Windows\WER\ReportArchive para revisar un crash de w3wp.exe en una VM de Azure? Aquí tienes una guía práctica, segura y orientada a resultados para recuperar el dump, entender por qué sucede y evitar que te vuelva a bloquear.

Índice

Resumen de la situación

En algunos servidores Windows (típicamente Windows Server con IIS en una VM de Azure unida a dominio), el application pool de IIS (w3wp.exe) se detiene de forma intermitente. El Visor de eventos muestra un Application Error (suele ser Evento 1000) seguido de Windows Error Reporting (Evento 1001) y referencias a rutas como:

...\WER\Temp\...
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrashw3wp.exe...

Cuando intentas abrir ReportArchive, ni con cuenta Administrators ni tras “tomar posesión” con takeown/icacls logras acceso. El Explorador y la consola devuelven “Acceso denegado”.

Por qué no puedes entrar a ReportArchive

Windows Error Reporting (WER) conserva informes en ReportArchive y puede aplicar ACLs estrictas para proteger evidencias de crash: propietario SYSTEM/TrustedInstaller, ACE de Deny, herencia bloqueada y Mandatory Integrity Control alto. En entornos unidos a dominio, una GPO puede reimponer permisos justo al cerrar la ventana de propiedades, generando la sensación de que “tomaste posesión” pero sigues sin acceso. Es normal que el objeto muestre estado “heredado protegido” y DACL con entradas explícitas de deny.

Objetivo inmediato

Tu prioridad es recuperar el dump existente para analizar la causa del fallo, sin corromper evidencias ni dejar el servidor inseguro. Después, debes prevenir el problema configurando un destino de dumps accesible y persistente.

Recuperar el dump de forma segura

Opción recomendada: consola como SYSTEM y copia fuera

Trabajar como NT AUTHORITY\SYSTEM ignora bloqueos habituales a cuentas de usuario. Usa PsExec (de Sysinternals) o una tarea programada en contexto SYSTEM.

:: Abrir cmd como SYSTEM (requiere PsExec)
psexec -i -s cmd.exe

\:: Verificar identidad
whoami      :: debe mostrar nt authority\system

\:: Crear carpeta accesible y copiar el reporte
mkdir C:\Dumps\WERCopy
robocopy "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash\w3wp.exe\115d43fbe0cf3af3d68bdf7983532e99abeb89\3cffe2f7\b3fedcc0" "C:\Dumps\WERCopy" /E /R:1 /W:1 </code></pre>

<p>Abre el <code>.dmp</code> desde <code>C:\Dumps\WERCopy</code> con WinDbg, Visual Studio o DebugDiag. Esta técnica evita tocar ACLs en producción.</p>

<h3>Variante sin PsExec: copia con privilegio de copia de seguridad</h3>
<p>Si tu sesión elevada dispone de <em>SeBackupPrivilege/SeRestorePrivilege</em>, puedes copiar ignorando DACL con <em>Backup mode</em>:</p>
<pre><code>robocopy "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso" "C:\Dumps\WERCopy" /E /R:1 /W:1 /COPYALL /B
</code></pre>
<p>El modificador <code>/B</code> usa el modo copia de seguridad. Úsalo solo para extraer el material forense, no para reestructurar permisos.</p>

<h3>Atajo gráfico: Monitor de confiabilidad</h3>
<p>A veces, <em>Confiabilidad</em> permite saltar al informe aunque el Explorador tradicional falle:</p>
<pre><code>Win + R  →  perfmon /rel
</code></pre>
<p>Abre el evento del día del crash (p. ej., 16‑nov‑2024), entra a <em>Ver detalles técnicos</em> y usa <em>Abrir ubicación del archivo</em>. Si las ACL lo permiten, copia el contenido a una ruta propia.</p>

<h2>Si necesitas ajustar permisos de forma controlada</h2>
<p>Hazlo solo si no conseguiste copiar como SYSTEM. <strong>Primero</strong>, captura un snapshot de la VM o del disco.</p>
<pre><code>:: Inspeccionar ACL
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso"

\:: (Opción A) Rehabilitar herencia (si fue bloqueada)
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso" /inheritance\:e

\:: (Opción B) Deshabilitar herencia preservando ACL explícitas (útil para editar luego)
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso" /inheritance\:d

\:: Quitar ACE de Deny concretos si aparecen
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso" /remove\:d "Cuenta\o\Grupo"

\:: Conceder control total a Administrators de forma recursiva
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso" /grant Administrators:(OI)(CI)F /T

\:: Asegurar propiedad y asignarla al grupo Administrators
takeown /f "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso" /a /r /d y
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso" /setowner Administrators /T </code></pre>

<p>Si tras aplicar vuelve el bloqueo, es probable que una <strong>GPO</strong> restablezca permisos. En ese caso, no insistas a ciegas: coordina una excepción temporal con tu equipo de TI.</p>

<h2>Comprobaciones adicionales útiles</h2>
<ul>
  <li><strong>¿Cifrado EFS?</strong> Comprueba con:
    <pre><code>cipher /c "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\...\Report.wer"</code></pre>
    Si está cifrado por otra identidad, copia como SYSTEM o recupera la clave EFS del perfil.
  </li>
  <li><strong>Integridad obligatoria (MIC):</strong> Algunas carpetas muestran etiqueta de integridad Alta. Puedes consultarla con <code>icacls</code>. Evita bajarla en producción; extrae el archivo como SYSTEM.
  </li>
</ul>

<h2>Diagnóstico de GPO que reimpone permisos</h2>
<p>Identifica políticas que afectan a <code>WER</code> o al árbol de <code>C:\ProgramData</code>:</p>
<pre><code>gpresult /scope computer /v
</code></pre>
<p>Revisa <em>Security Settings → File System</em>. Si hay entradas para <code>C:\ProgramData\Microsoft\Windows\WER</code> o subcarpetas, gestiona una excepción que conceda <em>Read</em> al grupo <em>Administrators</em> o, mejor aún, redirige los próximos <em>dumps</em> a una ruta propia.</p>

<h2>Prevención: configurar dumps accesibles</h2>
<h3>Redirigir WER LocalDumps de w3wp.exe</h3>
<p>Configura una ruta controlada y persistente para los próximos crashes. <strong>En Azure, evita usar el disco temporal</strong> (suele ser <code>D:</code> en muchos tamaños), porque se borra en reinicios. Prefiere un disco de datos persistente (p. ej., <code>E:</code> o la unidad que uses para datos).</p>
<pre><code>reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe" /v DumpFolder /t REGEXPANDSZ /d "E:\CrashDumps" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe" /v DumpType   /t REG_DWORD /d 2 /f   :: 2 = Full dump
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe" /v DumpCount  /t REG_DWORD /d 10 /f

mkdir E:\CrashDumps
icacls "E:\CrashDumps" /grant Administrators:(OI)(CI)F /T </code></pre>

<p>WER respetará esta configuración en el próximo crash de <code>w3wp.exe</code>, sin reiniciar el servidor.</p>

<h3>Valores de LocalDumps</h3>
<table>
  <thead>
    <tr><th>Clave</th><th>Valor</th><th>Descripción</th><th>Recomendación</th></tr>
  </thead>
  <tbody>
    <tr><td>DumpFolder</td><td>REGEXPANDSZ</td><td>Ruta destino de los <em>dumps</em></td><td>Usa disco persistente con espacio suficiente</td></tr>
    <tr><td>DumpType</td><td>REG_DWORD</td><td>1 = Mini, 2 = Completo</td><td>2 para análisis profundo en IIS</td></tr>
    <tr><td>DumpCount</td><td>REG_DWORD</td><td>Máximo de archivos retenidos</td><td>10 para evitar rotación prematura</td></tr>
  </tbody>
</table>

<h3>Alternativas probadas para capturar el siguiente crash</h3>
<ul>
  <li><strong>DebugDiag</strong>: crea una <em>Crash Rule</em> para <code>w3wp.exe</code> con destino <code>E:\CrashDumps</code>. Ideal para .NET y extensiones ISAPI, con análisis automático.</li>
  <li><strong>ProcDump</strong> (ligero y muy flexible):
    <pre><code>:: Espera a w3wp.exe y genera dump completo en la próxima excepción no controlada
procdump -ma -e -w w3wp.exe E:\CrashDumps
</code></pre>
    <p>Para escenarios agresivos puedes usar <code>-e 1</code> (primeras oportunidades) con filtros, pero puede producir muchos <em>dumps</em>.</p>
  </li>
</ul>

<h2>Abrir y analizar el dump</h2>
<p>Con <strong>WinDbg</strong> (o WinDbgX) o <strong>DebugDiag</strong> puedes obtener la causa raíz con rapidez.</p>
<ol>
  <li><strong>Configura símbolos</strong>: define un <em>symbol path</em> local (p. ej., <code>C:\Symbols</code>) y el servidor público de símbolos de Microsoft. Ejemplo de formato: <code>srvC:\Symbols&lt;servidor de símbolos de Microsoft&gt;</code>.</li>
  <li><strong>Carga el dump</strong>: <em>File → Open Crash Dump</em>.</li>
  <li><strong>Ejecuta análisis básico</strong>:
    <pre><code>!analyze -v
</code></pre>
  </li>
  <li><strong>Si es .NET</strong>: carga SOS y revisa pila y excepciones:
    <pre><code>.loadby sos clr
!clrstack
!threads
!pe -nested

Si es nativo: revisa call stack, módulos de terceros y referencias a heap corruption.

En IIS, causas comunes incluyen excepciones no controladas en la app, módulos nativos defectuosos, OutOfMemory, fugas de handles o violaciones de acceso.

Consideraciones de IIS que afectan la recogida de evidencias

Rapid-Fail Protection puede deshabilitar el application pool tras múltiples caídas en pocos minutos, impidiendo reproducciones.

:: Ejemplo con appcmd (ajusta el nombre del pool)
%windir%\system32\inetsrv\appcmd set apppool "NombreDelPool" /failure.rapidFailProtection:true /failure.rapidFailProtectionMaxCrashes:10 /failure.rapidFailProtectionInterval:00:05:00

Sube temporalmente el umbral mientras capturas el siguiente dump, siempre coordinado con el equipo de operaciones para evitar impacto.

Checklist rápido y accionable

Intenta copiar como SYSTEM desde ReportArchive a una carpeta tuya (robocopy con /E o /B).
Si hay bloqueo recurrente, identifica GPO que toca WER y coordina excepción.
Configura LocalDumps de w3wp.exe a un disco persistente y accesible (no el temporal de Azure).
Habilita DebugDiag o ProcDump para el próximo crash.
Analiza el dump con WinDbg/DebugDiag usando símbolos y comandos básicos (!analyze -v, !clrstack).
Revisa Rapid-Fail Protection para evitar que el pool se deshabilite antes de capturar evidencia.

Preguntas frecuentes

¿Por qué “tomar posesión” no funciona?
Porque la carpeta puede estar protegida con propietario SYSTEM/TrustedInstaller, herencia bloqueada, ACE de Deny y nivel de integridad alto. Además, una GPO puede reponer estos ajustes al instante.

¿Es seguro quitar ACE de Deny?
En producción, no. La práctica recomendada es no relajar la seguridad del sistema; mejor copia el contenido con una sesión SYSTEM y trabaja sobre una copia fuera de ProgramData.

¿Dónde pongo los dumps en Azure?
En un disco de datos persistente (por ejemplo, E:). Evita el disco temporal (frecuente como D:), ya que se borra en reinicios o mantenimiento.

¿Necesito reiniciar para que LocalDumps funcione?
No; WER aplicará la configuración en el próximo crash del proceso objetivo. Si quieres forzar carga, recicla el application pool tras guardar la configuración, aunque no es estrictamente necesario.

¿ProcDump o DebugDiag?
ProcDump es ligero y scriptable; excelente para un primer disparo. DebugDiag aporta reglas ricas y análisis de patrones frecuentes en IIS y .NET.

¿Qué eventos me orientan en el Visor?
Normalmente verás Application Error 1000 (módulo con fallo, offset, versión de w3wp.exe o de la DLL) seguido de Windows Error Reporting 1001 (ruta al reporte y bucket del crash).

Guía detallada paso a paso

Proteger el entorno: crea un snapshot de la VM o del disco y verifica espacio libre (>10–20 GB si vas a capturar full dumps).
Extraer la evidencia: usa psexec -i -s cmd.exe → robocopy hacia C:\Dumps\WERCopy o E:\CrashDumps\Incoming.
Auditar la GPO: gpresult /scope computer /v y revisa Security Settings → File System.
Persistencia: configura LocalDumps de w3wp.exe hacia un volumen de datos persistente. Da permisos explícitos a Administrators.
Captura siguiente crash: con ProcDump o DebugDiag. Ajusta Rapid-Fail si el pool cae demasiado rápido.
Análisis: abre el dump con WinDbg/DebugDiag, carga símbolos y ejecuta !analyze -v. Si es .NET, usa .loadby sos clr y comandos SOS básicos.
Corrección: aplica el fix (actualiza dependencias, corrige excepciones no controladas, revisa módulos nativos, sube límites de memoria o reciclos, etc.).

Tabla comparativa de métodos para recuperar el dump

Método	Ventajas	Riesgos	Cuándo usar
Consola SYSTEM + robocopy	Rápido, respeta seguridad, no altera ACL	Requiere PsExec o tarea SYSTEM	Primera opción en producción
Robocopy /B	Usa privilegio de copia de seguridad	Necesita privilegios; no reconfigura acceso	Cuando no tienes PsExec a mano
Ajustar ACL con icacls/takeown	Acceso local permanente	Puede chocar con GPO y debilitar seguridad	Solo si coordinarás con TI/GPO
Confiabilidad → Abrir ubicación	Atajo gráfico	No siempre salta barrera de ACL	Cuando ya estás en sesión de consola

Buenas prácticas y precauciones

No elimines ACE de Deny sin entender su motivo; preferible copiar la evidencia con SYSTEM.
No almacenes full dumps en el disco temporal de Azure; podrías perderlos al reiniciar.
Controla el tamaño de los dumps (completos pueden ocupar varios GB). Ajusta DumpCount y vigila el espacio.
Firma y versiona los modules de terceros en IIS para diagnosticar colisiones nativas.
Revisa reciclados de IIS: a veces interpretamos un reciclado como crash. Confirma con eventos y worker process history.

Ejemplos de comandos listos para copiar

Copiar como SYSTEM

psexec -i -s cmd.exe
whoami
mkdir C:\Dumps\WERCopy
robocopy "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrashw3wp.exe115d43fbe0cf3af3d68bdf7983532e99abeb893cffe2f7b3fedcc0" "C:\Dumps\WERCopy" /E /R:1 /W:1

Revisar y ajustar ACL solo si es imprescindible

icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso"
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso" /inheritance:e
:: o bien
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso" /inheritance:d
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso" /remove:d "CuentaoGrupo"
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso" /grant Administrators:(OI)(CI)F /T
takeown /f "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso" /a /r /d y
icacls "C:\ProgramData\Microsoft\Windows\WER\ReportArchive\CarpetaDelCaso" /setowner Administrators /T

LocalDumps hacia disco persistente

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe" /v DumpFolder /t REGEXPANDSZ /d "E:\CrashDumps" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe" /v DumpType   /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\w3wp.exe" /v DumpCount  /t REG_DWORD /d 10 /f
mkdir E:\CrashDumps
icacls "E:\CrashDumps" /grant Administrators:(OI)(CI)F /T

ProcDump para el próximo crash

procdump -ma -e -w w3wp.exe E:\CrashDumps

Comprobación de GPO

gpresult /scope computer /v

Resumen accionable final

Recupera el dump con una consola SYSTEM y cópialo a C:\Dumps\WERCopy (o a un volumen de datos persistente).
Si una GPO restaura permisos, coordina excepción o, mejor, redirige los próximos dumps a E:\CrashDumps con LocalDumps, DebugDiag o ProcDump.
Analiza el dump con WinDbg/DebugDiag, corrige la causa raíz y ajusta la configuración de IIS (Rapid-Fail Protection) para no perder reproducciones.

Con esta estrategia tendrás una evidencia forense inmediata sin degradar la seguridad del sistema, y un flujo estable para capturar y diagnosticar los próximos incidentes de w3wp.exe en IIS sobre Windows Server en Azure.