SystemEvents.SessionSwitch 导致我的 Windows 窗体应用程序冻结

Question

我在 .NET 4.5 上有一个 C# Windows 窗体应用程序。

此应用程序连接到 USB 设备。

我想同时支持多个会话。

为此，我需要在会话锁定时与该设备断开连接，以允许新会话连接到它。

我使用 SystemEvents.SessionSwitchEventArgs.Reason 来检测此类事件： - SessionSwitchReason.ConsoleDisconnect on session switch - SessionSwitchReason.ConsoleConnect on unlock after session switch

此事件似乎是完美的解决方案，但有时在随机时间（在多次锁定或解锁之后），该事件不会被触发并且 UI 会冻结。值得注意的是，当应用程序在调试器中运行时不会发生这种情况。

我从日志中知道其他一些后台线程仍在正常工作，但 UI 冻结并且未调用事件的订阅函数。

我的代码示例：

程序.cs：

using Microsoft.Win32;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace MyProgram
{
    static class Program
    {
        private static Mutex mutex = null;
    [STAThread]
    static void Main()
    {
        const string appName = "MyProgram";
        bool createdNew;

        mutex = new Mutex(true, appName, out createdNew);

        if (!createdNew)
        {
            //app is already running! Exiting the application  
            return;
        }

        Application.EnableVisualStyles();

        //This was one attempt to solve the UI deadlock Microsoft.Win32.SystemEvents.UserPreferenceChanged += delegate { };

        Application.SetCompatibleTextRenderingDefault(false);
        MyProgramEngine MyProgramEngine = new MyProgram.MyProgramEngine();
        Application.Run(MyProgramEngine.getForm());
    }
}

}

我的程序引擎：

using log4net;
using log4net.Config;
using System;
using System.Collections;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using System.Timers;
using WindowsInput;
using System.Windows.Forms;
using Microsoft.Win32;


namespace MyProgram
{
    class MyProgramEngine
    {
        private MainForm mainForm;
    public MyProgramEngine()
    {
        XmlConfigurator.Configure();
        Utility.logger.Info(string.Format("MyProgram Started. Version: {0}", Application.ProductVersion));
        SystemEvents.SessionSwitch += new SessionSwitchEventHandler(SystemEvents_SessionSwitch);
        if (!GlobalSettings.getInstance().isProperlyConfigured())
        {
            WarningForm warningForm = new WarningForm("MyProgram is not properly configured. Please contact support");
            warningForm.ShowDialog();
            Application.Exit();
            Environment.Exit(0);
        }
        mainForm = new MainForm();
        initArandomBackgroundThread();
        initDeviceThread();
    }

    private void initDeviceThread()
    {
        Thread detectAndStartReader = new Thread(initDevice);
        detectAndStartReader.IsBackground = true;
        detectAndStartReader.Start();
    }

    public void initDevice()
    {
        //Connect to device
        //Start device thread
    }

    public MainForm getForm()
    {
        return mainForm;
    }


    //Handles session switching events
    internal void SystemEvents_SessionSwitch(object sender, SessionSwitchEventArgs e)
    {
        try
        {
            if (e.Reason.Equals(SessionSwitchReason.ConsoleDisconnect))
            {
                DisconnectFromDevice();
                TerminateDeviceThread();
            }
            else if (e.Reason.Equals(SessionSwitchReason.ConsoleConnect))
            {
                initDeviceThread();
            }
            else
            {
                Utility.logger.Info("The following SesseionSwitchReason has been caught: " + e.Reason + " , No action!");
            }
        }
        catch (Exception ex)
        {
            Utility.logger.Error("Something bad happened while managing session switching events", ex);
        }

    }

}

注意：我对 SessionSwitchReason.SessionUnlock 或 SessionSwitchReason.SessionLock 不感兴趣，因为我都不希望在同一会话上对会话锁定和解锁进行任何操作。

感谢您的支持！

Answer 1

我发现了错误在哪里。

简单来说，

永远不要在后台工作线程上创建控件。

在我的代码中，如果我删除了 SessionSwitch 事件订阅，挂起仍然会发生。我能够将主线程上的等待追溯到 SystemSettingsChanging，这也是一个 SystemEvent 但我无法控制。

在我几乎放弃试图找出这个挂起之后，我开始逐行阅读代码，这让我发现正在后台线程上创建了一个表单（弹出窗口）。

如上面给出的示例所示，这部分代码没有引起我的注意。

initArandomBackgroundThread();

要了解有关此冻结的更多信息，您可以前往Microsoft 支持部门进行详细解释。

微软声称的这种冻结的低级别原因是

如果在不发送消息的线程上创建控件并且 UI 线程收到 WM_SETTINGCHANGE 消息，则会发生这种情况。

常见原因是在辅助 UI 线程上创建的闪屏或在工作线程上创建的任何控件。

修复

应用程序不应将 Control 对象留在没有活动消息泵的线程上。如果无法在主 UI 线程上创建控件，则应在专用的辅助 UI 线程上创建它们，并在不再需要时立即处置。

调试

在进程视图（Spy.Processes 菜单）中使用 Spy++ 识别在哪个线程上创建哪些窗口的一种方法。选择挂起的进程并展开其线程以查看是否有任何意外窗口。如果它仍然存在，这将找到本机窗口；但是，即使本机窗口已被破坏，只要托管控件尚未被处置，该问题也会发生。