WPF 调度程序 - 突然出现 "stuck"并且在按下某个键之前不处理操作

Question

我们的 WPF 应用程序遇到了一个非常奇怪的问题。

启动时我们的应用程序会触发一些服务请求。然后，当窗口加载时，它没有响应，直到我们按下某个键。 CPU 使用率为 0%。

它看起来像 UI 死锁，尽管不是真正的死锁 - 我们可以调整它的大小并移动它。连接调试器时，我们看到主线程位于 Win32.UnsafeNativeMethods.GetMessageW 上 - 它没有像您通常在此类问题中看到的那样等待锁定。

然后，如果我们按下某个键，它会继续处理我们传递给 Dispatcher.BeginInvoke 的操作。

这种情况在调试和发布版本上都会发生，但仅当它是由 MSBuild 工具构建时才会发生。如果我在 PC 上的 VS2010 和 VS2012 中构建应用程序(均针对 .NET 4.0)，则问题永远不会发生。

关于如何确定在按下某个键之前阻止调度程序执行操作的任何想法？

问候。

P.S - 请参阅下面的 UI 线程堆栈跟踪。

WindowsBase.dll!MS.Win32.UnsafeNativeMethods.GetMessageW(ref System.Windows.Interop.MSG msg, System.Runtime.InteropServices.HandleRef hWnd, int uMsgFilterMin, int uMsgFilterMax) + 0x14 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.GetMessage(ref System.Windows.Interop.MSG msg, System.IntPtr hwnd, int minMessage, int maxMessage) + 0x80 bytes WindowsBase.dll!System.Windows.Threading.Dispatcher.PushFrameImpl(System.Windows.Threading.DispatcherFrame frame) + 0x75 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.PushFrame(System.Windows.Threading.DispatcherFrame frame) + 0x49 bytes
WindowsBase.dll!System.Windows.Threading.Dispatcher.Run() + 0x4b bytes
PresentationFramework.dll!System.Windows.Application.RunDispatcher(object ignore) + 0x17 bytes
PresentationFramework.dll!System.Windows.Application.RunInternal(System.Windows.Window window) + 0x6f bytes PresentationFramework.dll!System.Windows.Application.Run(System.Windows.Window window) + 0x26 bytes PresentationFramework.dll!System.Windows.Application.Run() + 0x1b bytes MyApp.App.Main() Line 50 + 0xa bytes

Answer 1

这个可能性不大，但是可能是由于 .Net 4.0 中可能存在的错误(已在 .Net 4.5 中修复)造成的。您是否在 Jenkins 构建机器上进行测试并进行编译？

我曾经遇到过一些发生类似问题的事件(所有内容都可以在开发机和构建机上编译，但测试机上的核心框架中会发生运行时异常，而开发机上不会发生)。

在这些情况下，问题的根源在于，虽然以 .Net 4.0 为目标，但在安装 .Net 4.5/4.5.1(作为 VS2012 的一部分)时，.Net 4.0 的程序集会被覆盖，因此，虽然源代码是相同的，行为已经改变，因此，在装有 VS2012 的机器上一切似乎都正常，但在仅装有 VS2010 和/或仅 .Net 4.0 的机器上则不然。

建议，尝试使用 VS2012 进行构建(仍然针对 .Net 4.0)，然后在仅安装 .Net 4.0 的计算机上运行输出应用程序，然后在安装了 .Net 4.5 的计算机上运行输出应用程序。如果在 .Net 4.5 计算机上一切正常，但在 .Net 4.0 计算机上一切正常，则这可能是问题所在。

正如我所说，这是一次黑暗中的尝试，那里可能存在真正的程序问题，但值得将其作为一个起点。

当然，如果允许您在应用程序中安装 .Net 4.5，那么这当然没问题。如果没有，您可能必须找到解决该问题的编程方法。