【原创】窗口消息处理问题

      今天修改了一下之前做的一个Dll注入exe的Demo。之前由于项目需求，所以了解了一下远程注入Dll方面的知识，其实这个Demo也没有使用到远程注入的方面，只是写了一个Dll，在我的Dll中实现对将要注入进程里的一个窗口进行子类化，写好之后通过工具把我的dll注入到将要注入的应用程序中。

      在我的dll中有一个读取注册表键值的函数: BOOL ReadData()，通过函数把键值保存在一个全局变量dValue。在子类化的过程中，我首先拦截原进程的消息，相应自己的消息处理函数，子类化几乎都是这样做的。但是我拦截原进程的WM_LBUTTONDOWN或WM_LBUTTONUP消息中的时候调用我的ReadData函数并把读到的值存在dValue，但是发现dValue并不一定每次都能获取到读取的值，假如注册表中的那个键值就是1，dValue获取到的有时是0有时是1，只是特别让人费解的地方，迫于无奈我只能把ReadData函数这样放，如下：

 1 LRESULT CALLBACK MyProc(HWND hwnd,UINT msg,WPARAM wParam,LPARAM lParam)
 2 {
 3     ReadData();          //只能在这里读才能保证稳定能dValue能获取到键值并保存
 4     switch(msg)
 5       {
 6          case WM_LBUTTONDOWM:
 7          break;
 8 
 9          case WM_LBUTTONUP:
10          break;
11          
12          case default:
13          CallWindowProc(OldWndProc,hwnd,msg, wParam, lParam);
14       }
15     return TRUE;
16 }

      不大清楚为什么会这样子，我尝试过在WM_LBUTTONUP中调用ReadData之前先调用一个MessageBox，弹出的对话框要等单击确定之后才去执行ReadData函数，这样的话也能保证读取到的键值保存在dValue中，我想是否因为窗口受到WM_LBUTTONUP会很快收到其他注入WM_MOUSEMOVE之类的消息，所以ReadData还没有处理完线程就跳到了WM_MOUSEMOVE消息处理中，但是为什么把ReadData放在消息处理函数之外就能有充足的时间去执行完这个函数？有待研究。

      在这次的修改BUG中，有点体会。写程序一定要冷静的分析问题，时刻保持思绪清晰。碰到问题了，首先要从大的方面去检测问题的所在，然后一步一步的把范围收缩，最终确定问题的根源所在。程序出问题了，一般把程序减缩成只有一个大概的框架进行测试，没问题了再向原来的这个框架搭建其他程序再测试，如此不断搭建不断测试，最终就容易找到问题的根源。