有了前几节的准备工作，我们的程序已经可以自动捕获异常了，那么我们开始通过windbg来分析dump解决实际问题。先从简单入手，一个index过大导致数组越界引发的崩溃。
1、使用windbg 打开dump，设置pdb、系统pdb。
2、设置完成后，执行命令".ecxr"。 因为是程序自动截获异常，所以dump中已保存了异常的上下文，直接使用".ecxr" 切换即可。
0:135> .ecxr
eax=0dea0048 ebx=0016ae18 ecx=7ff22000 edx=004b38e8 esi=0aba40b8 edi=0016ae10
eip=004448cd esp=0ba9ebfc ebp=0ba9ec08 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
CheckSvr!CalcKubIndexByGameID+0x1d:
004448cd ?? ???
3、“kv”。打印异常上下文的栈信息
0:135> kv
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
0ba9ec08 0040d9c4 0dea0048 af7220ac 0016ae10 CheckSvr!CalcKubIndexByGameID+0x1d (FPO: [Non-Fpo]) (CONV: cdecl) [d:\program files (x86)\jenkins\workspace\publish_gamechannel\checksvr\main.cpp @ 1082]
0ba9fcd4 0040bcb4 0db37c10 0db41a88 0aae48c0 CheckSvr!CSockServer::OnRefreshResultExFromKub+0x1ce4 (FPO: [Non-Fpo]) (CONV: thiscall) [d:\program files (x86)\jenkins\workspace\publish_gamechannel\checksvr\cmpaqpro.cpp @ 1081]
0ba9feb4 0045ca88 0db37c10 0db41a88 0aae48c0 CheckSvr!CSockServer::OnRefreshResultEx+0x134 (FPO: [Non-Fpo]) (CONV: thiscall) [d:\program files (x86)\jenkins\workspace\publish_gamechannel\checksvr\cmpaqpro.cpp @ 419]
0ba9ff2c 00477674 0db37c10 0db41a88 0016ae18 CheckSvr!CSockServer::OnRequest+0xd38 (FPO: [Non-Fpo]) (CONV: thiscall) [d:\program files (x86)\jenkins\workspace\publish_gamechannel\checksvr\socksvr.cpp @ 1931]
0ba9ff54 0047e7db 00000000 0aae5e68 0a9c23a0 CheckSvr!CIocpWorker::DoWorkLoop+0xa4
0ba9ff6c 0047e7ab 0ba9ffac 0050c01d 0016ae10 CheckSvr!CBaseWorker::WorkerThreadProc+0x2b
0ba9ff74 0050c01d 0016ae10 876c3023 00000000 CheckSvr!CBaseWorker::WorkerThreadFunc+0xb
4、异常函数为CalcKubIndexByGameID， 入参的值为0dea0048。 回到代码查看CalcKubIndexByGameID的实现，
int CalcKubIndexByGameID(int nGameID )
{
return g_kub[nGameID];
}
明显nGameID 过大导致访问数组越界。 然后排查代码，发现nGameID未使用默认值，某些条件下使用了随机值导致。
