今天遇到一个比较有意思的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发生时窗口的某些行为会不对, 测试发现原因是所有窗口的定时器都不能正常工作了。
关于这个问题, 你能想到原因吗? 

如果想不到, 请把我的这篇博客《从点击Button到弹出一个MessageBox, 背后发生了什么》看一遍。
如果看了还想不到, 重点看第4条。

最后, 简单总结下:计算机的好处是它永远不会欺骗你, 它只会按部就班的执行, 所以很多看似奇怪(甚至看似不可思议的问题), 只要你理解了程序背后的机制原理,都是可以找出根本原因的。
posted on 2014-05-30 23:18 Richard Wei 阅读(2189) 评论(2)  编辑 收藏 引用 所属分类: windbg

FeedBack:
# re: 记一个界面刷新相关的Bug
2014-06-04 09:59 | friv 3
我将收藏此页,并与他的几个朋友一起分享,希望他们能有所帮助。感谢分享。
http://www.friv3go.com  回复  更多评论
  
# re: 记一个界面刷新相关的Bug
2014-06-22 20:52 | 旗袍女装
所以很多看似奇怪(甚至看似不可思议的问题), 只要你理解了程序背后的机制原理,都是可以找出根本原因的。旗袍女装www.ssnz88.net  回复  更多评论
  

只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理