一年多没碰的 Pico Neo 2,某个周二的下午我突然想戴上重温一下 VR。结果 SteamVR 一启动,pico 加载项直接崩溃——弹窗告诉我”由于最近的崩溃,某些加载项已被自动屏蔽”。问题是:一年前它明明是好的。我没升级过头盔、没换过串流助手,唯一变过的只有 Windows 和显卡驱动。
于是我做了一次完整的取证式排障:从 Windows 事件查看器,到 SteamVR 的 vrserver.txt 日志,再到网上的交叉验证,最终定位到一个相当”时代性”的根因——并用一个日本开发者刚发布 6 天的补丁临时修好了它。这篇文章把整个链条完整记录下来,给同样卡在 e06d7363 的人一个可复现的闭环。
一句话结论:不是 SteamVR 的问题,也不是头盔坏了。是 NVIDIA 驱动升级后移除了旧版 NVENC 编码器 API,而 Pico 串流助手用的还是 2022 年的旧预设 GUID,一调用就崩。修复方式是给它套一层 NVENC 兼容层。
症状:SteamVR 自动屏蔽 pico 加载项
最直观的现象就是这个弹窗。SteamVR 检测到 pico 加载项反复导致 vrserver.exe 崩溃,于是把它连同 prism、Gamepad Support 一起自动屏蔽了:
点”取消所有屏蔽”能让 pico 驱动重新加载,头盔甚至能被短暂识别——但几秒后又是同样的崩溃,SteamVR 又把它屏蔽回去。一个死循环。
先把环境交代清楚
排障第一步永远是”锁定变量”。我的软件版本和一年前基本没变,只有驱动一路自动更新了:
| 组件 | 版本 / 型号 | 备注 |
|---|---|---|
| 头盔 | Pico Neo 2 | 渲染目标 1664×1664 |
| Pico 游戏串流助手 | 7.2.3.0(特殊版本) | 已停止维护 |
| 显卡 | NVIDIA GeForce RTX 4090 | — |
| 显卡驱动 | 610.74 / CUDA 13.3 | ← 这就是变量 |
| SteamVR | 当前正式版 | — |
串流助手停留在 7.2.3.0 这个”特殊版本”,官网早已不再更新:
而显卡驱动已经悄悄爬到了 610.74——这是整个案子的关键。一年前我用的驱动大概还在 5xx 时代:
证据 #1:Windows 事件查看器
路径:事件查看器 → Windows 日志 → 应用程序 → 来源 Application Error(EventID 1000)。
当天一共 6 次崩溃,参数完全相同——这是”确定性崩溃”的典型特征,说明不是随机的内存问题,而是每次都走到同一行代码就爆:
| 时间 | 进程 ID | 异常代码 | 偏移量 |
|---|---|---|---|
| 15:31:50 | 0x8bec | e06d7363 | 0xc1ada |
| 15:32:32 | 0x618c | e06d7363 | 0xc1ada |
| 16:20:41 | 0xb06c | e06d7363 | 0xc1ada |
| 16:21:14 | 0xd814 | e06d7363 | 0xc1ada |
| 16:22:32 | 0xdef8 | e06d7363 | 0xc1ada |
| 17:17:21 | 0xdb9c | e06d7363 | 0xc1ada |
把每条记录展开,字段都指向同一个地方:
AppName = vrserver.exe
AppVersion = 1.1.1.0
ModuleName = KERNELBASE.dll
ExceptionCode = e06d7363 ← C++ 异常 (Visual C++ SEH exception)
FaultingOffset = 00000000000c1ada
AppPath = ...\SteamVR\bin\win64\vrserver.exe
ModulePath = C:\WINDOWS\System32\KERNELBASE.dll关键解读:
e06d7363不是普通的访问违规,它是微软 Visual C++ 抛 C++ 异常时的专用 SEH 代码(0xE0+"msc"的 ASCII)。崩在KERNELBASE.dll里,意味着某个被调用的底层 API 主动抛了异常——而不是程序自己写崩了。这一步就基本排除了”SteamVR bug”的方向。
证据 #2:SteamVR 日志 vrserver.txt
文件位置:...\Steam\logs\vrserver.txt。这份日志把崩溃的因果顺序完整记录了下来,分四个阶段。
阶段 A — 崩溃前:pico 被安全模式屏蔽
#3748 [Warning] Not loading driver pico because it was blocked
by a previous safe mode event这是点”取消所有屏蔽”之前的状态:SteamVR 因为上一次崩溃,自动进了安全模式屏蔽 pico。
阶段 B — 取消屏蔽后:pico 驱动加载,头盔被识别(17:17:20)
#4020 pico: driverpath ...\Streaming Assistant\driver\bin\win64\RVRPlugin.ini
#4028 pico: SetPoseDepth success
#4029 pico: VEncdll Load ← 加载视频编码插件
#4038 pico: driver_pico: Serial Number: Pico Neo 2 ← 头盔成功检测到
#4040 pico: driver_pico: Render Target: 1664 1664
#4042 ______COMPOSITOR_INITIALIZE______ ← 合成器开始初始化阶段 C — 崩溃瞬间(17:17:20.931)
#4043 Exception e06d7363 ← 砰!最妙的一个细节:从 COMPOSITOR_INITIALIZE 到 Exception e06d7363,中间只隔了 0.53 秒——这恰好是初始化 NVENC 硬件编码器所需的时间。崩溃点被精确地钉在了”调用 NVENC”这一刻。
阶段 D — 崩溃后:再次进入安全模式
#4049 Found saved crash timestamp -- Using safe mode
#4097 [Warning] Not loading driver pico because it was blocked
by a previous safe mode event于是又回到了阶段 A。死循环闭合。
证据 #3:网上的交叉验证
定位到 NVENC 之后,我去搜了一圈,发现不是我一个人。日本开发者 kakikou 在 2026-07-22 的一篇逆向分析里,贴出了与我逐行一致的崩溃模式:
Faulting application name: vrserver.exe
Faulting module name: KERNELBASE.dll
Exception code: 0xe06d7363
pico: VEncdll Load
pico: driver_pico: Serial Number: Pico Neo 2
______COMPOSITOR_INITIALIZE______
Exception e06d7363作者通过逆向确认了根因:Pico 的 VEncPlugin.dll 调用了已过期的 NVENC 预设 GUID,新版 NVIDIA 驱动直接拒绝执行。这与我的推断完全吻合——两份来自不同机器、不同人的日志,指向同一行代码。
根因分析:一个”时代性”的兼容断裂
把所有线索拼起来,因果链非常清晰:
Pico 串流助手(2022,已停产)→ 调用旧版 NVENC 预设 GUID → NVIDIA 驱动 582.xx 之后移除了这些旧 API → 驱动抛 C++ 异常 →
vrserver.exe崩溃 → SteamVR 自动屏蔽 pico
换句话说:软件停在过去,驱动走到了未来,中间的 API 桥断了。我的驱动已经是 610.74,远在 582 之后,所以必崩无疑。这也解释了为什么”一年前好好的”——一年前的驱动还认识那套旧 GUID。
根因时间线
| 时间 | 发生了什么 |
|---|---|
| 15:31 | 启动 SteamVR → 加载 pico 驱动 → VEncPlugin.dll 调用旧 NVENC 预设 → 驱动不认识 → 崩溃 |
| 15:32 | SteamVR 重启 → 检测到上次崩溃 → 自动屏蔽 pico → 弹出”加载项已被屏蔽” |
| 16:20–16:22 | 反复尝试,反复崩溃(事件查看器里那几条) |
| 17:17 | 点”取消所有屏蔽” → pico 重新加载 → 头盔识别成功 → 合成器初始化 → NVENC 初始化 → 再次 e06d7363 |
| 17:17 | SteamVR 再次安全模式 → 再次屏蔽 pico |
解决方案:NVENC 兼容补丁 PicoNeoCompat
好消息是,就在崩溃前 6 天,日本开发者 kakik0u 发布了开源项目 PicoNeoCompat,专门解决 582.xx 及以后驱动下 Pico Neo 2 / Neo 2 Eye 的这个崩溃。
它的思路很干净:不改动原始驱动,而是插入一层兼容 DLL,把旧的 NVENC 调用实时翻译成新版驱动能接受的格式:
PICO VEncPlugin.dll
│ 以 nvEncCompat64.dll 的身份被加载
▼
兼容补丁层
├─ 旧预设 GUID → P1–P7 + tuning info
├─ 已废弃的 RC 模式 → CBR / VBR + multipass
└─ NvEncGetEncodePresetConfig → ...ConfigEx(新版接口)
│
▼
System32\nvEncodeAPI64.dll(真正的 NVIDIA 驱动)重要:安装需要管理员权限。这个补丁的
Install.bat会复制 PICO 驱动、修改副本里的VEncPlugin.dll、并切换 OpenVR 的驱动注册指向——这些操作都要写入Program Files下的受保护目录,所以运行安装脚本时 Windows 会弹 UAC,必须选”是”。
安装步骤
| 步骤 | 操作 |
|---|---|
| 0 | 确认已装好 SteamVR + Pico 串流助手,并完全退出 SteamVR(检查任务栏托盘也没残留) |
| 1 | 从 Releases 下载 PicoNeoCompat-win64.zip 并解压 |
| 2 | 双击 Install.bat,在 UAC 弹窗选“是”(管理员权限) |
| 3 | 若驱动装在非默认路径,按提示输入,例如 C:\Program Files (x86)\Streaming Assistant\driver |
| 4 | 若 SteamVR 之前屏蔽过 pico:设置 → 启动/关闭 → 管理加载项 → 给 pico “取消屏蔽” → 重启 SteamVR |
如果默认的 Auto 编码设置画面卡顿,可以编辑 ZIP 内的 nvenc_compat.ini 调低负载(退出 SteamVR 后改,再重跑 Install.bat):
[NVENC]
Preset=P3
Tuning=LowLatency
MultiPass=Disabled作者在 NVIDIA 驱动 596.49 + RTX 3060 Ti 上测试通过。我这边是 610.74 + RTX 4090,补丁同样有效——头盔终于重新亮起来了。卸载也很简单:退出 SteamVR,双击 Uninstall.bat 即可还原原始驱动注册。
备选方案
| 方案 | 说明 | 适用 |
|---|---|---|
| PicoNeoCompat(推荐) | NVENC 兼容层,保留串流助手工作流 | 想继续用官方串流助手的人 |
| ALVR pico-legacy | ALVR 客户端的 Pico Neo 2 分支,更轻量;建议编码器用 HEVC、码率 50–100 Mbps | 愿意换一整套串流方案的人 |
| 回退 NVIDIA 驱动 | 降到 581.xx 或更早,让旧 GUID 重新可用 | 不推荐——会拖累其它需要新驱动的软件 |
写在最后:这次排障的方法论
这个案子之所以能干净闭环,靠的不是运气,而是一条固定的取证顺序:
先锁变量(软件没变、驱动变了)→ 看系统日志(事件查看器确认确定性崩溃 + 异常代码性质)→ 看应用日志(vrserver.txt 定位崩溃发生在 NVENC 初始化那 0.53 秒)→ 交叉验证(别人的日志逐行一致)→ 锁定根因(旧 NVENC GUID 被新驱动移除)→ 上补丁。
一个 e06d7363 看起来像天书,但只要顺着日志一层层剥,它最终会告诉你:软件停在了 2022 年,而你的显卡驱动已经活在 2026 年。
本文记录的是个人排障过程,PicoNeoCompat 为第三方非官方补丁,与 PICO / Valve / NVIDIA 无关,请自行评估风险后使用。