我在wpf应用程序中遇到问题,渲染线程停止渲染,但UI线程和帮助程序线程仍在处理消息。
它似乎与演示字体缓存的损坏有关,但这似乎不太可能,因为应用程序在重新启动时恢复正常。
渲染线程偶尔会挂起,阻止绘图更新,但UI线程仍然在传递消息。
我们看到类似的问题(类似于here)在将缩放变换应用于通过删除字体缓存解决的文本块时发生,但是这个特殊问题不能可靠地重复。
诊断此问题根本原因的最佳方法是什么?
我在connect打开了一个微软的错误,但除非其他人投票,否则不会考虑。
答案 0 :(得分:5)
冻结是由托管的activex控件呈现视频引起的。
控件使用directshow的方式存在竞争条件,导致directx挂起。
我们通过使用procdump进行进程转储然后在窗口debugger中打开转储文件来发现此问题。
在net上进行搜索并检查本机调用堆栈会显示一个问题,即关键段指针的高位字节为零,这意味着其中一个线程正在等待一个不存在的临界区永远不会发出信号。
这允许我们通过执行启动和停止视频的代码来创建可重复的挂起。我们删除了控件,挂起就停止了。
答案 1 :(得分:1)
我不知道为什么会这样,但我以前经历过。在面向框架4.0并在旧机器(XP,Vista)上运行的系统中观察它会更容易。
我要解决的是:
解决方案1在一台XP机器上运行。它也适用于Vista机器,但过了一段时间后问题又出现了。
要删除FontCache3.0.0.0.dat,您需要先停止“Windows Presentation Foundation字体缓存3.0.0.0”服务,然后才能删除该文件。在Vista中,它位于c:\ windows \ serviceprofiles \ localservice \ appdata \ local下。在XP中,它位于c:\ windows \ system32 \ documents和settings \ localservice \ local settings \ application data(我可能拼错了一些文件夹)
我还发现完全禁用系统(解决方案2)并不会影响我的.net应用程序的性能。
答案 2 :(得分:1)
找到问题的根本原因的唯一方法是从线程开始不断记录,直到找到它挂起的原因。我可以建议很多方法来进行日志记录,但这取决于渲染线程中代码的复杂程度。如果没有大量的调试信息(引入足够的延迟以暂时解决问题的那种事情,那么你就无法向下钻取到它确实发生的那一次。
如果您可以在VS中重复它,那么您应该使用一些控制台记录预期的故障部分,否则您可能不得不将其拉入文本文件,或将其发送到系统记录器。
你可以让它在一个简单的应用程序中重现,该应用程序只执行应用程序其余部分的呈现和相关部分,或者只在完整程序中发生(只能发生?)?
答案 3 :(得分:0)
您可以使用监视程序服务,在服务检测到问题时清除缓存。每当您的应用程序运行时,该服务都必须定期轮询。
我将是第一个承认这是次优解决方案的人,除非你能够在很短的时间内打开和关闭服务,否则很可能会很快耗尽电池。
答案 4 :(得分:0)
我认为你必须使用循环轮询,不断检查软件是否正在运行,并在软件挂起时重置它。