今天遇到一個比較有意思的bug, 這里簡單記錄下。
Bug的癥狀是通過拖拉邊框把我們客戶端主窗口拖小之后，再最大化，會發現窗口顯示有問題， 看起來像是刷新問題， 有些地方顯示的不對了。
這里要說明的是我這里的主窗口是非常復雜的窗口， 里面集成了很多組件(cpmponent)，有很多層的子窗口。 這個問題只有在特定條件下才會發生， 正常情況下都是好的。
遇到這種問題，我們怎么處理？
首先當然是觀察癥狀， 究竟是刷新問題， 還是Layout出錯了。
我們可以通過Spy++查看窗口層次是不是正確， 窗口位置是不是對的。
查看結果是窗口的層次和Layout位置都沒有問題。
既然我們這里遇到的刷新問題，所以我們要從WM_PAINT消息著手， 我們通過Spy++查看相關窗口的WM_PAINT是不是正確。
很快我們就會發現某個窗口正在不停地收到WM_PAINT消息， 很可能與我們的bug有關。
一個窗口不停的收到WM_PAINT重畫， 無非大概有幾類原因：
正常情況是我們正在做動畫， 可能是通過定時器之類的東西讓窗口不停地InvalidateRect重畫某塊區域， 我們的窗口明顯不屬于這種情況。
異常情況有時是WM_PAINT消息里我們的消息處理函數在某些條件下直接返回了，從而沒有調用BeginPaint告訴窗口無效區域已經有效， 這樣會因為因為窗口一直有無效區域存在，導致窗口一直收到WM_PAINT消息。
還有一種異常情況情況是我們是在WM_PAINT消息里調用BeginPaint后又調用了InvalidateRect, 這樣會導致窗口后面會再次收到WM_PAINT消息， 最后窗口陷入WM_PAINT的死循環。
那么我們這里的問題窗口屬于哪類？ 用什么方法可以判斷出來？
注意到這里關鍵的三個API：BeginPaint， EndPaint, InvalidateRect的第一個參數都是窗口句柄， 我們可以通過WinDbg的API斷點來跟蹤執行過程， Attach WinDbg到我們的主窗口進程，比如我們的窗口句柄是0x209A0, 我們可以這樣設置API斷點：
bp USER32!NtUserInvalidateRect ".if(dwo(@esp+0x4)==0x209A0) {kv;gc} .else {gc}"
bp USER32!NtUserBeginPaint ".if(dwo(@esp+0x4)==0x209A0) {kv;gc} .else {gc}"
bp USER32!NtUserEndPaint ".if(dwo(@esp+0x4)==0x209A0) {kv;gc} .else {gc}"
上面的條件斷點表示，當調用我們的對應的API，并且第一個參數(窗口句柄)是我們的目標窗口時，打印堆棧。
很快我定位出Bug發生的原因了， 條件斷點顯示了API如下的調用次序：
BeginPaint->InvalidateRect->InvalidateRect->EndPaint
找到Bug的原因后，然后把Bug assign給該模塊的負責人。 （看我夠意思吧，不僅找到原因，還把調用棧都提供了）
另外 ，后面還發現這個bug發生時窗口的某些行為會不對， 測試發現原因是所有窗口的定時器都不能正常工作了。
關于這個問題， 你能想到原因嗎？
如果看了還想不到， 重點看第4條。
最后， 簡單總結下：計算機的好處是它永遠不會欺騙你， 它只會按部就班的執行， 所以很多看似奇怪(甚至看似不可思議的問題)， 只要你理解了程序背后的機制原理，都是可以找出根本原因的。
posted on 2014-05-30 23:18
Richard Wei 閱讀(2675)
評論(2) 編輯 收藏 引用 所屬分類:
windbg