How to debug MU Online client crashes with WinDbg

Client crashes are one of the most frustrating support tickets to solve "in the dark": the player reports "the game just closes," with no further details, and without an analysis tool you're reduced to trial and error. WinDbg, Microsoft's free debugger, lets you open the memory dump generated at the moment of the crash and see exactly which module, function, and (sometimes) line of code caused the failure — even in clients with custom third-party DLLs. This tutorial walks through configuring WinDbg, capturing the dump, reading the call stack, and correlating the crash with recent client changes.

When it's worth using WinDbg

Not every crash requires deep analysis — a clear "file not found" error in the launcher log already resolves a good portion of cases. WinDbg comes into play when the crash is silent (the client simply closes), intermittent (it only happens sometimes, in specific situations), or correlated with a recent change (a new custom wing, a new visual effect, a launcher update). In these cases, the memory dump is the only reliable source of truth.

Prerequisites

• WinDbg installed (available for free via the Microsoft Store as "WinDbg Preview" or in the Windows SDK).
• Access to the machine where the crash happens (your own or the player's, with authorization).
• Ideally, debug symbols (PDB) for the client build, if you compiled or customized the client yourself.
• A MU client that reproduces the crash consistently, or at least fairly frequently.

Step 1 — Configure the symbol path

Without symbols, WinDbg shows only memory addresses instead of function names. Configure Microsoft's symbol path (for operating system DLLs) and, if available, the path to your own PDBs:

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

This already greatly improves call stack readability for Windows modules (kernel32, ntdll) even without your own client symbols.

Step 2 — Capture the dump at the moment of the crash

There are two main approaches:

1. Windows Error Reporting (WER): configure Windows to automatically generate a dump whenever the client process fails, via the LocalDumps registry key, pointing to a destination folder.
2. Active WinDbg attach: open WinDbg, use File > Attach to Process before starting the client (or attach while it's already running), and leave it monitoring until the crash occurs — WinDbg automatically pauses execution at the moment of failure.

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 generates a full dump; 1 generates a minidump, sufficient for most cases and much lighter.

Step 3 — Open the dump in WinDbg

Open the generated .dmp file via File > Open Dump File. The first command to always run is:

!analyze -v

This command runs an automatic analysis and already suggests the likely exception, the module involved, and a call stack summary — it's the starting point of any investigation.

Step 4 — Read the call stack

If !analyze -v isn't enough, examine the stack manually:

kb

The output lists the functions called up to the point of the crash, from most recent to oldest. Look for the first entry that does not belong to a system DLL (ntdll.dll, kernel32.dll) — that's usually where the client's own module or a custom DLL responsible for the failure sits.

Step 5 — Identify modules loaded at the moment of the crash

lm

This command lists every module (DLL) loaded in the process. Compare this list to what you'd expect the client to have — an unknown or third-party DLL (overlay, recording tool, unofficial mod) near the top of the call stack is a strong indicator of the cause.

Step 6 — Interpret the exception type

The table below summarizes the most common exception codes in MU client crashes and what they typically indicate:

Step 7 — Correlate with recent client changes

If the crash started happening after an update (a new wing, a new effect, a launcher update), compare the loaded modules list (lm) with the files modified in the latest update. A 0xC0000005 crash right after adding a custom wing, for example, points strongly to a malformed BMD — review the process described in the custom wings tutorial if that's the case.

Step 8 — Test hypotheses by isolating components

Once you've formed a hypothesis (e.g., "the new texture is causing the crash"), test it by reverting just that component on an isolated client and reproducing the action that caused the failure. If the crash stops happening, the cause is confirmed; if it persists, go back to the dump and reassess the call stack — there may be more than one concurrent cause.

Step 9 — Document and prevent recurrence

For every crash investigated, record: exception code, module responsible, root cause, and fix applied. This history becomes a valuable knowledge base for the support team to quickly recognize patterns in future tickets, without needing to reopen WinDbg for every similar case.

Common errors and fixes

Investigation checklist

• Symbol path configured (Microsoft + your own PDBs, if any).
• Dump captured (via WER or direct attach) at the moment of the crash.
• !analyze -v run as the first triage step.
• Call stack (kb) reviewed until identifying the non-system module involved.
• Loaded modules (lm) compared against a clean reference install.
• Exception code interpreted and cross-referenced with recent client changes.
• Root cause documented for future reference by the support team.

Making a habit of investigating crashes via dumps instead of trial and error gives your server's support real speed and precision — and whenever the cause involves custom client content, it's worth revisiting the update distribution process described in the server creation tutorial to make sure files reach every player intact.

Frequently asked questions