Como debugar crash do cliente de MU Online com o WinDbg

Crashes de cliente são um dos tickets de suporte mais frustrantes de resolver "no escuro": o jogador reporta "o jogo fecha sozinho", sem mais detalhes, e sem uma ferramenta de análise você fica reduzido a tentativa e erro. O WinDbg, depurador gratuito da Microsoft, permite abrir o dump de memória gerado no momento do crash e enxergar exatamente qual módulo, função e (às vezes) linha de código causou a falha — inclusive em clientes com DLLs customizadas de terceiros. Este tutorial percorre a configuração do WinDbg, a captura do dump, a leitura da call stack e a correlação do crash com mudanças recentes no cliente.

Quando vale a pena usar o WinDbg

Nem todo crash exige análise profunda — um erro claro de "arquivo não encontrado" no log do launcher já resolve boa parte dos casos. O WinDbg entra em cena quando o crash é silencioso (o cliente simplesmente fecha), intermitente (acontece só às vezes, em situações específicas) ou correlacionado a uma mudança recente (nova asa custom, novo efeito visual, atualização do launcher). Nesses casos, o dump de memória é a única fonte de verdade confiável.

Pré-requisitos

• WinDbg instalado (disponível gratuitamente via Microsoft Store como "WinDbg Preview" ou no Windows SDK).
• Acesso à máquina onde o crash ocorre (própria ou do jogador, com autorização).
• Idealmente, símbolos de depuração (PDB) do build do cliente, se você mesmo compilou ou customizou o cliente.
• Um cliente de MU que reproduza o crash de forma consistente, ou pelo menos com frequência razoável.

Passo 1 — Configurar o caminho de símbolos (symbol path)

Sem símbolos, o WinDbg mostra apenas endereços de memória em vez de nomes de função. Configure o caminho de símbolos da Microsoft (para DLLs do sistema operacional) e, se disponível, o caminho dos seus próprios PDBs:

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

Isso já melhora bastante a legibilidade da call stack para módulos do Windows (kernel32, ntdll) mesmo sem símbolos próprios do cliente.

Passo 2 — Capturar o dump no momento do crash

Existem duas formas principais:

1. Windows Error Reporting (WER): configure o Windows para gerar automaticamente um dump sempre que o processo do cliente falhar, via chave de registro LocalDumps, apontando para uma pasta de destino.
2. Attach ativo do WinDbg: abra o WinDbg, use File > Attach to Process antes de iniciar o cliente (ou anexe já com o cliente rodando) e deixe monitorando até o crash ocorrer — o WinDbg pausa automaticamente a execução no momento da falha.

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 gera um dump completo; 1 gera um minidump, suficiente para a maioria dos casos e bem mais leve.

Passo 3 — Abrir o dump no WinDbg

Abra o arquivo .dmp gerado via File > Open Dump File. O primeiro comando a rodar é sempre:

!analyze -v

Esse comando faz uma análise automática e já sugere a exceção provável, o módulo envolvido e um resumo da call stack — é o ponto de partida de qualquer investigação.

Passo 4 — Ler a call stack (pilha de chamadas)

Se !analyze -v não for suficiente, examine a pilha manualmente:

kb

A saída lista as funções chamadas até o ponto do crash, da mais recente para a mais antiga. Procure a primeira entrada que não pertence a uma DLL do sistema (ntdll.dll, kernel32.dll) — geralmente é ali que está o módulo do próprio cliente ou de uma DLL customizada responsável pela falha.

Passo 5 — Identificar módulos carregados no momento do crash

lm

Esse comando lista todos os módulos (DLLs) carregados no processo. Compare essa lista com o que você espera que esteja no cliente — a presença de uma DLL desconhecida ou de terceiros (overlay, ferramenta de gravação, mod não oficial) no topo da call stack é um forte indício da causa.

Passo 6 — Interpretar o tipo de exceção

A tabela abaixo resume os códigos de exceção mais comuns em crashes de cliente de MU e o que costumam indicar:

Passo 7 — Correlacionar com mudanças recentes no cliente

Se o crash começou a ocorrer após uma atualização (nova asa, novo efeito, atualização do launcher), compare a lista de módulos carregados (lm) e os arquivos modificados na última atualização. Um crash em 0xC0000005 logo após adicionar uma asa customizada, por exemplo, aponta fortemente para um BMD malformado — revise o processo descrito no tutorial de asas customizadas se esse for o caso.

Passo 8 — Testar hipóteses isolando componentes

Depois de uma hipótese formada (ex.: "a textura nova está causando o crash"), teste revertendo apenas esse componente em um cliente isolado e reproduzindo a ação que gerava a falha. Se o crash parar de ocorrer, a causa está confirmada; se persistir, volte ao dump e reavalie a call stack — pode haver mais de uma causa concorrente.

Passo 9 — Documentar e prevenir recorrência

Registre, para cada crash investigado: código de exceção, módulo responsável, causa raiz e correção aplicada. Esse histórico vira uma base de conhecimento valiosa para a equipe de suporte reconhecer padrões rapidamente em tickets futuros, sem precisar reabrir o WinDbg para cada caso semelhante.

Erros comuns e soluções

Checklist de investigação

• Caminho de símbolos configurado (Microsoft + PDBs próprios, se houver).
• Dump capturado (via WER ou attach direto) no momento do crash.
• !analyze -v executado como primeiro passo de triagem.
• Call stack (kb) revisada até identificar o módulo não-sistema envolvido.
• Módulos carregados (lm) comparados a uma instalação limpa de referência.
• Código de exceção interpretado e cruzado com mudanças recentes no cliente.
• Causa raiz documentada para consulta futura da equipe de suporte.

Com o hábito de investigar crashes via dump em vez de tentativa e erro, o suporte do seu servidor ganha velocidade e precisão real — e sempre que a causa envolver conteúdo customizado do cliente, vale revisitar o processo de distribuição de atualizações descrito no tutorial de criação de servidor para garantir que os arquivos chegam íntegros a todos os jogadores.

Perguntas frequentes