WPF 渲染线程挂起
我在 wpf 应用程序中遇到一个问题，渲染线程停止渲染，但 UI 线程和辅助线程仍在泵送消息。
它似乎与演示字体缓存的损坏有关，但这似乎不太可能，因为应用程序在重新启动后恢复良好。
渲染线程偶尔会挂起，从而阻止绘图更新，但 UI 线程仍在泵送消息。
我们在应用缩放变换时发现了类似的问题（类似于此处）到通过删除字体缓存解决的文本块，但是这个特定问题不能可靠地重复。
诊断此问题根本原因的最佳方法是什么？
我已在 连接，但除非其他人投票赞成，否则不会考虑。
I'm experiencing a problem in a wpf app where the render thread stops rendering, but the UI thread and helper threads are still pumping messages.
It appears to be related to the corruption of the presentation font cache, however this seems unlikely, as the app recovers fine on reboot.
The render thread will occasionally hang, preventing drawing updates, but the UI thread is still pumping messages.
We have seen a similar issue (similar to here) that occured when applying a scale transform to a textblock that was solved by deleting the font cache, however this particular problem is not reliably repeatable.
What is the best way to diagnose the root cause of this problem?
I have open a bug with microsoft at connect, but it will not be considered unless others vote it up.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
冻结是由托管的 ActiveX 控件渲染视频引起的。
控件使用 directshow 的方式存在竞争条件，导致 directx 挂起。
我们通过使用 procdump 进行进程转储然后打开转储文件发现了此问题在 Windows 调试器中。
在网络上搜寻< /a> 并检查本机调用堆栈显示了一个问题，即关键部分指针的高位字节被清零，这意味着其中一个线程正在等待一个不存在的关键部分，而该关键部分永远无法发出信号。
这使我们能够通过执行启动和停止视频的代码来创建可重复的挂起。我们移除了控制装置，悬挂停止了。
The freeze was caused by a hosted activex control rendering video.
There was a race condition in the way the control used directshow which caused directx to hang.
We found this problem by taking a process dump using procdump and then opening the dump file in the windows debugger.
Hunting around on the net and inspecting the native callstacks showed a problem where the high order byte of a critical section pointer was zeroed, which meant that one of the threads was waiting on a non-existent critical section which can never be signaled.
This allowed us to create a repeatable hang by exercising the code that started and stoped the video. We removed the controls, and the hang stopped.
我不知道为什么会这样，但我以前经历过。在针对框架 4.0 并在旧机器（XP、Vista）上运行的系统中更容易观察到它。
我要解决的问题是：
解决方案 1 在一台 XP 机器上工作。它在 Vista 机器上也可以工作，但过了一段时间问题又出现了。
要删除 FontCache3.0.0.0.dat，您需要先停止“Windows Presentation Foundation Font Cache 3.0.0.0”服务，然后才能删除该文件。在 Vista 中，它位于 c:\windows\serviceprofiles\localservice\appdata\local 下。在 XP 中，它位于 c:\windows\system32\documents and settings\localservice\local settings\application data 下（我可能拼错了某些文件夹）
我还发现完全禁用系统（解决方案 2）不会影响性能我的 .net 应用程序。
I don't know why it happens, but I have experienced it before. It's easier to observe it in systems that target framework 4.0 and run on older machines (XP, Vista).
What I did to solve was:
Solution 1 worked in one XP machine. It also worked in a Vista machine, but after a while the problem showed up again.
To delete FontCache3.0.0.0.dat you will need to stop the "Windows Presentation Foundation Font Cache 3.0.0.0" service before you can delete that file. In Vista it is located under c:\windows\serviceprofiles\localservice\appdata\local. In XP it is under c:\windows\system32\documents and settings\localservice\local settings\application data (I might have mispelled some folder)
I have also found that disabling the system altogether (solution 2) did not affect the performance of my .net apps.
找到问题根本原因的唯一方法是从线程中不断记录日志，直到找到它挂起的原因。我可以建议很多方法来进行日志记录，但这取决于渲染线程中代码的复杂程度。如果没有大量的调试信息（这种信息会引入足够的延迟来暂时解决问题，至少），您将无法深入了解问题确实发生的时间。
如果您可以在 VS 中重复它，那么您应该在预期的问题部分周围使用一些控制台日志记录，否则您可能必须将其拉入文本文件，或将其发送到系统记录器。
您能否让它在一个简单的应用程序中重新出现，该应用程序仅执行应用程序其余部分的渲染和相关部分，或者它仅发生（只能发生？）在完整的程序中？
The only way to find the root cause of the issue is going to be constant logging from the thread until you can find a reason why it hangs. I can suggest lots of ways to do that logging, but it depends on how complex that code in the render thread is. Without having lots of debugging information (the sort of thing that introduces enough latency to temporarily resolve the problem, no less) you're not going to be able to drill down to the one time where it does occur.
If you can repeat it in VS, then you should use some console logging around the anticipated trouble parts, otherwise you're likely going to have to pull it into a textfile, or send it to the system logger.
Can you get it to reoccur in a simple app that only does the rendering and related parts of the rest of the app, or does it only occur (can only occur?) in the full program?
您可以使用看门狗服务，在服务检测到问题时清除缓存。只要您的应用程序运行，该服务就必须定期轮询。
我将第一个承认这是一个次优的解决方案，除非您能够仅在一小部分时间内打开和关闭服务，否则您可能会很快耗尽电池电量。
You could use a watchdog service that clears the cache when the service detects the issue. The service would have to poll on a periodic basis whenever your application is running.
I will be the first to admit that this is a sub-optimal solution and, unless you are able to flip the service on and off for only small slices of time, you are likely to drain batteries rather quickly.
我认为您必须使用循环轮询，它会不断检查软件是否正在运行，并在软件挂起时重置它。
I think you must use a looping poll which continuously checks if the software is running and resets it whenever the software hangs.