Introducción a la recolección de volcados de memoria de fallos en Windows - WER/ProcDump/WinDbg

Cuando una aplicación Windows empieza a fallar «solo de vez en cuando», hay bastantes situaciones en las que los registros por sí solos no bastan para seguir el rastro.

Los casos especialmente complicados son estos:

• Solo ocurre en el entorno del cliente
• Se tiene el mensaje de excepción, pero falta el contexto de quién lo llamó
• Interviene no solo el lado managed de C# / .NET, sino también COM, P/Invoke, DLL nativas y SDK de terceros
• Solo falla después de una ejecución prolongada

En estos casos, el volcado de memoria de fallo (crash dump) es lo que realmente ayuda. Si se guarda en un archivo el estado del proceso en el momento del fallo, después se puede leer el código de excepción, la pila del subproceso que falló, los módulos que estaban cargados y una parte o la totalidad de la memoria.

En Windows resulta claro pensar el orden así: primero LocalDumps de WER, si hace falta Sysinternals ProcDump, y cuando se quiera un control aún mayor, MiniDumpWriteDump. Este artículo organiza el primer paso de la recolección de volcados de memoria de fallos, partiendo de aplicaciones de escritorio Windows, aplicaciones residentes, servicios de Windows y herramientas de integración con dispositivos.

Términos que aparecen repetidamente en este artículo

Antes de continuar, conviene fijarlos brevemente. Si quedan ambiguos, los capítulos siguientes pierden claridad.

1. Conclusión por adelantado

Antes que nada, se enumeran solo los puntos que conviene tener claros desde el principio.

• Lo más seguro es configurar WER LocalDumps por aplicación como primer paso. Permite dejar el volcado localmente tras un fallo, sin necesidad de herramientas adicionales.
• Para investigaciones de campo con baja tasa de reproducción, o cuando se quiere observar también first chance exceptions o hangs, se usa ProcDump.
• Es razonable dejar la recolección propia (custom) para el final. Basta con considerar MiniDumpWriteDump cuando de verdad haga falta.
• Tan importante como el volcado es conservar el PDB y los binarios distribuidos. Aunque se tenga el volcado, si faltan los símbolos, la cantidad de información legible se reduce bastante.
• El volcado completo es potente, pero también lo son su tamaño y el riesgo de que se filtre información confidencial. Hay que decidir de antemano el lugar de almacenamiento, el número de copias, los permisos de acceso y el procedimiento de compartición.

La configuración recomendada para la etapa inicial suele reducirse, más o menos, a lo siguiente.

En resumen: primero WER, después ProcDump y, al final, la recolección propia. Empezar en el orden inverso suele hacer que el diseño se vuelva pesado.

2. Qué se puede saber a partir de un volcado de memoria de fallo

Un volcado de memoria de fallo es «una instantánea de ese momento». Se parece más a una foto fija de la escena de un accidente que a una cámara de seguridad.

Por eso, es bastante fácil obtener este tipo de información:

• Con qué código de excepción falló
• Qué subproceso (thread) falló
• La pila de llamadas en ese momento
• Los módulos que estaban cargados
• Según la cantidad de memoria incluida, el estado del montículo (heap) y el contenido de los objetos

Por otro lado, hay información que el volcado por sí solo suele no cubrir:

• La línea temporal que llevó hasta ese punto
• Tendencias de aumento desde varias horas antes
• El estado externo de las comunicaciones o de los dispositivos
• La entrada inmediatamente anterior o el contexto de negocio

Por eso, en la práctica lo básico es no intentar resolverlo solo con el volcado, sino combinarlo con registros y heartbeats.

3. Panorama general de los métodos de recolección

Para la recolección de volcados en aplicaciones Windows, los cuatro métodos que conviene conocer en la etapa inicial son estos.

Para quien empieza, lo más importante es decidir, antes que «con qué herramienta capturar», «en qué condiciones», «hacia dónde» y «con qué tamaño» se va a capturar.

4. La primera recomendación es WER LocalDumps

4.1 Los valores del registro que hay que revisar primero

Windows Error Reporting (WER) incluye LocalDumps, que guarda localmente un volcado en modo usuario después de un fallo. Como no hace falta distribuir ninguna herramienta adicional, resulta bastante manejable como primer paso.

La clave básica es esta.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps

Aquí también se puede colocar la configuración global, pero en la práctica es más manejable inclinarse por una subclave por aplicación.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe

Hay tres valores que conviene revisar primero.

4.2 Ejemplo de configuración por aplicación

