一、基本原理
使用SendMessage函数发送TB_BUTTONCOUNT消息到指定窗口，可以检索工具栏中当前按钮的计数。但这个值可能并不是最新的，个数仅仅是当前个数，而且并非是显示的个数，也非有效按钮窗口的个数。
使用SendMessage函数发送TB_GETBUTTON消息到指定窗口获取指针，然后向指定进程申请访问内存，获取TBBUTTON结构体中dwData字段数据，可以获得远线程的工具栏窗口中当前所有按钮的句柄、标题、进程路径信息。但该信息可能包含旧的内容。
任务栏的通知区域分为四个部分：用户提示的通知区域、系统升级的通知区域，溢出角通知区域、DUI弹出式通知区域（部分图标如：电源电量、音量等的注册记录在溢出通知区域窗口，但是并不是在溢出窗口内显示的，所以单独归类）。通知区域是外壳处理器Shell控件：ToolBarWindow32.
首先我们需要明白任务栏的ToolBarWindow(工具栏视图)的一些特征：
1）除系统升级的通知区域以外的通知区域图标不会自动刷新，需要接收到鼠标移动消息、模拟点击消息才会逐个刷新。
2）如果一个窗口多次在通知区域注册通知图标，即使它是由同一个窗口发出的，也会被记录为独立的窗口，但他们具有相同的信息，在外壳程序内存中相应位置按序排列。
二、案例如何发生？
当开发者尝试使用如下代码获取任务栏图标个数时可能得不到准确的个数：
LRESULT ButtonCount = SendMessage(hWnd, TB_BUTTONCOUNT, 0, 0);// 获取hWnd窗口的图标个数警告：以下谈到的案例并不局限于任务管理器，其他第三方软件都如此，这和资源管理器外壳Shell的处理逻辑有关系。
误区1：忽略系统升级的通知区域，尽管这个区域经常没有显示，但它位于溢出角按钮和用户通知区之间，当有程序首次创建通知区图标的时候，提供短暂突出显示的时间，这些图标临时显示在该区域，不在用户区和溢出区，当超时完成时（最长60秒）这些图标被放入溢出区（前提是没有被标记为始终显示）。在超时完成前通知统计的用户区和溢出区图标数据中跳过了这些图标。
误区2：忽略重复注册的图标窗口，尽管这在我们看来是相当荒诞的，但它确实发生过，也应该引起相关开发者的注意。
这张图片展示了当任务管理器打开时（等待超时完成后记录的结果），在使用TB_BUTTONCOUNT获取个数时将多次记录到任务管理器窗口，显示为他创建了13个图标按钮，随后通过在外壳进程内存中读取TBBUTTON结构中的dwData数据，得到窗口的标题、句柄、以及目录路径（类名、矩形等其他信息是根据窗口句柄通过相关API遍历枚举的，不是直接获得的结果），不难发现同样的句柄有多条记录，然而我们不需要多余的信息。这是TB类消息得到错误结果的重要原因。
误区3：（对于误区2而言）任务管理器等刚刚注册通知图标的窗口，图标会显示在系统升级通知区，此时记录的个数是真确的（唯一的）。因为他只要接收消息了，就会被移除到溢出区。否则他只允许静默一段时间。
误区4：线程异常退出，而没有注销相应图标。这时候我们把它称作僵尸图标，空有躯壳而没有灵魂。但是这段内存区域中相关信息不会被立即清除。导致获得的计数以及句柄都是无效的。
通过检查窗口的矩形，API调用返回“Error：1400”无效的窗口句柄即可排除该错误带来的影响。
Notice：请观察下图数据
再看下图数据：
以上结果发生在一个已经注册通知图标的程序意外终止时（没有来得及注销图标），外壳程序内存中不会及时删除这些内容，这些内容可能位于错误的内存位置，访问这些位置会带来意外的结果。即使用户已经刷新了视图区域，这些内容依然不会被清除，直到重启资源管理器。
并且对无效的句柄使用GetClassName()返回值为0，但是不会向遍历时候的字符串指针更新数据，所以需要注意变量的作用域或者记得及时检查错误原因，比如此时的LastError为1400，以及最后要记得将内容重新初始化为{0}。一面这些垃圾数据影响用户体验。（显然图中没有考虑到这些问题）
-----------------------------------------------
希望通过我的分析，能够给遇到相关问题的友人一点微薄的解答。文章如果有误，欢迎各位斧正，谢谢！
转载请注明博客来源：@涟幽516（http://t.csdn.cn/CpBeJ）
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
