Windows窗体应用程序在过夜运行时随机冻结

Question

我有一个窗体窗体应用程序，它有多个线程在主UI线程上调用以更新UI。偶尔在开发机器上，应用程序主UI线程将停止运行，应用程序不再响应。如果我让应用程序在一夜之间运行，似乎就会发生。但是，我有通过远程桌面运行此窗口窗体应用程序的用户，如果应用程序在没有用户交互的情况下在一夜之间运行，则会出现此问题。

我发现article似乎在描述这个问题，但我没有足够的Windows开发知识来弄清楚为什么应用程序会冻结。

我得到的唯一信息是以下堆栈跟踪，指示主UI线程正在等待某种操作。

这个问题一直困扰着我很长一段时间了。我将不胜感激任何建议或意见。

谢谢！

 
Main UI thread stack trace: 

mscorlib.dll!System.Threading.WaitHandle.WaitOne(long timeout, bool exitContext) + 0x2f bytes 
mscorlib.dll!System.Threading.WaitHandle.WaitOne(int millisecondsTimeout, bool exitContext) + 0x25 bytes 
System.Windows.Forms.dll!System.Windows.Forms.Control.WaitForWaitHandle(System.Threading.WaitHandle waitHandle = {System.Threading.ManualResetEvent}) Line 4268 C# 
System.Windows.Forms.dll!System.Windows.Forms.Control.MarshaledInvoke(System.Windows.Forms.Control caller, System.Delegate method, object[] args, bool synchronous) Line 7614 C# 
System.Windows.Forms.dll!System.Windows.Forms.Control.Invoke(System.Delegate method, object[] args) Line 7178 + 0x11 bytes C# 
System.Windows.Forms.dll!System.Windows.Forms.WindowsFormsSynchronizationContext.Send(System.Threading.SendOrPostCallback d, object state) Line 89 C# 
System.dll!Microsoft.Win32.SystemEvents.SystemEventInvokeInfo.Invoke(bool checkFinalization = true, object[] args = {object[2]}) + 0x62 bytes 
System.dll!Microsoft.Win32.SystemEvents.RaiseEvent(bool checkFinalization = true, object key = {object}, object[] args = {object[2]}) + 0x10f bytes 
System.dll!Microsoft.Win32.SystemEvents.OnUserPreferenceChanging(int msg, System.IntPtr wParam, System.IntPtr lParam) + 0x77 bytes 
System.dll!Microsoft.Win32.SystemEvents.WindowProc(System.IntPtr hWnd = 2032836, int msg = 8218, System.IntPtr wParam = 47, System.IntPtr lParam = 100019840) + 0x2ca bytes 
[Native to Managed Transition] 
[Managed to Native Transition] 
System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(int dwComponentID, int reason = 4, int pvLoopData = 0) Line 2106 + 0x8 bytes C# 
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason = 4, System.Windows.Forms.ApplicationContext context = {System.Windows.Forms.Application.ModalApplicationContext}) Line 3377 + 0x1b bytes C# 
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) Line 3261 + 0xa bytes C# 
System.Windows.Forms.dll!System.Windows.Forms.Application.RunDialog(System.Windows.Forms.Form form) Line 1488 C# 
System.Windows.Forms.dll!System.Windows.Forms.Form.ShowDialog(System.Windows.Forms.IWin32Window owner) Line 6120 + 0x8 bytes C# 
Schedule.exe!ME.APTS.ScheduleApp.ScheduleAppMainForm.ShowOpenScheduleForm.AnonymousMethod() Line 829 + 0xd bytes C# 
Schedule.exe!ME.APTS.ScheduleApp.ScheduleAppMainForm.PromptUserToSaveSchedule(System.Action oAfterPromptUserToSaveCallBack = {Method = Cannot evaluate expression because the code of the current method is optimized.}) Line 1858 + 0xb bytes C# 
Schedule.exe!ME.APTS.ScheduleApp.ScheduleAppMainForm.ShowOpenScheduleForm() Line 859 + 0xb bytes C# 
[Native to Managed Transition] 
[Managed to Native Transition] 
mscorlib.dll!System.Delegate.DynamicInvokeImpl(object[] args) + 0x55 bytes 
System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallbackDo(System.Windows.Forms.Control.ThreadMethodEntry tme) Line 7266 + 0xb bytes C# 
System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallbackHelper(object obj) Line 7228 + 0x7 bytes C# 
mscorlib.dll!System.Threading.ExecutionContext.runTryCode(object userData) + 0x51 bytes 
[Native to Managed Transition] 
[Managed to Native Transition] 
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x67 bytes 
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x45 bytes 
System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallback(System.Windows.Forms.Control.ThreadMethodEntry tme) Line 7213 + 0xffffffc5 bytes C# 
System.Windows.Forms.dll!System.Windows.Forms.Control.InvokeMarshaledCallbacks() Line 7297 + 0xb bytes C# 
System.Windows.Forms.dll!System.Windows.Forms.Control.WndProc(ref System.Windows.Forms.Message m) Line 13848 C# 
System.Windows.Forms.dll!System.Windows.Forms.ScrollableControl.WndProc(ref System.Windows.Forms.Message m) Line 1491 C# 
System.Windows.Forms.dll!System.Windows.Forms.ContainerControl.WndProc(ref System.Windows.Forms.Message m) Line 1898 C# 
System.Windows.Forms.dll!System.Windows.Forms.Form.WndProc(ref System.Windows.Forms.Message m) Line 7515 C# 
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.OnMessage(ref System.Windows.Forms.Message m) Line 14051 C# 
System.Windows.Forms.dll!System.Windows.Forms.Control.ControlNativeWindow.WndProc(ref System.Windows.Forms.Message m) Line 14106 C# 
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg = 49512, System.IntPtr wparam, System.IntPtr lparam) Line 647 + 0xa bytes C# 
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.DefWndProc(ref System.Windows.Forms.Message m = {System.Windows.Forms.Message}) Line 814 + 0x1d bytes C# 
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.WndProc(ref System.Windows.Forms.Message m) Line 1409 C# 
Infragistics2.Win.UltraWinToolbars.v8.1.dll!Infragistics.Win.UltraWinToolbars.UltraToolbarsManager.FormSubClasser.WndProcImpl(ref System.Windows.Forms.Message m) + 0x17f5 bytes 
Infragistics2.Win.UltraWinToolbars.v8.1.dll!Infragistics.Win.UltraWinToolbars.UltraToolbarsManager.FormSubClasser.WndProc(ref System.Windows.Forms.Message m) + 0x5 bytes 
System.Windows.Forms.dll!System.Windows.Forms.NativeWindow.Callback(System.IntPtr hWnd, int msg = 49512, System.IntPtr wparam, System.IntPtr lparam) Line 647 + 0xa bytes C# 
[Native to Managed Transition] 
[Managed to Native Transition] 
System.Windows.Forms.dll!System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(int dwComponentID, int reason = -1, int pvLoopData = 0) Line 2106 + 0x8 bytes C# 
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(int reason = -1, System.Windows.Forms.ApplicationContext context = {System.Windows.Forms.ApplicationContext}) Line 3377 + 0x1b bytes C# 
System.Windows.Forms.dll!System.Windows.Forms.Application.ThreadContext.RunMessageLoop(int reason, System.Windows.Forms.ApplicationContext context) Line 3261 + 0xa bytes C# 
System.Windows.Forms.dll!System.Windows.Forms.Application.Run() Line 1457 C# 
Schedule.exe!ME.APTS.ScheduleApp.ScheduleApp.LoadData() Line 318 + 0x5 bytes C# 
Schedule.exe!ME.APTS.ScheduleApp.ScheduleApp.Run() Line 170 + 0x9 bytes C# 
Schedule.exe!ME.APTS.ScheduleApp.ScheduleApp.Main() Line 126 + 0xb bytes C# 

