1
所以 window tray 的这个 bug，从 win95 一直延续到 win11？
source link: https://www.v2ex.com/t/831205
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
一个在 tray 里面的程序，如果被 kill 掉没有 gracefully 退出，那么就会一直残留在 tray
喵喵喵？？？ M$觉得这个是个 feature 么？？？？
18 条回复 • 2022-01-30 02:57:27 +08:00
moen 1 天前 
3
严格上说这是机制的问题，不算 bug 。Notification icon 的创建和删除都是由应用程序自己 Push 给 explorer.exe ，但 explorer.exe 方面并没有设计一套 Pull 机制来主动了解 notification icon 所属的进程是否存在。所以进程崩溃了没法自行删除，就一直显示在那里了。而 explorer.exe 崩溃后 notification icon 不会重建也是因为这套机制导致的
至于为什么一直不加我不知道
至于为什么一直不加我不知道
kkocdko 1 天前 via Android
@moen 但是鼠标移上去就消失了，我对 windows 开发不熟悉，推测这大概是 mouseover ，然后向应用请求获得 tooltips ，结果发现没有回应，就知道应用推出了。
那为什么不能隔一段时间轮询呢？难道是历史遗留问题，怕某些应用获取一次 tooltips 要花很多时间？或者某些应用依赖这种行为？
那为什么不能隔一段时间轮询呢？难道是历史遗留问题，怕某些应用获取一次 tooltips 要花很多时间？或者某些应用依赖这种行为？
geelaw 1 天前 9
首先，那个东西叫“通知区域”，不叫 tray 。即使你认为 tray 来自于早期代码里的命名，tray 也是指整个任务栏。
这个问题的成因是通知区域图标是程序通知任务栏创建的，崩溃时程序没有通知删除，所以不会立刻消失。
鼠标放上去会消失是因为 Explorer 会给图标对应的窗口发消息，如果窗口句柄已经无效，则会删除图标——注意窗口句柄是 USER 句柄，因此既没有计数也会复用，在极限情况下可能新程序被分配到已经崩溃程序使用过的句柄，导致新程序莫名其妙收到消息。
Explorer 崩溃重启后程序需要重新添加图标，获取这一信息的方法是注册“任务栏创建好了”消息。
为什么不能轮询——因为不存在一个“心跳”消息，也不应该随便给窗口发送消息（虽然理论上可以注册一个新名字，这样任意窗口都不会对该消息有特殊反应才对），也不应该轮询（性能问题）。
这个问题显然是可以解决的，比如任务栏上列举窗口的按钮可以对崩溃立刻作出反应，这个变化是 USER 监控，并发送 WM_SHELL_* 消息给任务栏的。然而通知区域图标并不是 USER 概念而是 shell 概念（只存在于 explorer.exe 进程中），虽然可以提升到 USER 概念实现之，估计是不值得吧（ USER 是 per-session 级别的，可以容纳的句柄数量也相当有限）。
更好的解决方法是——不要崩溃。
类似的问题也存在于 Application Desktop Toolbar 。还有更多设计 bug 导致 shell 的一些部分需要两次操作才能刷新（ COM categories 、shellnew 等）。
这个问题的成因是通知区域图标是程序通知任务栏创建的，崩溃时程序没有通知删除，所以不会立刻消失。
鼠标放上去会消失是因为 Explorer 会给图标对应的窗口发消息，如果窗口句柄已经无效，则会删除图标——注意窗口句柄是 USER 句柄，因此既没有计数也会复用，在极限情况下可能新程序被分配到已经崩溃程序使用过的句柄，导致新程序莫名其妙收到消息。
Explorer 崩溃重启后程序需要重新添加图标，获取这一信息的方法是注册“任务栏创建好了”消息。
为什么不能轮询——因为不存在一个“心跳”消息，也不应该随便给窗口发送消息（虽然理论上可以注册一个新名字，这样任意窗口都不会对该消息有特殊反应才对），也不应该轮询（性能问题）。
这个问题显然是可以解决的，比如任务栏上列举窗口的按钮可以对崩溃立刻作出反应，这个变化是 USER 监控，并发送 WM_SHELL_* 消息给任务栏的。然而通知区域图标并不是 USER 概念而是 shell 概念（只存在于 explorer.exe 进程中），虽然可以提升到 USER 概念实现之，估计是不值得吧（ USER 是 per-session 级别的，可以容纳的句柄数量也相当有限）。
更好的解决方法是——不要崩溃。
类似的问题也存在于 Application Desktop Toolbar 。还有更多设计 bug 导致 shell 的一些部分需要两次操作才能刷新（ COM categories 、shellnew 等）。
yulon 1 天前
进程创建销毁的事件依赖内核态，所以内核资源比如文件网络都可以自动释放，你要监控就得写个驱动。
GUI 资源一般是用户态的窗口消息管理的，他就是逼你正确处理窗口消息，不要越过 GUI 直接终止进程。
既然已经有事件的方法了，再加个轮询就显得有点脏，当然这都是设计问题，人家就是这么规定的。
GUI 资源一般是用户态的窗口消息管理的，他就是逼你正确处理窗口消息，不要越过 GUI 直接终止进程。
既然已经有事件的方法了，再加个轮询就显得有点脏，当然这都是设计问题，人家就是这么规定的。
ysc3839 1 天前
@geelaw 一种可行的方案是检测窗口对应的进程，这样不需要轮询，也不会有复用问题，缺点是没法解决进程没退出，窗口关闭但忘记删除 notification icon 的情况。
geelaw 1 天前 via iPhone
@ysc3839 #7 这是不行的，因为通知区域图标关联的窗口可能是高权限进程（或者另一个非管理员用户的进程），窗口消息仍然可以送达（ Explorer 有 UIAccess ），但 Explorer 无权访问该进程。此外关联窗口可以变更，要恰当实现等待进程结束还是挺复杂的（需要用 WaitForMultipleObjects 技巧）。
imn1 1 天前
dandycheung 21 小时 53 分钟前 via Android
@geelaw 没有查资料，凭记忆瞎聊两句。1. 通知区域自从出现就是叫 tray ，当时翻译过来多数译作“托盘”。2. 用 TaskbarCreated 字符串注册出来是消息是后加的，不是一开始就有。3. 不要崩溃结局不了所有问题，有时候是被别人杀死的。4. 还有，有一个 Windows 消息，叫 WM_NULL ，似乎真需要的话，可以废物利用一下。
LxnChan 19 小时 56 分钟前
@imn1 俺也一样
@kkocdko 这个应该就是刻意没有做轮询，本身删除托盘图标的操作就是应该由程序本身发起而不是系统去做，一是性能问题二是万一当前 explorer 没有权限访问该程序（也可能是服务）就误以为该程序已经关闭甚至 explorer 直接崩溃
@CallMeReznov 草哈哈哈
@kkocdko 这个应该就是刻意没有做轮询，本身删除托盘图标的操作就是应该由程序本身发起而不是系统去做，一是性能问题二是万一当前 explorer 没有权限访问该程序（也可能是服务）就误以为该程序已经关闭甚至 explorer 直接崩溃
@CallMeReznov 草哈哈哈
ysc3839 14 小时 8 分钟前 via Android
@geelaw 印象中 OpenProcess SYNCHRONIZE 好像不受权限限制吧？关联窗口变更后监视新窗口对应的进程就行了。
@imn1 我没明白这是什么问题。
@dandycheung 你的说法是错的，自从出现就是 Shell Notify Icon 。这篇文章 https://devblogs.microsoft.com/oldnewthing/20030910-00/?p=42583 也给出了一些理由。
@imn1 我没明白这是什么问题。
@dandycheung 你的说法是错的，自从出现就是 Shell Notify Icon 。这篇文章 https://devblogs.microsoft.com/oldnewthing/20030910-00/?p=42583 也给出了一些理由。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK