WinUI3用CommunityToolkit.Mvvm.Messaging线程通信遇RPC_E_WRONG_THREAD异常

这个RPC_E_WRONG_THREAD异常的核心原因是后台线程发送消息时，新增的StatusWindow接收者在处理消息时跨线程访问了UI线程专属对象，具体拆解如下：

1. WeakReferenceMessenger的执行逻辑：默认情况下，WeakReferenceMessenger.Default.Send()会在**发送线程（即你的后台RandomMessageGenerator线程）**同步执行所有接收者的消息处理方法，不会自动切换到UI线程。

2. 新增接收者的问题：打开StatusWindow后，该窗口（或其ViewModel）新增了TraceMessage的接收注册。这个接收者的处理方法中，存在直接访问UI元素、修改UI绑定属性（比如ObservableCollection、绑定到UI的ViewModel属性）等操作，而这些操作必须在UI线程执行。

3. 异常传播导致线程终止：由于Send方法是同步执行，跨线程访问UI触发的异常会直接回传到后台线程的调用栈，导致后台线程被终止。

而之前MainPage接收正常，大概率是因为MainPage的接收处理仅做数据存储（未涉及UI操作），或者其消息注册时已经指定了UI线程调度（比如通过带DispatcherQueue的重载、或使用[Recipient]属性自动关联UI线程）。

针对这个问题，有两种常见的修复方式：

方式1：注册消息时指定UI线程调度 #

在StatusWindow的接收者注册消息时，使用带DispatcherQueue的重载，强制让处理方法在UI线程执行：

// 在UI线程环境下执行注册（比如StatusWindow的构造函数、ViewModel初始化时）
WeakReferenceMessenger.Default.Register<TraceMessage>(
    this,
    DispatcherQueue.GetForCurrentThread(),
    (recipient, message) =>
    {
        // 这里的代码会在UI线程执行，可安全访问UI相关对象
        UpdateStatusDisplay(message.Content);
    });

方式2：处理方法内手动切换到UI线程 #

如果无法在注册时指定调度，可在处理方法内部，将UI相关操作封装到DispatcherQueue的队列中：

private void HandleTraceMessage(TraceMessage message)
{
    // 非UI操作可直接在后台线程执行
    LogMessageToFile(message.Content);

    // UI相关操作切换到UI线程执行
    DispatcherQueue.GetForCurrentThread().TryEnqueue(() =>
    {
        StatusTextBlock.Text = message.Content;
        StatusCollection.Add(message);
    });
}

额外提示 #

如果使用CommunityToolkit.Mvvm的[Recipient]属性自动注册消息，确保ViewModel是在UI线程创建且继承自ObservableObject——框架会自动使用UI线程的DispatcherQueue调度处理方法。

内容的提问来源于stack exchange，提问作者aturnbul