关于9879的Explorer（任务栏、资源管理器）出现渲染问题、崩溃的原因之一

依文

自从Win10 9879发布后就有不少人在论坛反映Win10的任务栏或资源管理器总是崩溃或出现渲染问题

但由于我一直无法在虚拟机里重现这个问题，曾经怀疑是显卡驱动导致，直到最近有人提到用Potplayer播放视频可以重现问题，我在虚拟机里使用Potplayer确实可以重现问题，终于给了我一个分析问题的机会。

当我使用Potplayer播放视频的时候，可以通过Process Explorer或者任务管理器看到explorer.exe进程的GDI对象数量正在以大约每秒4个对象的速度发生GDI对象泄漏，算上explorer.exe本身消耗的GDI对象数量，预计30分钟后就会达到10000的极限值，当到达这个极限值的时候，就会出现大家所看到的开始菜单、任务栏、文件管理器的渲染错误，甚至崩溃。下图是使用用Potplayer播放视频超过30分钟的表现：



稍微思考分析一下后，我认为是Potplayer在任务栏显示的进度条触发泄漏的，事实上之后我通过关闭Potplayer的任务栏功能以及用MPC HC播放器（这个触发的泄漏速度慢很多）以及用IE下载文件证实了我的想法。

不过这还不足够证明，因此我自己编写了一个小程序实现在任务栏显示进度条，并且设定30分钟才能填充满，以此来进一步测试。奇怪的是，我写的测试程序无法触发GDI对象泄漏发生，一切正常。开始以为是我搞错原因了，但我从网上找了一个别人编写的示例程序（比我的复杂很多）却成功触发了explorer GDI对象泄漏。该程序也是一个纯粹的任务栏进度条示例程序，而且跟我的一样使用WPF + C#编写，究竟是什么区别导致我的不能触发泄漏，实在懒得深究了，本来做这种任务栏进度条的程序我还是第一次做，有兴趣的可以自行深入研究（该程序是开源的，等下我会提供地址）。

该程序界面如下图所示，程序默认倒计时25分钟，不过这个程序触发的泄漏速度比Potplayer慢很多，大概需要1个小时多点的时间（一个文件夹窗口都不打开的话）才能让explorer.exe的GDI对象数量达到10000，如果你想用这个程序测试，请将时间设置为1小时。





测试程序从附件下载 Countdown Timer.zip (258.83 KB, 下载次数: 4)

2014-11-20 15:13 上传

下载次数: 4
下载积分: PB币 -1
请勿使用多线程下载工具下载论坛附件！

，源代码请到这里下载：http://www.codeproject.com/Articles/330073/A-WPF-MVVM-Countdown-Timer

目前只能确认任务栏进度条是触发explorer.exe发生GDI对象泄漏的原因之一，至于还有没有其他原因很难说，不过现在有这么多信息，只要让微软知道的话，微软排查问题也很容易了，希望能直接反馈到微软总部吧。

----------------------------------------------------------------------------------------------------------------
更新：
我编写的6分钟内让explorer.exe的GDI对象数量泄漏到10000的测试程序：

经过一些研究，最终还是自己重新编写了一个测试程序，这次编写的程序保证在6分钟内（如果你有打开一个或多个文件夹窗口会更快）让explorer.exe的GDI对象数量泄漏到10000，从而使explorer（任务栏、资源管理器）出现渲染错误。有兴趣的可以下载测试： Taskbar Progressbar Test.zip (222.94 KB, 下载次数: 22)

2014-11-22 10:41 上传

下载次数: 22
下载积分: PB币 -1
请勿使用多线程下载工具下载论坛附件！

byyxx126

沙发！支持！

wuwei334455

支持。已经反映很久了。没有反应。

raymai97

所以任务栏进度条是主因

slitaz

wow高手现身了，这个问题微软倒是估计可以很快搞定

yhr31580

感谢楼主
在hyper-v中安装企业版9879，
使用测试程序40分钟可重现，
而且需关机后重启才能恢复。

一间坊

上午经过测试，IE下载速度超过（接近）1000K/秒，就崩溃。

依文

yhr31580 发表于 2014-11-20 20:54
感谢楼主
在hyper-v中安装企业版9879，
使用测试程序40分钟可重现，

其实不用重启的，用任务管理器重新启动explorer进程就可以恢复了。

qbit

不错的发现，微软应该奖励楼主。

依文

一间坊 发表于 2014-11-20 21:03
上午经过测试，IE下载速度超过（接近）1000K/秒，就崩溃。

IE下载的时候也会在任务栏显示进度条，我也测试过确认会触发explorer.exe产生泄漏，但要让explorer达到GDI对象限制从而出问题，一般来说应该需要下载一个大文件慢慢耗时间。

你的莫非是下载速度很快的话，就可以快速触发explorer崩溃？你是用了多少分钟让它崩溃的？建议再试一次，并打开任务管理器，像我第一张截图那样显示“GDI对象”的列，然后观察explorer的GDI数量是不是以超快的速度增长。

一间坊

两次下载，都是近2G的文件，在4-5分钟时开始逐渐显现，1-2分钟就右键不显示了。
https://bbs.pcbeta.com/viewthread-1561158-1-1.html

一间坊

依文 发表于 2014-11-20 21:46
IE下载的时候也会在任务栏显示进度条，我也测试过确认会触发explorer.exe产生泄漏，但要让explorer达到GD ...

可是用第三方下载程序，8M/秒，连续5个小时都没有这个现象。
经常下载大量文件，今天出于好奇想试试IE的下载速度，发现了。

依文

一间坊 发表于 2014-11-20 22:02
可是用第三方下载程序，8M/秒，连续5个小时都没有这个现象。
经常下载大量文件，今天出于好奇想试试IE的 ...

你用IE多试一次，按我上面说的，打开任务管理器观察explorer进程的GDI对象数量的增长速度是不是超快，用Potplayer都只能以大约每秒4个GDI对象的速度递增，你这个估计会涨得很快。

一间坊

Mouri_Naruto

今天准备去小鸟去feedback

rubycon

怪不得播放视频，很容易造成 Explorer 崩溃。

依文

一间坊 发表于 2014-11-21 01:13

有点奇怪，不过我始终认为与磁盘读写无关（有很多例子可以否定磁盘读写因素），问题应该还是在任务栏的进度条身上。

原本实现任务栏进度条的关键API 函数SetProgressValue是要开发者分别填充当前完成进度量以及进度的最大总值来实现的，简单来说，如果要显示一个下载文件的进度的话，只需在调用这个函数的时候填入当前下载的字节数值以及文件的总字节数值就可以了，然后函数会自动计算并显示相应的进度。

问题可能就在于这里了，我猜想总数值越大，并且当前完成的进度的数值的增长速度越快，所产生的GDI对象的泄漏速度就越快。

由于我使用C#所编写的代码，调用的函数（方法）是经过微软封装处理过的，我所能调用的函数（方法）是直接指定进度条的进度数值（比如直接填入数值0.5表示50%的进度），而不是像原始的SetProgressValue函数那样要填入2个数值让它计算显示，所以我无法用C#编码验证，如果有熟悉Win32 C++编程的人验证的话就好了。

benyulong002

楼主大神啊！！

依文

benyulong002 发表于 2014-11-21 12:10
楼主大神啊！！

我水平很差的，不敢当。。。

zgp031120

我的也是发生在视频播放将近一小时的时候。希望巨硬及时修复！！！