最近遇到了一个非常奇怪的远程桌面问题：使用 Mac 上的 Windows App 连接一台 Windows 11 电脑，可以正常登录并进入桌面，但过了几秒钟，远程连接就会突然中断，弹出“协议错误”，错误代码为 0x200d。
经过一番排查，最终找到了一个简单且有效的解决办法：禁用 Windows 远程桌面的 H.264/AVC 硬件编码。
问题已经在我的电脑上得到解决。考虑到网上关于这个错误码的有效解决方案并不容易找到，特意把排查过程记录下来，希望能够帮助遇到类似问题的朋友。
一、问题现象：能连接、能登录，却无法保持连接
先介绍一下我的使用环境。
- 客户端：Apple Mac，使用微软 Windows App 远程桌面客户端。
- 被控电脑：Windows 11 26H2 系统，配备 NVIDIA 独立显卡。
- 连接方式：通过 FRP（Fast Reverse Proxy）内网穿透，实现跨互联网远程连接。
- 故障现象：成功进入 Windows 桌面后，几秒钟就会自动断开。
Windows App 弹出的英文错误信息如下：
Your session ended because of a protocol error. If this keeps happening, contact your network administrator for assistance.
Error code: 0x200d
简单翻译就是：由于协议错误，远程桌面会话已结束。
比较奇怪的是，同一台 Mac 通过 Windows App 远程连接其他 Windows 电脑时完全正常，而且其他电脑同样使用 FRP 实现远程访问。
也就是说：
Mac 没有普遍性的远程连接故障，FRP 也不是所有连接都存在问题，唯独这台 Windows 11 电脑会在进入桌面后断开。
这让问题变得有些棘手。
二、初步排查：问题可能不在密码和网络连接
最开始，我也怀疑是不是 Windows App 保存的登录凭据出了问题。
不过，仔细分析故障过程后发现，这个判断不太符合实际情况。
因为整个远程连接实际上已经完成了几个关键步骤：
- Mac 成功与远程 Windows 电脑建立连接。
- Windows 成功完成用户登录认证。
- 远程桌面已经能够正常显示。
- 进入桌面几秒钟后，连接才突然终止。
这意味着，至少最初的 TCP 连接和用户认证是成功的。
如果单纯是账号或密码错误，通常不会顺利进入桌面。
而且，其他通过 FRP 访问的电脑都能正常工作，也让人怀疑是不是目标 Windows 电脑本身的远程桌面服务出现了兼容性问题。
进一步分析后，我把排查方向集中在两个方面：
一是 RDP 的 TCP/UDP 网络传输，二是 Windows 远程桌面的图形编码。
其中，图形编码的问题后来成为了解决故障的关键。
三、关键突破：从 Windows 事件日志找到 NVIDIA 编码器
既然能直接操作目标 Windows 电脑，就可以利用系统日志来进一步分析，而不是不断尝试修改各种设置。
Windows 远程桌面服务本身会记录比较详细的连接日志。
在目标 Windows 电脑上，以管理员身份打开 PowerShell，执行：
Get-WinEvent -LogName 'Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational' -MaxEvents 30 |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-List这个命令可以读取 Windows 远程桌面核心服务的近期事件，包括连接建立、图形通道初始化、网络传输和会话断开等信息。
在我的日志中，出现了两条非常值得关注的记录。
第一条：远程桌面启用了 NVIDIA 的 H.264 硬件编码器。
事件 ID 为 170：
AVC hardware encoder enabled: 1,
encoder name is NVIDIA H.264 Encoder MFT.
Server: OFFICE这条日志非常关键。
其中：
AVC hardware encoder enabled: 1表示硬件视频编码处于启用状态。NVIDIA H.264 Encoder MFT表示远程桌面正在使用 NVIDIA 提供的 H.264 视频编码器。
换句话说，Windows 远程桌面传输的画面，使用了 NVIDIA 显卡的硬件编码能力。
第二条：远程桌面使用了较高的显示分辨率。
事件 ID 为 168：
The resolution requested by the client:
Monitor 0: (3840, 2160)另外一次连接中，还出现了 2880 × 1800 的分辨率。
这说明 Mac 客户端曾经向 Windows 请求过 4K 或其他高分辨率桌面画面。
在这样的情况下，RDP 图形编码器需要持续对桌面图像进行压缩，并通过网络传输到 Mac。
如果显卡驱动、硬件编码器、RDP 图形协议或客户端解码过程存在兼容性问题，就可能在显示桌面之后出现异常。
当然，仅凭这两条日志，还不能断定 NVIDIA 编码器一定存在问题。
但它们给出了一个非常明确的排查方向：尝试禁用 RDP 的硬件视频编码，观察故障是否消失。
四、最终解决方案：禁用远程桌面的 H.264/AVC 硬件编码
这一步最终解决了我的问题。
操作其实非常简单，不需要重装 Windows，也不需要卸载 NVIDIA 显卡驱动。
第 1 步：打开 Windows 组策略编辑器
在目标 Windows 电脑上，按下：
Win + R
输入：
gpedit.msc
按回车，打开“本地组策略编辑器”。
第 2 步：找到远程桌面图形编码策略
依次展开：
计算机配置
→ 管理模板
→ Windows 组件
→ 远程桌面服务
→ 远程桌面会话主机
→ 远程会话环境
在右侧找到下面这个策略：
Configure H.264/AVC hardware encoding for Remote Desktop Connections
中文通常显示为：
为远程桌面连接配置 H.264/AVC 硬件编码
第 3 步：禁用硬件编码
双击打开该策略。
将它设置为：
Disabled（已禁用）
点击“应用”和“确定”。
注意，这里禁用的是远程桌面的 H.264/AVC 硬件编码，并不是禁用 NVIDIA 显卡本身，不会因此关闭电脑正常的显卡功能。
第 4 步：刷新组策略
以管理员身份打开 PowerShell 或命令提示符，运行：
gpupdate /force等待组策略更新完成。
第 5 步：重启电脑并重新连接
重启目标 Windows 电脑。
然后返回 Mac，使用 Windows App 再次远程连接。
测试结果：成功！
修改这项设置后，Mac 可以正常远程进入 Windows 桌面，之前进入桌面几秒后自动断开、弹出 0x200d 错误的问题消失了。
整个解决过程并不复杂，真正困难的是找到正确的排查方向。
五、为什么禁用硬件编码就能解决？
这里需要简单介绍一下 Windows 远程桌面的工作原理。
我们通过 RDP 远程控制 Windows 时，远程电脑需要不断将桌面画面编码、压缩，再传输到客户端显示。
其中，H.264/AVC 是远程桌面可以使用的一种视频编码技术。
编码过程可以通过两种方式实现：
第一种：硬件编码
利用 NVIDIA 等显卡的专用视频编码能力处理桌面画面。
优点是通常可以减少 CPU 占用，在高分辨率、高帧率等场景下具有性能优势。
第二种：软件编码
主要利用 CPU 完成编码工作，不依赖显卡的视频硬件编码器。
它在某些兼容性场景下可能更加稳定，但也可能增加 CPU 负担。
微软官方文档明确说明：
当上述 H.264/AVC 硬件编码策略设为 Disabled 或 Not Configured 时，远程桌面将使用软件编码。
因此，我的操作实际上是让 Windows RDP 绕过 NVIDIA 的 H.264 硬件编码路径，改为软件编码。
从实际测试结果来看，问题很可能与 NVIDIA 的硬件编码路径有关。
不过需要强调：
这并不等于确认 NVIDIA 显卡硬件损坏，也不能直接认定 Windows 11 26H2 存在普遍性的系统 Bug。
真正的兼容性问题也可能发生在显卡驱动、Windows RDP 图形组件，以及 Mac 版 Windows App 的协议协商等环节。
这次排查能够确认的是：在我的这套设备环境下，禁用硬件编码有效消除了故障。
六、禁用硬件编码会不会影响远程桌面性能？
这也是很多人可能关心的问题。
我的建议是：如果主要用于普通远程办公、文档处理、编程、服务器管理等工作，可以优先考虑稳定性。
禁用硬件编码后，Windows 仍然可以正常使用远程桌面，通常不需要额外配置。
但在 4K 高分辨率、多显示器、高清视频或其他需要频繁更新画面的场景下，软件编码可能增加 CPU 占用，并影响远程桌面的性能。
因此，并不是所有电脑都应该统一关闭硬件编码。
如果你的远程桌面本来就运行正常，没有必要专门修改这项设置。
对于像我这样已经出现 0x200d 协议错误的用户，则非常值得尝试。
七、如果你的问题还没有解决，可以继续检查什么？
需要提醒的是，0x200d 只是客户端显示的协议错误代码，并不能单凭这个数字确定所有故障的原因。
如果禁用 H.264 硬件编码后仍然不能解决，建议继续排查以下方向：
1. 降低 Windows App 的显示分辨率
在 Mac 的 Windows App 中编辑目标 PC 的显示设置。
可以尝试关闭 Retina 显示优化、关闭自动调整分辨率，并降低远程桌面的显示分辨率，例如设为 1920 × 1080。
这样有助于排除高分辨率图形传输引发的问题。
2. 检查 RDP 的 UDP/TCP 传输
对于跨互联网连接，尤其是使用 FRP、端口映射或 VPN 的情况，可以测试让远程桌面仅使用 TCP。
在组策略中找到：
计算机配置 → 管理模板 → Windows 组件 → 远程桌面服务 → 远程桌面会话主机 → 连接
将 Select RDP transport protocols 设置为 Enabled，并选择 Use only TCP。
这是排除 UDP 通道兼容性问题的一种测试手段，并非本次案例最终确认有效的解决办法。
3. 查看远程桌面事件日志
建议重点关注以下日志：
Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
尤其是涉及图形编码、传输协议及连接断开的事件。
4. 更新显卡驱动和 Windows App
如果希望以后重新启用硬件编码，可以在更新 NVIDIA 显卡驱动、Windows 系统和 Mac 客户端后重新测试。
修改系统策略前，最好先记录原始设置，以便必要时恢复。
此外，使用 FRP 访问远程桌面时，也要注意认证、访问控制和通信安全，尽量避免将未经充分保护的 RDP 服务直接暴露在公网。
八、最后总结
这次排障给我最大的启发是：
远程桌面连接成功，并不意味着图形传输一定正常。
如果你使用 Mac 上的 Windows App 连接 Windows 11，出现以下特征：
- 能正常输入账号密码；
- 能成功进入远程桌面；
- 进入桌面几秒钟后自动断开；
- 弹出
Your session ended because of a protocol error； - 错误代码为
0x200d； - 远程 Windows 电脑使用 NVIDIA 显卡；
那么不妨优先尝试下面这个设置：
gpedit.msc → 远程桌面会话主机 → 远程会话环境 → Configure H.264/AVC hardware encoding for Remote Desktop Connections → Disabled
之后执行 gpupdate /force，重启 Windows，再重新连接。
在我的电脑上，这个办法已经得到实际验证。
它不一定适用于所有 0x200d 错误，但对于 NVIDIA 显卡相关的 RDP 图形编码兼容性问题，是一个操作简单、可以恢复、值得优先尝试的办法。
现在回想起来，以前远程连接过程中时常出现画面冻住，需要重新连接才能操作的情况，说不定也是这个问题导致的。目前使用一切正常。
希望这篇记录能帮到正在为同样问题困扰的朋友，也欢迎大家交流自己的排障经验。
参考资料
微软官方文档：ADMX_TerminalServer Policy CSP
https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-admx-terminalserver
微软官方文档：Windows App 显示设置
https://learn.microsoft.com/en-us/windows-app/display-settings
本文基于一次真实的 Mac—Windows 11 远程桌面故障排查经历整理。不同系统版本、显卡驱动及网络环境可能存在差异，建议根据实际情况测试。
评论