Por ejemplo, si para MyApp.exe se quieren conservar hasta 10 volcados completos en C:\CrashDumps\MyApp, se puede configurar así como primer paso.

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpFolder /t REG_EXPAND_SZ /d "C:\CrashDumps\MyApp" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpCount /t REG_DWORD /d 10 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpType /t REG_DWORD /d 2 /f

Este ejemplo tiene cuatro puntos clave.

• Se limita a MyApp.exe en lugar de aplicarlo de forma global
• Se separa el destino en una carpeta dedicada
• Se usa el volcado completo como punto de partida
• Se limita el número de copias conservadas a 10

4.3 Comprobar que se ha capturado correctamente

Una vez aplicada la configuración, es más seguro capturar el volcado al menos una vez en el entorno de verificación, antes de esperar a que ocurra de forma natural en producción.

Hay cuatro puntos que conviene comprobar.

1. Si aparece el .dmp en la carpeta prevista
2. Si el tamaño se ajusta a lo previsto en la operación
3. Si se puede abrir con WinDbg
4. Si el fallo se ve en el registro Application del Visor de eventos (Event Viewer)

4.4 Código mínimo para provocar un fallo intencionalmente

Aunque se diga «hay que capturarlo», esperar a que ocurra un fallo real no sirve como verificación. Para eso, conviene preparar de antemano un pequeño EXE que simplemente falle a propósito, lo cual resulta más rápido.

En .NET basta con una aplicación de consola que simplemente lance una excepción no controlada. Como una excepción managed no controlada en .NET termina el proceso, queda directamente sujeta a WER.

// CrashTest.csproj: <TargetFramework>net8.0</TargetFramework>
using System;
using System.Threading;

internal static class Program
{
    private static void Main()
    {
        Console.WriteLine($"PID={Environment.ProcessId} / Se producirá el fallo en 3 segundos.");
        Thread.Sleep(3000);

        throw new InvalidOperationException("intentional crash for dump collection test");
    }
}

Si se quiere comprobar el lado nativo, es más directo provocar una violación de acceso (0xC0000005). Se añade volatile para que la optimización no la elimine.

// crash_test.cpp / C++17 / MSVC
int main()
{
    volatile int* p = nullptr;
    *p = 1;  // Aquí se produce STATUS_ACCESS_VIOLATION
    return 0;
}

Aquí hay un punto que se suele pasar por alto. El nombre de la subclave de LocalDumps debe coincidir con el nombre de archivo del EXE que se está haciendo fallar. Si solo se crea la clave de MyApp.exe y se hace fallar CrashTest.exe, por supuesto que no aparecerá ningún volcado. Durante la verificación, hay que crear temporalmente la clave de CrashTest.exe, o bien probar con la configuración global.

NotMyFault, de Sysinternals, también suele mencionarse como herramienta para «fallar a propósito», pero está pensada para hacer fallar o colgar el propio sistema Windows y generar el volcado de una pantalla azul, y además requiere permisos de administrador. Para verificar LocalDumps en aplicaciones en modo usuario, es más seguro y fiable usar un pequeño EXE propio como el mostrado arriba.

5. Situaciones en las que usar ProcDump

En muchos casos basta con WER, pero también hay situaciones en las que ProcDump resulta útil.

• Se quiere evitar dejar una configuración permanente en el registro
• Se quiere vigilar solo un proceso que ya está en ejecución
• Se quiere vigilar solo a partir del próximo inicio
• Se quiere observar las first chance exceptions
• Se quiere capturar un hang
• Se quiere capturar según contadores de rendimiento o de forma condicional

5.1 Opciones de uso frecuente

Si nos limitamos a las que se usan con frecuencia en la etapa inicial, con recordar lo siguiente ya se puede hacer bastante con ProcDump.

5.2 Ejemplos de comandos representativos

Volcado completo ante una excepción no controlada, de un proceso ya en ejecución

procdump -accepteula -ma -e 1234 C:\CrashDumps\MyApp

Volcado completo ante una excepción no controlada, esperando al próximo inicio

procdump -accepteula -ma -e -w MyApp.exe C:\CrashDumps\MyApp

Iniciarlo uno mismo y vigilarlo directamente

procdump -accepteula -ma -e -x C:\CrashDumps\MyApp MyApp.exe

Cuando también se quiere capturar first chance exceptions

procdump -accepteula -ma -n 3 -e 1 MyApp.exe C:\CrashDumps\MyApp

Cuando se quiere capturar un hang