Answer 1

我经历了这个确切的同样的问题一年前（应用程序挂起没有用户交互一段时间后，随着OnUserPreferenceChanging()调用堆栈）。

最可能的原因是您在控件上使用InvokeRequired/Invoke()而不是在主窗体上。如果控件的句柄尚未创建，有时会产生错误的结果。

解决方案是始终在主窗口上调用InvokeRequired/Invoke()（如果您不想为表单类引入依赖项，则可以将其作为ISynchronizeInvoke进行投射）。

你可以找到一个优秀的，非常详细的原因和解决方案的描述here。

Answer 2

是的，这是由SystemEvents类造成的一个相当臭名昭着的线程问题。我从来没有得到一个可靠的诊断，但90％的可能性是，这是由您的应用程序中的初始化问题触发的。

根本问题是系统事件通过您的应用程序中的第一个窗体进行按需初始化，该窗体具有对它生成的事件感兴趣的控件。如果在主线程中创建的第一个表格是而不是，SystemEvents无法猜测哪个线程是程序中的UI线程。最终，当收到通知（如UserPreferenceChanging）时，它会尝试在该线程上触发事件，但它不在附近。 SynchronizationContext类中的回退代码会引发线程池线程上的事件。这不可避免地通过在未创建窗口的线程上运行UI代码来调用线程化地狱。发生这种情况时，很多事情都会出错。在工作站被锁定后恢复桌面时，死锁是特别常见的结果。

