Cómo depurar crashes del cliente de MU Online con WinDbg

Los crashes de cliente son uno de los tickets de soporte más frustrantes de resolver "a ciegas": el jugador reporta "el juego se cierra solo", sin más detalles, y sin una herramienta de análisis quedas reducido a prueba y error. WinDbg, el depurador gratuito de Microsoft, permite abrir el dump de memoria generado en el momento del crash y ver exactamente qué módulo, función y (a veces) línea de código causó la falla — incluso en clientes con DLLs personalizadas de terceros. Este tutorial recorre la configuración de WinDbg, la captura del dump, la lectura de la call stack y la correlación del crash con cambios recientes en el cliente.

Cuándo vale la pena usar WinDbg

No todo crash exige un análisis profundo — un error claro de "archivo no encontrado" en el log del launcher ya resuelve buena parte de los casos. WinDbg entra en escena cuando el crash es silencioso (el cliente simplemente se cierra), intermitente (ocurre solo a veces, en situaciones específicas) o correlacionado con un cambio reciente (nueva ala custom, nuevo efecto visual, actualización del launcher). En esos casos, el dump de memoria es la única fuente de verdad confiable.

Prerrequisitos

• WinDbg instalado (disponible gratuitamente vía Microsoft Store como "WinDbg Preview" o en el Windows SDK).
• Acceso a la máquina donde ocurre el crash (propia o del jugador, con autorización).
• Idealmente, símbolos de depuración (PDB) del build del cliente, si tú mismo compilaste o personalizaste el cliente.
• Un cliente de MU que reproduzca el crash de forma consistente, o al menos con frecuencia razonable.

Paso 1 — Configurar la ruta de símbolos (symbol path)

Sin símbolos, WinDbg muestra solo direcciones de memoria en vez de nombres de función. Configura la ruta de símbolos de Microsoft (para DLLs del sistema operativo) y, si está disponible, la ruta de tus propios PDBs:

.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols;C:\MeuCliente\PDB
.reload

Esto ya mejora bastante la legibilidad de la call stack para módulos de Windows (kernel32, ntdll) incluso sin símbolos propios del cliente.

Paso 2 — Capturar el dump en el momento del crash

Existen dos formas principales:

1. Windows Error Reporting (WER): configura Windows para generar automáticamente un dump cada vez que el proceso del cliente falle, vía la clave de registro LocalDumps, apuntando a una carpeta de destino.
2. Attach activo de WinDbg: abre WinDbg, usa File > Attach to Process antes de iniciar el cliente (o adjúntalo con el cliente ya corriendo) y déjalo monitoreando hasta que ocurra el crash — WinDbg pausa automáticamente la ejecución en el momento de la falla.

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpFolder /t REG_EXPAND_SZ /d "C:\Dumps" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpType /t REG_DWORD /d 2 /f

DumpType 2 genera un dump completo; 1 genera un minidump, suficiente para la mayoría de los casos y mucho más liviano.

Paso 3 — Abrir el dump en WinDbg

Abre el archivo .dmp generado vía File > Open Dump File. El primer comando a ejecutar es siempre:

!analyze -v

Este comando hace un análisis automático y ya sugiere la excepción probable, el módulo involucrado y un resumen de la call stack — es el punto de partida de cualquier investigación.

Paso 4 — Leer la call stack (pila de llamadas)

Si !analyze -v no es suficiente, examina la pila manualmente:

kb

La salida lista las funciones llamadas hasta el punto del crash, de la más reciente a la más antigua. Busca la primera entrada que no pertenezca a una DLL del sistema (ntdll.dll, kernel32.dll) — generalmente ahí está el módulo del propio cliente o de una DLL personalizada responsable de la falla.

Paso 5 — Identificar módulos cargados en el momento del crash

lm

Este comando lista todos los módulos (DLLs) cargados en el proceso. Compara esa lista con lo que esperas que esté en el cliente — la presencia de una DLL desconocida o de terceros (overlay, herramienta de grabación, mod no oficial) en la parte superior de la call stack es un fuerte indicio de la causa.

Paso 6 — Interpretar el tipo de excepción

La siguiente tabla resume los códigos de excepción más comunes en crashes de cliente de MU y lo que suelen indicar:

Paso 7 — Correlacionar con cambios recientes en el cliente

Si el crash empezó a ocurrir después de una actualización (nueva ala, nuevo efecto, actualización del launcher), compara la lista de módulos cargados (lm) con los archivos modificados en la última actualización. Un crash en 0xC0000005 justo después de agregar un ala personalizada, por ejemplo, apunta fuertemente a un BMD malformado — revisa el proceso descrito en el tutorial de alas personalizadas si ese es el caso.

Paso 8 — Probar hipótesis aislando componentes

Después de formar una hipótesis (ej.: "la textura nueva está causando el crash"), pruébala revirtiendo solo ese componente en un cliente aislado y reproduciendo la acción que generaba la falla. Si el crash deja de ocurrir, la causa está confirmada; si persiste, vuelve al dump y reevalúa la call stack — puede haber más de una causa concurrente.

Paso 9 — Documentar y prevenir recurrencia

Registra, para cada crash investigado: código de excepción, módulo responsable, causa raíz y corrección aplicada. Este historial se convierte en una base de conocimiento valiosa para que el equipo de soporte reconozca patrones rápidamente en tickets futuros, sin necesidad de reabrir WinDbg para cada caso similar.

Errores comunes y soluciones

Lista de verificación de investigación

• Ruta de símbolos configurada (Microsoft + PDBs propios, si los hay).
• Dump capturado (vía WER o attach directo) en el momento del crash.
• !analyze -v ejecutado como primer paso de triaje.
• Call stack (kb) revisada hasta identificar el módulo no-sistema involucrado.
• Módulos cargados (lm) comparados con una instalación limpia de referencia.
• Código de excepción interpretado y cruzado con cambios recientes en el cliente.
• Causa raíz documentada para consulta futura del equipo de soporte.

Con el hábito de investigar crashes vía dump en vez de prueba y error, el soporte de tu servidor gana velocidad y precisión real — y siempre que la causa involucre contenido personalizado del cliente, vale la pena revisar el proceso de distribución de actualizaciones descrito en el tutorial de creación de servidor para garantizar que los archivos lleguen íntegros a todos los jugadores.

Preguntas frecuentes