procdump -accepteula -h MyApp.exe C:\CrashDumps\MyApp

5.3 Por qué no conviene usar -i como primer paso

ProcDump también se puede usar con -i para registrarse como postmortem debugger. Esto es potente, pero afecta al comportamiento de toda la máquina ante un fallo, por lo que resulta un poco pesado como primer paso en la etapa inicial.

Por eso, es más manejable empezar por la configuración de WER por aplicación, o por -w / -x de ProcDump, o especificando directamente el PID.

6. Consideraciones al usar MiniDumpWriteDump para una recolección propia

La recolección propia resulta adecuada, por ejemplo, en situaciones como estas.

• Se quiere ofrecer un botón de «Guardar información de diagnóstico» desde la interfaz de usuario
• Se quiere agrupar el volcado junto con registros, configuración e ID de traza
• Se quiere reunir también los procesos hijos o auxiliares relacionados
• Se quiere aplicar un enmascarado o una compresión propios antes de subir el archivo

La API central en este caso es MiniDumpWriteDump.

Sin embargo, esta API tiene ciertas particularidades. En la etapa inicial, hay dos puntos que conviene no pasar por alto.

1. Siempre que sea posible, llamarla desde un proceso distinto al que se va a volcar
2. Tratar las funciones de la familia DbgHelp asumiendo que no son seguras para múltiples subprocesos (single-threaded)

7. Cómo elegir entre minidump, volcado completo y tamaños intermedios

Son muchas las personas que dudan en este punto. A continuación se resume en una tabla cómo elegir en la práctica.

La recomendación para quien empieza es bastante simple.

• En máquinas de desarrollo o verificación, usar el volcado completo
• En el entorno del cliente, elegir entre minidump o volcado completo según las condiciones de operación
• Si se sospecha de corrupción de memoria, DLL nativas, COM, P/Invoke o anomalías de estado tras una ejecución prolongada, inclinarse hacia el volcado completo

7.1 Cómo se especifican realmente MiniPlus y Custom

Solo la tercera fila de la tabla tiene una forma de especificación algo confusa, así que se aclara a continuación.

En el caso de WER LocalDumps, se pone DumpType en 0 (personalizado) y se coloca en CustomDumpFlags la combinación de bits de MINIDUMP_TYPE. CustomDumpFlags es un valor que solo se usa cuando DumpType=0, y su valor predeterminado es 0x00000121 (la combinación de MiniDumpWithDataSegs, MiniDumpWithUnloadedModules y MiniDumpWithProcessThreadData).

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpType /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v CustomDumpFlags /t REG_DWORD /d 0x121 /f

En el caso de ProcDump, -mp corresponde a MiniPlus y -mc <Mask> al modo personalizado.

procdump -accepteula -mp -e MyApp.exe C:\CrashDumps\MyApp

A pesar de su nombre, el contenido de MiniPlus está bastante cerca del volcado completo. Según la documentación, incluye toda la memoria privada y toda la memoria de imagen o mapeada con permisos de lectura/escritura, y después excluye únicamente la región privada más grande que supere los 512 MB para contener el tamaño. Como resultado, queda posicionado como «tan detallado como un volcado completo, pero con un tamaño de entre el 10 % y el 75 % del completo».

Sin embargo, hay dos puntos a tener en cuenta.

• Debido a limitaciones de depuración, en los procesos CLR el volcado se captura como completo (-ma) aunque se especifique -mp. Contar con que MiniPlus reduzca el tamaño en una aplicación .NET suele fallar
• Si el motivo para reducir el tamaño es «disminuir el riesgo de que se filtre información confidencial», es más directo pensar en el minidump en lugar de en MiniPlus

8. Qué decidir de antemano en la operación

En la recolección de volcados, hay bastantes casos en los que el problema surge en la operación, más que en la implementación. A continuación se enumera lo que conviene decidir de antemano.

8.1 Cómo conservar el PDB y los binarios

Esto es lo más importante.

• La versión exacta del EXE/DLL distribuido
• El PDB correspondiente a esa versión
• Con qué commit o con qué pipeline de compilación se generó
• La información de versión del instalador o del paquete distribuido

8.2 Dónde generarlo y cuántos conservar

El volcado completo puede llegar a ser bastante grande. Es más seguro decidir desde el principio la política de destino y de conservación.

• No dejarlo abandonado directamente en la unidad del sistema
• Separarlo en una carpeta dedicada
• Establecer un límite con DumpCount o con -n
• Diferenciar el almacenamiento a largo plazo del almacenamiento temporal