这不是唯一可能出现的问题，如果您在其他线程上创建任何表单，这是不可避免的。现在SystemEvents不可能在正确的线程上提出事件，当然有人会失败。展示调试技术is here的博客文章。是的，丑陋。理想情况下，控制人员知道要处理这个问题，并编制通知本身。但是，这是在.NET 2.0，DataGridView，NumericUpDown，DomainUpDown，ToolStrip + MenuStrip和ToolStripItem派生类忘记知识不这样做。我应该注意RichTextBox和ProgressBar是可疑的，其余的都没问题。

查看您的应用的启动顺序。创建你自己的启动画面是一个很好的主角，不妨使用WindowsFormsApplicationBase类提供的内置支持。如果你自己做，那么保持它很简单，只是一个位图。如前所述，任何可以在工作线程上创建自己的表单的地方都是麻烦的处方。总是这样做，在工作人员上运行昂贵的代码并将UI保留在主线程上。

Answer 3

我一直在遭受这个完全相同的问题，它始终是由于在Windows 8.1下更频繁地发生Microsoft.Win32.SystemEvents.DisplaySettingsChanged事件，也是因为我的应用程序正在运行，并且某人连接了VNC或RDP 。使用Windows x.x与Fusion（VMWare）通过Mac更改桌面设置时也非常清楚。

尝试很多事情后，我终于得到了解决由我MainApp（即创建的所有对话，并执行所有调用的）

申报听这些事件：

Microsoft.Win32.SystemEvents.DisplaySettingsChanged += SystemEvents_DisplaySettingsChanged; 
Microsoft.Win32.SystemEvents.DisplaySettingsChanging += SystemEvents_DisplaySettingsChanging; 
Microsoft.Win32.SystemEvents.UserPreferenceChanged += SystemEvents_UserPreferenceChanged; 

实现：

static void SystemEvents_UserPreferenceChanged(object sender, Microsoft.Win32.UserPreferenceChangedEventArgs e) 
{ 
    //Do nothing 
} 

static void SystemEvents_DisplaySettingsChanged(object sender, EventArgs e) 
{ 
    //Do nothing 
} 

static void SystemEvents_DisplaySettingsChanging(object sender, EventArgs e) 
{ 
    //Do nothing 
} 

这些事件的捕获什么都不做，但这似乎是无效的，当这些事件来自窗口和任何其他部分我的代码正在等待MainApp参加Invoke。

希望这会有所帮助。

Answer 4

禁用视觉样式也将解决该问题（如果你不需要他们）

//Comment this line if you do not want visual styles and do not want to mess with SystemEvents. 
//Application.EnableVisualStyles();