在多 DPI / 刷新率 多屏环境下使用 spacedesk 虚拟副屏时出现冻结与渲染卡死问题

[Merrrrrrrrr]

在反馈此问题前请注意 Please note before reporting this issue

• 已经查看相关帮助内容 Read more about the Salt Player help content
• 已经在本仓库搜索相关内容（避免重复反馈）Already searched for related content in this repository (to avoid duplicate feedback)
• 确认仅将提交一个问题（多个问题或者备注提及另外的问题请重新提交新的）Confirm to submit only one issue (if multiple issues or notes mention other issues, please submit a new one separately)

平台 Platform

• Android
• Windows
• HarmonyOS

设备型号 Device Model

R9 8945HX + RTX 5070Ti Laptop

系统版本 System Version

Windows 11 专业版 25H2

软件版本 App Version

SPW 1.14

描述问题 Describe issue

问题描述

在 Windows 11 环境下使用 SaltPlayer (v1.14) 在 spacedesk (v2.2.25) 虚拟副屏上运行时，会触发严重的界面与音频冻结问题。

该问题与已有反馈 #1178（应用在缩放不一致的屏幕上切换会导致窗口大小问题）存在一定相似性，但表现更严重：在副屏放置一段时间后，软件会完全卡死（画面冻结、音频断开）。

环境信息

• OS: Windows 11 专业版 25H2
• Device: R9 8945HX + RTX 5070Ti Laptop（独显直连）
• SaltPlayer Version: Windows v1.14
• spacedesk Version: v2.2.25（有线连接）
• Audio Output: Windows API -> 电脑内置 Senary Audio（未启用 spacedesk audio streaming）

屏幕配置

• 主屏：

  • 2560 × 1600 @ 300Hz
  • DPI 缩放 175%

• spacedesk 虚拟副屏：

  • 2772 × 1240 @ 120Hz
  • DPI 缩放 200%

复现步骤

1. 启动并连接 spacedesk 虚拟副屏。
2. 打开 SaltPlayer (v1.14)。
3. 将窗口拖拽至 spacedesk 虚拟副屏。
4. 正常播放音乐数分钟。
5. 一段时间后必然触发冻结问题。（在当前环境下约 5-15 分钟内稳定复现，目前已连续测试 3 次，均可复现。）
   修订：第4次测试持续了30分钟才触发问题。所有的测试包含了歌词界面和选曲界面，都会发生卡死。

实际表现

触发后会出现以下现象：

• 界面完全冻结，无法响应点击或快捷键。
• 音频同步停止，无任何声音输出。
• 任务管理器中 SaltPlayer 进程始终显示为“正在运行”，未显示“未响应”。
• 无法通过窗口右上角关闭按钮退出程序，必须通过任务管理器强制结束进程。

此外：

• 即使强制断开 spacedesk 副屏，使 Windows 自动将窗口移回主屏幕，SaltPlayer 依然保持冻结状态。
• 此时界面底部会出现与 [SPW]应用在缩放不一致的屏幕上切换会导致窗口大小问题 #1178 类似的白边。

需要特别说明的是：

• spacedesk 本身并未整体崩溃。
• 虚拟副屏在问题发生后仍能正常显示 Windows 桌面及其他程序。
• 当前观察到只有 SaltPlayer 会进入完全冻结状态。

预期行为

SaltPlayer 应能够在不同分辨率、刷新率及 DPI 缩放环境下稳定运行，并在跨屏移动及长时间放置后依然能够正常渲染与播放音频。

额外排查信息

## WER 日志

在问题发生期间，我发现 Windows Event Viewer 中存在如下 APPCRASH 记录：

* Process: displayUtil.exe
* Event Type: APPCRASH
* Exception Code: c0000005

由于崩溃进程并非 SaltPlayer 本身，因此我无法确认其是否为根因，或者只是虚拟显示/渲染链路异常后的副作用。

但目前观察到：

* 此类 displayUtil.exe 崩溃仅会在使用 spacedesk 时出现；
* SaltPlayer 的冻结问题也仅在窗口长时间停留于 spacedesk 虚拟副屏时触发。

因此该信息或许能够为排查多屏渲染、DPI 缩放、虚拟显示器兼容性等问题提供一定参考。

修订：已确认无关，第4次复现未看到此错误报告。

与 #1178 的关联

强制断开副屏并将窗口移回主屏后，界面会出现与 #1178 类似的渲染异常。

这可能表明：

• 两者在底层存在一定关联；
• 均可能与多屏切换、不同 DPI 缩放、不同刷新率环境下的渲染资源重建或窗口状态同步有关。

其他补充

当前尚未在 SaltPlayer 根目录下发现相关崩溃日志。

由于：

• 主屏与副屏存在较大硬件参数差异；
• 问题仅在窗口长时间停留于虚拟副屏后触发；

因此猜测问题可能与：

• 多显示器状态切换
• 高 DPI 自适应
• 虚拟显示器兼容性
• 渲染资源恢复

等相关逻辑存在一定关联。

以上信息仅供参考，希望能够帮助定位相关问题。

[Merrrrrrrrr]

需要说明的是，这类使用虚拟显示器（spacedesk）作为长期副屏的场景可能相对小众，因此实际遇到该问题的用户数量未必很多。

但结合目前观察到的现象来看，该问题可能并不仅限于虚拟显示器环境本身。

除了当前的 spacedesk 冻结问题外，我也在其他 issue 中观察到一些与多屏切换、窗口渲染或显示状态相关的异常现象（例如偶发闪烁等）。

因此，spacedesk 可能只是一个更容易稳定触发问题的特殊场景。

希望这些信息也能够对其他多屏显示相关问题的定位与修复有所帮助。

[Moriafly]

收到反馈

[Merrrrrrrrr]

刚刚我重新进行了多轮测试，目前基本可以确认：该问题实际上与 WASAPI 模式下“单曲循环导致卡死”问题（#1988）表现一致。

此前之所以误以为与 spacedesk / 多屏渲染有关，是因为我测试时始终在 WASAPI + 单曲循环场景下进行，导致问题被错误归因到了虚拟副屏与渲染环境。

在重新测试后发现：

• 即使不使用 spacedesk，也能够复现相同卡死问题；
• 问题与窗口所在屏幕、DPI 缩放、刷新率等因素没有直接关系；
• 因此基本可以排除渲染方式或虚拟显示器兼容性导致的问题。

鉴于 #1988 似乎已经在后续版本中得到修复或正在处理，因此本 issue 应当可以关闭。

抱歉此前没有进行更充分的变量排查，给排查方向带来了干扰。

[Merrrrrrrrr]

重新打开此 issue，仅因为其此前已被加入 milestone。

目前我仍认为该问题大概率与 #1988 属于同一问题，后续状态可由维护者决定是否作为 duplicate / fixed 处理。