8.3 Quién puede tener acceso a él

El volcado completo puede llegar a contener información confidencial o datos personales.

• Configuración en texto plano
• Cadenas de conexión
• Tokens o credenciales
• Datos de negocio que se estaban manejando justo antes
• Rutas de archivo o nombres de usuario

Por eso, es necesario decidir «quién puede acceder a él» al mismo tiempo que se diseña «cómo capturarlo».

9. El camino más corto de análisis una vez obtenido el volcado

Una vez capturado el volcado, lo primero que hay que hacer es sorprendentemente sencillo.

9.1 Instalar WinDbg

Actualmente resulta fácil instalar WinDbg desde Microsoft Store o con winget.

winget install Microsoft.WinDbg

9.2 Abrir el volcado

windbg -z C:\CrashDumps\MyApp\MyApp_YYMMDD_HHMMSS.dmp

El nombre de archivo usado aquí es el nombre predeterminado que asigna ProcDump. Su nombre de archivo predeterminado es PROCESSNAME_YYMMDD_HHMMSS.dmp, y se pueden usar como marcadores de sustitución PROCESSNAME, PID, EXCEPTIONCODE, YYMMDD y HHMMSS.

Por otro lado, WER LocalDumps crea los archivos con una convención de nombres distinta a la de ProcDump. Como Microsoft Learn no especifica claramente esta convención, en lugar de intentar adivinar el nombre, es más fiable revisar la carpeta de destino ordenada por fecha de modificación.

dir /o-d "C:\CrashDumps\MyApp\*.dmp"

Si no se ha configurado DumpFolder, el destino predeterminado es %LOCALAPPDATA%\CrashDumps. Sin embargo, el fallo de un servicio se genera en la carpeta de perfil correspondiente a la cuenta con la que se ejecuta. Para el servicio System es %WINDIR%\System32\Config\SystemProfile, y para Network Service o Local Service es bajo %WINDIR%\ServiceProfiles. Si se piensa que «no se ha generado el volcado», este es el primer lugar que hay que revisar.

9.3 Configurar los símbolos

Primero se deja disponible el acceso a los símbolos públicos de Microsoft, y después se añade la ubicación del PDB propio.

.symfix C:\Symbols\Microsoft
.sympath+ C:\Symbols\MyApp
.reload

9.4 Ver primero el análisis automático

!analyze -v

A partir de ahí, se revisan en orden estos puntos:

• Qué código de excepción es
• Cuál es el faulting module
• Hasta dónde aparece el propio código en la pila
• Si hay alguna espera o bloqueo sospechoso fuera del subproceso de la excepción

10. Errores comunes en los que se suele caer

10.1 Se obtuvo el volcado, pero falta el PDB

Esto ocurre con bastante frecuencia. Aunque la recolección del volcado haya tenido éxito, falta el material necesario para leerlo. Es mejor incorporar el diseño de conservación del PDB al mismo tiempo que la configuración de recolección.

10.2 No se ha revisado la ACL de DumpFolder

En servicios o procesos con permisos separados, es fácil que esto falle sin dar ningún resultado. Conviene comprobar primero si ese proceso realmente puede escribir ahí. Microsoft Learn también indica que, si se usa una ruta distinta de la predeterminada, hay que comprobar que la ACL permita escribir al proceso que ha fallado.

La ACL actual se puede consultar con icacls.

icacls C:\CrashDumps\MyApp

Si faltan permisos de escritura, se añade M (modificar) a la cuenta de ejecución. Como la carpeta de volcados también necesita el mismo permiso en los archivos que contiene, se añaden (OI) y (CI) para que se herede.

rem Ejemplo: servicio que se ejecuta con Network Service
icacls C:\CrashDumps\MyApp /grant "NT AUTHORITY\NETWORK SERVICE:(OI)(CI)M"

(OI) hace que la ACE se herede en los archivos subordinados, y (CI), en las carpetas subordinadas. El alcance de esta herencia determina directamente quién puede leer el volcado, así que antes de aplicarla conviene comprobar que no entra en conflicto con la política decidida en el apartado 8.3.

10.3 Seguir generando volcados completos en la unidad del sistema de la máquina de producción

Este es un clásico de los incidentes por falta de espacio. Hay que aplicar el límite en el número de copias y la separación del destino desde el principio.

10.4 Intentar cubrir también todos los hangs solo con WER

WER LocalDumps es, ante todo, fuerte frente a los fallos (crashes). Hay situaciones en las que ProcDump resulta más adecuado para los hangs o las first chance exceptions.

