c# - .NET 4.0 和可怕的 OnUserPreferenceChanged 挂起

Question

我一直被可怕的 OnUserPreferenceChanged Hang 所困扰，Ivan Krivyakov 在这里很好地提到了它:

http://ikriv.com/en/prog/info/dotnet/MysteriousHang.html#BeginInvokeDance

前阵子发帖提问，当初遇到问题的时候:

Yet another C# Deadlock Debugging Question

我以为我已经通过删除一个从 UI 线程构建的控件来解决它，但过了一会儿它又出现了(可能永远不会离开......)。

我们一直在使用 .NET 3.5，据我所知，它使用 CLR 2.0。最近，应用程序已升级为使用 .NET 4.0 Client Profile/CLR 4.0。此外，我们已经从 Infragistics WinForms 10.1 升级到 10.3。唯一的区别是之前的版本被混淆了......有人遇到过混淆和挂起的问题吗？

我曾尝试一劳永逸地摆脱任何应用程序挂起，但不寻常的是，我无法在最新版本(使用 .NET 4.0)中重现挂起。在以前的版本(使用 .NET 3.5)中，使用 Ivan Krivyakov 方便的 Freezer 应用程序(请参阅他的文章)很容易重现该挂起，该应用程序会根据请求触发 WM_SETTINGCHANGE 消息。

我可能有点希望这个问题已经自动消失了，但是有人知道 CLR 从 2.0 到 4.0 是否有任何变化会导致这个问题吗？

-------------------------------------------- - - - - -解决方案 - - - - - - - - - - - - - - - - - - - - ----------

所以在测试应用程序的变体之后，例如CLR 2.0 + Infragistics 2010.1、CLR 2.0 + Infragistics 2010.3 和 CLR 4.0 + Infragistics 2010.1，我们相信我们已经确定问题是 WinForms 2010.1 中的 Infragistics 组件的问题(无热修复)。我们仍然没有使用 CLR 2.0 或 CLR 4.0 和 Infragistics 2010.3 来重现卡住(我们现在已经非常擅长重现这个......)。

Answer 1

a Control that was constructed off the UI thread...

是的，这是触发此问题的好方法。根本问题是由 SystemEvents 类引起的，它具有在正确线程上引发事件的艰巨任务。 UserPreferenceChanged 事件是典型的麻烦制造者，许多控件都订阅它，以便在用户更改桌面主题时它们可以重新绘制自己。组件供应商不会忽视对此的需求。工具箱中的标准 .NET 框架控件也没有。

测试此问题的一种通常不错的方法是锁定工作站(按 Win+L 键)，这也是在用户计算机上通常触发死锁的方法。切换到安全桌面往往会触发事件。额外的怪癖是，当你调试你的程序时，这永远不会发生，而且它有棘手的与时间相关的行为，因为这往往发生在没有人在机器旁的时候。特别难调试。

像这样陷入麻烦的一种标准方法是因为程序中的初始化问题。订阅的第一个 SystemEvents 事件会导致 SystemEvents 类自行初始化并设置接收这些通知和引发相应事件所需的管道。一个自定义启动画面做太多(即不仅仅是显示位图)并在标记为 STA 的工作线程上运行就足以让这个错误。像 ProgressBar 这样简单的东西就足够了。 SystemEvents 假设工作线程是程序的主线程，现在可以很容易地在未来的错误线程上生成事件。对此有一个很好的诊断，如果该工作线程不再存在，则会生成第一次机会异常。您可以在“输出”窗口中看到它。

或者您创建另一个 UI 线程并在两个线程上都有表单。不可避免地，其中一种形式总是会在错误的线程上获取事件。

唯一体面的建议是承认在工作线程上创建 UI 是火箭科学，而 Microsoft 也不知道如何正确地做到这一点。值得注意的是 .NET 1.x 控件有一个事件处理程序，当它被错误的线程调用时仍然可以正常工作，它只是调用 Control.Invalidate()。但这是在 2.0 中似乎已经丢失的知识，ToolStrip 是一个 good example。 .并且不要相信组件供应商能够做到这一点，尤其是 Infragistics 并没有很好的声誉。不要这样做。