已按 `20260206a -> 20260502a` 摸排，没改代码，工作树仍是干净的。

结论倾向：最可疑的是 `86b1fac` 引入的 PowerPoint COM busy-retry 逻辑，也就是你记得的“防止 pptcom 死掉”那块。旧版遇到 `0x8001010A` 这类 PowerPoint 忙只打印并继续轮询；新版在 [PptCOM.cs](D:/Project/Inkeys/Repo/Inkeys2/PptCOM/PptCOM.cs:221) 增加了 10 秒超时，超时后会把 `TotalPage/CurrentPage` 写成 `-1`，部分路径会 `break` 或 `FullCleanup()`。而 UI 是否出现正是由 [IdtPlug-in.cpp](D:/Project/Inkeys/Repo/Inkeys2/智绘教/IdtPlug-in.cpp:2264) 的 `PptInfoState.TotalPage != -1` 驱动，所以“开机很久后第一次进入放映不显示”很可能是 COM 首次绑定时 PowerPoint/WPS/ROT 短暂忙或返回异常，被新版当成断联处理了。

第二个可疑点是 `5854797` 的 ProgID-based ROT 扫描。新版会解析 `PowerPoint.Application`、`KWPP.Application`、`Wpp.Application`、`WPP.Application`，并直接把 application moniker 当作候选对象，见 [PptCOM.cs](D:/Project/Inkeys/Repo/Inkeys2/PptCOM/PptCOM.cs:384) 和 [PptCOM.cs](D:/Project/Inkeys/Repo/Inkeys2/PptCOM/PptCOM.cs:605)。论坛里用户机器装过 WPS，这点和现象吻合。这里还有一个细节：候选 COM 对象在计算优先级前就进入去重列表，见 [PptCOM.cs](D:/Project/Inkeys/Repo/Inkeys2/PptCOM/PptCOM.cs:637)，如果某个 WPS/Office application moniker 先被扫到但 `ActivePresentation` 暂时不可用，后续同实例的 presentation moniker 可能被当重复跳过。

`IdtPlug-in.cpp` 这轮变更主要是线程状态守卫、触摸/鼠标捕获和 UI 信号原子化；这些更像是“组件显示后交互”的问题源，不像“组件根本不显示”的主因。C++ 侧 [GetPptState](D:/Project/Inkeys/Repo/Inkeys2/智绘教/IdtPlug-in.cpp:457) 仍会在 `PptComService()` 返回后约 2 秒重试，所以它不是完全死掉，而是更像反复得不到有效 `TotalPage`。

外部帖子我读到的关键症状是：Win10、PowerPoint 2019、装过 WPS；开机数小时后使用或切换 PPT 小组件不显示，重启缓解；补充为“开机后 2 小时内没进入过 PPT 放映模式，再进入就不显示”。来源：[论坛帖](https://forum.smart-teach.cn/d/1924-zhi-hui-jiao-inkeysde-pptxiao-zu-jian-you-shi-bu-xian-shi)，代码范围参考：[GitHub compare](https://github.com/Alan-CRL/Inkeys/compare/20260206a...20260502a)。

可以，下一步我会倾向做一个“一次性诊断版”，不要让用户反复远程配合。核心思路是把 PPTCom3 做成黑盒飞行记录器：用户只需要替换一次程序或 DLL，正常使用到复现，然后把日志文件发回来。

我建议记录成 `JSONL` 或简单文本，放到例如 `opt/pptcom_trace.log`，滚动限额 2 到 5 MB，避免无限写盘。重点记录这些点：

1. `PptCOM.cs` 里的 COM 绑定全过程  
记录 `PptComService` 每轮关键状态：`bestPriority/targetPriority`、是否 `needRebind`、`pptApplication == null`、`pptActivePresentation == null`、`bindingEvents`、`forcePolling`、`TotalPage/CurrentPage`、每次 `break/continue/FullCleanup` 的原因。

2. ROT 扫描细节  
在 `GetAnyActivePowerPoint` 中记录每个命中的 moniker：`displayName` 类型、是否 presentation file、是否 application moniker、是否重复、是否取到 `ActivePresentation`、是否取到 `SlideShowWindow`、最终优先级。  
这个能直接判断是不是 WPS/Office moniker 抢占、重复去重过早、或者 ROT 里根本没目标。

3. COM 异常和 busy-retry 细节  
在 `HandleBusyException` 里记录 `stage`、HRESULT、连续 busy 起点、距离超时还剩多久、最终是否触发“发送结束信号”。  
这能验证我前面怀疑的 `10s busy timeout` 是否真把状态打成 `-1`。

4. C++ 侧状态变化  
在 `IdtPlug-in.cpp` 记录 `CheckPptCom`、`PptComService()` 返回值、`PptInfoState.TotalPage/CurrentPage` 从 `-1` 到有效或有效到 `-1` 的边沿变化。这里不用每 500ms 写一次，只写变化，日志会清爽很多。

5. 环境快照  
启动时写一次：Inkeys 版本、PptCOM 版本、系统版本、是否管理员、PowerPoint/WPS 进程列表、PowerPoint 路径、WPS 路径、相关 ProgID 解析出来的 CLSID。文件名和课件完整路径建议默认打码，只保留扩展名和 hash，避免用户隐私问题。

比“只写本地文件过程细节”更好的形式是：做一个可开关的诊断模式。比如检测 `opt/pptcom_trace_enable.flag` 或配置项存在才启用详细日志。这样可以发给用户一个诊断包，说明三步：放入文件、正常使用、复现后发回 `opt/pptcom_trace*.log`。

我会优先避免让用户装调试器或实时连线。这个问题最需要的是复现当刻的 COM/ROT 状态，而不是截图；一份好的 `PptCOM.cs + IdtPlug-in.cpp` 双侧日志基本就能判断是 busy 超时、ROT 选错对象、权限隔离，还是 UI 层没有响应。

对，用两个日志文件更稳。不要让 C# 和 C++ 争同一个 JSON 文件锁，尤其 PPTCom 是 COM/.NET 环境，C++ 侧又可能在高频线程里跑，单文件追加很容易出现锁等待、半行写入、编码差异或异常时 flush 不完整。

我建议这样设计：

- C# 侧：`opt/pptcom_trace_cs.jsonl`
- C++ 侧：`opt/pptcom_trace_cpp.jsonl`
- 公共会话文件：`opt/pptcom_trace_session.json`

日志本体用 `jsonl`，不是一个完整 JSON 数组。每行一条事件，追加写入，坏一行也不影响后面分析。

关键是两个日志要能对齐。`pptcom_trace_session.json` 里写一个 `sessionId`，例如 `20260530-143012-<pid>`，C++ 启动 PPTLinkageMain 时生成；C# 第一次 `Initialization()` 时读取同一个 session 文件。之后两边每条日志都带：

```json
{
  "sessionId": "...",
  "side": "cs",
  "ts": "2026-05-30T14:30:12.345+08:00",
  "pid": 1234,
  "tid": 5678,
  "event": "busy_retry",
  "stage": "检查放映窗口",
  "hr": "0x8001010A",
  "totalPage": -1,
  "currentPage": -1
}