[Bug]: 删除游戏时出错导致反复报错 Cannot read properties of undefined (reading 'name')

[mojimoon]

Software Version | 软件版本

4.6.0

Bug Description | 问题描述

背景

我尝试添加游戏 PriministAr，使用 VNDB 源。但由于网络缓慢，在加载背景图片（从 VNDB 的 10 张截图里选一张做背景大图）这一步还没有完成时我就退出了添加过程，更换网络环境，准备删除后再次添加。

但是疑似由于添加或删除过程中出现问题，导致 PriministAr 没有被真正删除。这之后直接从硬盘启动 PriministAr 后，反复出现以下致命问题。

问题描述

点击进入任何单个游戏（不限于 PriministAr）的详情界面均报错：

Cannot read properties of undefined (reading 'name')

应用重启后能重新进入主页面，但此问题仍然未解决。

日志分析

查看日志可见大量重复报错信息：

Unhandled rejection in event handler: TypeError: Cannot read properties of undefined (reading 'name')
at refreshTimerStatus (D:\ProgramData\Vnite\resources\app.asar\out\main\index.js:9556:60)
at async D:\ProgramData\Vnite\resources\app.asar\out\main\index.js:9545:5

请定位到此之前 （2026-02-06 22:44:09）的日志，见下方的 app-2026-02-06.log。

---

以下是我直接喂给 Copilot 做出的回答，你也可以参考一下。

根据提供的日志文件和代码分析，这个问题是由 "僵尸" 游戏监控进程 导致的。

简而言之：你（或系统）删除了一个游戏，但 vnite 的后台监控服务（Native Monitor）没有同步收到通知，仍然在监控该游戏的进程。当你运行这个已删除游戏的程序时，后台服务试图读取已不存在的数据库信息，导致程序内部报错并崩溃。

详细问题成因分析

1. 游戏被删除 (22:43:12):

   • 日志显示 ID 为 979067f8... 的游戏 "PriministAr" 被删除 (game:deleted)。
   • GameDBManager 成功从数据库中移除了该游戏的数据。

2. 监控服务未同步 (Bug 核心):

   • 经过代码排查，src/main/features/monitor/services/nativeMonitor.ts 文件中缺少对 game:deleted 事件的监听。
   • 这意味着，虽然数据库里删除了游戏，但底层的 C++/Native 进程监控模块并没有更新“已知游戏列表”。它仍然记录着 priministar_chs.exe 对应着 ID 979067f8...。

3. 游戏进程启动 (22:44:09):

   • 系统检测到 priministar_chs.exe 启动。
   • Native 监控模块触发回调，告诉主程序：“ID 为 979067f8... 的游戏启动了”。

4. 产生“僵尸”监控对象:

   • nativeMonitor 收到通知后，尝试为这个 ID 创建一个监控对象 (startPhantomMonitor)。
   • 尽管数据库中已无此游戏，但代码中的容错逻辑（或默认返回值）可能允许了这个“空壳”监控对象的创建，并将其加入到了全局的 monitors 列表中。

5. 致命错误 (22:44:09 及后续):

   • 程序试图更新所有运行中游戏的状态 (refreshTimerStatus)。
   • 该函数遍历 monitors 列表，并尝试从数据库获取每个游戏的元数据（如名称）。
   • 代码逻辑是：name: (await GameDBManager.getGame(gameId)).metadata.name。
   • 由于游戏已从数据库彻底删除，getGame(gameId) 返回了空对象或 undefined。
   • 尝试读取空对象的 .metadata 属性时，并未报错（得到 undefined），但在尝试读取 undefined.name 时，抛出了 TypeError: Cannot read properties of undefined (reading 'name')。

6. 持续报错:

   • 由于这个“僵尸”监控对象一旦加入 monitors 列表就没有被移除（因为报错中断了后续逻辑），之后每一次触发状态刷新（比如点击任何游戏详情、或者定时刷新），都会运行同一段代码，遍历到同一个不存在的游戏，再次抛出同样的错误，导致 App 功能瘫痪。

总结

这是一个典型的 状态不同步 (State Desynchronization) 问题。

