單步到崩潰地點，有數組取數據和拷貝操作，猜測數組越界導致的棧溢出。就開始找越界檢查工具。
vs自身帶的/GS只是在棧溢出時蹦個異常，不會給你定位崩在哪。所以找了會兒別的工具，boundschecker還沒找到下的地方，IBM的purify跨平臺但是收費，另外免費好用的就是linux下的valgrind了。這幾種內存檢查工具都可以檢查內存泄露和越界之類的。只是項目現在趕進度，linux平臺的編譯還沒時間解決，內存統一檢查就作罷。
開始看看能不能查dump。dump不是原生的dmp而是歷史代碼里重存為別的了。vc調試不很熟練，就索性把重存dump那塊兒的catch給干掉了。直接讓編譯器崩到代碼塊兒再看看能不能看出什么問題。
崩停到具體代碼行了，很驚喜，趕緊看看各變量內存狀況，問題數組是一個指針數組，這次驚喜的發現之前單步的那個下標對應在數組元素指針跟別的不一樣，為0xcdcdcdcd，確認了下為vc下為未初始化的指針。
這樣就好查了，問題定位到了，后邊的就不啰嗦了。
最終問題是，同事給一個類新加了幾個指針成員，但是這幾個沒有new出來初始化之。唉……只能感嘆下敏捷開發那本書里說的，架構師要參加編碼，我覺得要加點兒，就是架構師要參與編碼還要參與測試調試自己的代碼。