10.5 Dejar -e 1 activado de forma permanente y desatar una tormenta de excepciones

Las first chance exceptions son útiles, pero son bastante frecuentes. Lo realista es poner un límite en el número de casos, activarlo solo durante un periodo corto y limitar el objetivo.

11. Resumen

El volcado de memoria de fallo es un punto de observación bastante potente frente a incidencias con baja tasa de reproducción. En particular, si en una aplicación Windows intervienen COM, P/Invoke, DLL nativas o una ejecución prolongada, vale la pena decidir desde el principio «qué va a quedar registrado si el programa falla».

El orden recomendado es sencillo.

1. Primero, implantar WER LocalDumps por aplicación
2. Si hace falta, añadir ProcDump
3. Si se quiere un control aún mayor, usar MiniDumpWriteDump desde un proceso independiente

Siguiendo este orden, es difícil equivocarse de forma significativa.

12. Referencias

• Recopilación de volcados en modo usuario - Win32 apps | Microsoft Learn
• ProcDump v11.1 - Sysinternals | Microsoft Learn
• MiniDumpWriteDump function (minidumpapiset.h) - Win32 | Microsoft Learn
• User-mode dump files - Windows drivers | Microsoft Learn
• Análisis de un archivo de volcado en modo usuario - Windows drivers | Microsoft Learn
• Instalar el depurador de Windows - Windows drivers | Microsoft Learn
• Symbol path for Windows debuggers - Windows drivers | Microsoft Learn
• !analyze (WinDbg) - Windows drivers | Microsoft Learn
• Troubleshoot processes by using Task Manager - Windows Server | Microsoft Learn
• Enabling Postmortem Debugging - Windows drivers | Microsoft Learn
• MINIDUMP_TYPE enumeration (minidumpapiset.h) - Win32 | Microsoft Learn
• icacls - Windows commands | Microsoft Learn
• NotMyFault - Sysinternals | Microsoft Learn

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Qué es un volcado de memoria de fallo (crash dump)? ¿Qué información aporta?

Es un archivo que guarda el estado del proceso en el instante exacto del fallo, como una instantánea fija de la escena de un accidente. Permite comprobar después el código de excepción, el subproceso (thread) que falló y su pila de llamadas, los módulos que estaban cargados y, según la cantidad de memoria incluida, incluso el contenido de los objetos en el montículo (heap). Por otro lado, suele faltar la línea temporal que llevó hasta ese momento y el estado externo de comunicaciones o dispositivos, por lo que en la práctica lo habitual es combinarlo con registros (logs) y heartbeats.

¿Dónde se configura LocalDumps de WER?

Se configura en el registro, bajo HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps. En la práctica es más manejable usar una subclave por aplicación, como MyApp.exe, en lugar de la configuración global. Los tres valores que conviene revisar primero son DumpFolder (destino), DumpCount (número de copias que se conservan) y DumpType (tipo de volcado); con esto se puede dejar el volcado localmente tras un fallo sin distribuir ninguna herramienta adicional.

¿Debo elegir minidump o volcado completo (full dump)?

Como referencia general, en máquinas de desarrollo o de verificación conviene usar el volcado completo (DumpType=2), y en el entorno del cliente hay que elegir entre minidump (DumpType=1) o volcado completo según el espacio disponible y los requisitos de confidencialidad. Cuando se sospecha de corrupción de memoria, DLL nativas, COM, P/Invoke o anomalías de estado tras una ejecución prolongada, el volcado completo resulta más ventajoso. Sin embargo, el volcado completo ocupa mucho espacio y conlleva el riesgo de incluir información confidencial, como cadenas de conexión o tokens, por lo que es necesario decidir de antemano el lugar de almacenamiento, el número de copias que se conservan y los permisos de acceso.

¿En qué situaciones conviene usar ProcDump?

Dado que LocalDumps de WER está pensado básicamente para fallos (crashes), ProcDump resulta más adecuado cuando también se quiere observar hangs o first chance exceptions, cuando se prefiere evitar dejar una configuración permanente en el registro, o cuando solo se necesita vigilar un proceso que ya está en ejecución. Las opciones representativas son -ma para el volcado completo, -e para capturarlo ante una excepción no controlada, -h para la detección de hangs y -w para esperar el inicio del proceso. Como -e 1, que apunta a las first chance exceptions, tiende a generar muchos volcados, en la práctica es más realista usarlo de forma acotada y por poco tiempo, por ejemplo poniendo un límite con -n.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.