• 根本原因: nativeMonitor 模块没有监听 game:deleted 事件来清理底层监控列表。
• 直接原因: refreshTimerStatus 函数在读取数据库结果时缺少空值检查（Null Check）。

修复建议 (针对开发者):

1. 在 nativeMonitor.ts 中添加对 game:deleted 的监听，一旦游戏删除，立即调用 updateKnownGames() 或移除对应的监控存根。
2. 在 refreshTimerStatus 中添加防御性代码，如果 getGame() 返回空，应自动将该无效的 monitor 从列表中移除，而不是让整个程序崩溃。

---

Error Log | 问题日志

完整日志: app.log

最相关部分：app-2026-02-06.log

Screenshots | 问题截图

1. 报错画面

2. 托盘右键菜单，能证明 PriministAr 没有被真正删除的直接证据

---

UPD: 我直接写了个 PR #489

[vilebbit]

感谢反馈，已成功复现 bug。
Native monitor 确实漏掉了处理游戏运行中被删除的情况。-> 转 PR 讨论

[mojimoon]

神奇的是，僵尸游戏之前没有在列表里显示，现在居然显示出来了。

并且删掉之后，该问题也就消失，进一步验证了问题的根源。

[fishyy119]

看上去和 #471 有一定共通之处，但是好像又有一些区别：

1. 该issue提供的log文件中貌似没有和本issue相似的报错
2. 该issue补充信息提到回退到<4.6版本问题消失，不知道本issue提到的问题表现如何

[mojimoon]

如何稳定复现这个问题？

添加一个游戏，删掉(取消勾选忽略该文件夹)，然后立即从硬盘启动，游戏列表出现这样的条目即复现成功

[mojimoon]

接下来我将尝试回退到 4.5.3

---

现象：vnite 点击幽灵条目和其他条目都没有报错

结论：确实是 4.6.0 版本引入了该问题

[mojimoon]

附上回退到 4.5.3 版本后的完整 log，可以看到也没有报错或者 warn

app.log

[fishyy119]

目前来看我倾向于认为这里有两个由幽灵游戏引发的不同问题：

1. 后端监听这里的游戏列表，refreshTimerStatus函数的代码的提交是比较早的（v4.5.0）（而且它既然被log捕获了，多半也不会继续传到外面让前端的渲染崩掉）
2. 前端的渲染失败，页面显示这里 “Cannot read properties of undefined”，这里应该是v4.5.3 -> v4.6.0 期间的其他代码导致的。我猜测多半和 RelatedGamesCard 组件相关，提交时间点吻合，同时其逻辑就是在打开游戏详情页时分析数据库中全部游戏计算相似度。不过我还没在本地尝试复现，已复现，就是这里的问题，已在 Optimize game detail page #478 中修复。

同时这样一来又有新的疑惑了，这说明问题可能不仅是在监听相关逻辑中，因为实际上它只是一个下游。数据库里产生了幽灵游戏才是根源。

稍微有些理解了，是这个监听器监听了数据库中被删除的游戏，导致游戏越过软件直接启动时向数据库回写了一个缺失各种必要字段的游戏条目（见下图，仅有 游玩状态 字段与计时器列表，其中 游玩状态 应该是自动对初次启动的游戏设置的，计时器列表是其本身职能），连带把其他地方没作防护的代码崩掉了。之前从来没用过这种越过软件直接从文件系统启动游戏的方式，也没往这边想。

另外，上条消息中的log好像没有回退后的日志？里面v4.5.3对应的启动日志都是几周前的。

[mojimoon]

另外，上条消息中的log好像没有回退后的日志？里面v4.5.3对应的启动日志都是几周前的。

最后是有的，从 2026-02-07 18:21:00 开始的部分就是。

你可以看到这么一行，说明目前是旧版本。但是这部分log没报错，确实没什么信息。

[2026-02-07 18:21:56.487] [info]  [AppUpdater] Discover the new version: 4.6.0

[fishyy119]

看到了，原来是日志里不会记录当前启动版本，只会记录最新版本检查的信息，我直接搜索的4.5.3的关键字。

不过这里没报错还是感觉有些奇怪啊，因为就像前面说的那样，这部分代码加入的时间早于4.5.3的版本，会不会是需要进行一些操作才会触发到这段代码？