There was a problem with WSL：移动应用时 Docker 停止的原因

通过 Windows 设置把 ChatGPT 移到其他盘时，Docker 因 WSL 错误停止。日志记录了准备应用存储位置期间整个盘被卸载的过程。只重启 Docker 就恢复了引擎。

出现的 WSL 错误

ChatGPT 移动后，Docker Desktop 显示以下错误。详细信息还显示，Docker 的 WSL 启动进程以退出码 135 结束。

There was a problem with WSL
An error occurred while running a WSL command.
Please check your WSL configuration and try again.

exit status 135

Docker Desktop 版本为 4.95.0，WSL 为 2.7.14.0。Docker 的数据 VHDX 在本次迁移前就已位于 D 盘，逻辑大小约 273GB。我们没有随着 ChatGPT 应用一同移动 Docker 数据。

长篇错误详情也包含前一晚启动时的日志。最初提示缺少componentsVersion.json的警告，发生在随后约 11 小时的正常运行之前。我们没有把第一条显眼警告直接当成原因，而是调查 Docker 实际停止前后的事件。

这个区别会改变处理方式。尽管消息要求检查 WSL 配置，本次核心问题却是正在使用的虚拟磁盘失去访问，而不是 WSL 设置错误。在修改设置或重新注册 WSL 前，我们先对齐时间戳并检查 Windows 事件。

准备目标位置时，整个 D 盘被卸载

关键是将 NTFS、AppXDeploymentServer 和 VHDMP 日志与常规 System 日志一起比较。下表列出保存的事件时间，采用日本标准时间，四舍五入至毫秒。

D 盘在 ChatGPT 应用包本身开始移动之前就被卸载了。Windows 准备将它用作应用存储位置时，影响的是整个盘。即使待移动的应用已经关闭，只要 Docker 在同盘的虚拟磁盘仍打开，Docker 也可能受到影响。

NTFS 记录的请求方是svchost.exe。将事件中的进程 ID 与故障前就已运行的同一进程以及 Windows 服务信息对照后，确定为StorSvc，即 Storage Service（存储服务）。它与注册应用存储位置的 AppX 进程不同，我们没有把两个进程视为同一个。

从开始卸载到重新挂载完成约 3.3 秒；从卸载成功到重新挂载完成约 0.17 秒。因此不能说 D 盘整整消失了 3.3 秒。问题在于，即使很短的操作，也可能中断对正在使用的文件的访问，使应用之后无法继续工作。

0xC000026E 揭示了什么

在 Microsoft 的NTSTATUS 定义中，0xC000026E表示STATUS_VOLUME_DISMOUNTED，意思是尝试对已卸载卷执行操作。Docker VHDX 读取失败时也出现了这个值。

WSL 内核记录也显示虚拟存储 READ 失败、设备离线，以及 containerd 因信号 7 崩溃。Windows 虚拟磁盘记录与最终的 WSL 关闭形成了一致的时间线。

Microsoft 的卷卸载文档说明，即使卷正在使用，也可能尝试卸载，对使用它的进程造成不可预测的影响。本次行为与这一一般特性一致。但我们没有取得显示调用该具体 API 的调用栈，因此尚未确定 Windows 内部的具体调用路径。

事件原因字段写的是User request。我们没有将其解释为有人点击了“弹出 USB”的证据。通过检查请求服务与时间线，才将它关联到 Windows 准备应用存储位置时的处理过程。

我们检查的同期 USB、PnP 等日志未提供支持物理断开并重新连接的证据。调查时磁盘状态也为 Healthy。这不保证 SSD 没有故障，但本次找到的直接故障链是 Storage Service 卸载卷后，VHDX 访问失败。

Microsoft 文档介绍的PackageVolume机制，是受支持的应用存储方式。即便如此，内置移动功能也不代表同盘其他应用能不受中断地继续运行。

Unity 同时出现 I/O 故障

同盘还有一个 Unity 项目，之后出现 Unity Bug Reporter。Application Error 记录显示，Unity Data Store 在 13:20:47–49 崩溃，早于 Docker 重启。异常为0xC0000006，底层 I/O 状态为0xC000026E。

Microsoft 将0xC0000006定义为STATUS_IN_PAGE_ERROR，表示因 I/O 错误，所需数据无法载入内存。底层状态包含与 Docker 故障相同的卷卸载值，这支持 Unity 受到同一磁盘不可用影响的结论。

但事件的文件名字段为空，因此未能确定 Unity 无法访问的具体文件。后续崩溃记录中出现 Unity.dll，单凭这一点也不能认定 DLL 损坏或需要重装。

我们没有立即重启 Unity，而是另行保全 5 个文件，总计约 8MB，包括已有场景备份、日志与转储。场景备份时间是当天 08:31，不能证明崩溃前未保存的工作已保留。此次调查也没有用保全文件覆盖原始项目。

这段时间线同样排除了“先重启 Docker，才把 Unity 弄坏”的说法。第一次 Unity Data Store 崩溃早于 Docker 重启。调查故障需要核对日志中的事件时间，而不能只依赖窗口出现的先后顺序。

仅重启 Docker 即恢复引擎

在本地保留足够追溯原因的日志，并确认 D 盘重新可访问后，我们只对 Docker Desktop 执行了一次重启，使用 Docker 官方 CLI。以下命令会影响正在运行的 Docker 工作，执行前应确认哪些进程需要保存或停止。

docker desktop restart --timeout 45

Docker 官方重启文档将--timeout描述为限制命令等待时间的选项，并不表示保证 45 秒内恢复。本次命令以退出码 0 完成。

随后使用docker version检查 Server 响应，得到 Engine 29.8.2。WSL 列表也再次显示 docker-desktop 为 Running。新的后端在 13:27 这一分钟内启动。

获取的列表中有 108 个容器：1 个运行中、106 个已退出、1 个已创建。我们没有批量启动停止的容器。引擎能响应，不等于每个项目的数据库和服务都恢复原样，因此所需服务的功能检查交由各自负责人执行。

恢复没有涉及恢复出厂设置、删除数据、注销 WSL 或重装。我们也没有关闭整个 WSL，以免影响 Docker 以外的工作，更没有将整套诊断数据上传到外部。重点是不要从错误画面直接跳到可能丢失存储数据的操作。

帮助定位原因的日志

最初只查 System 日志时，没有找到决定性的卷卸载记录。System 中没有，不代表 Windows 没有记录。将下列日志按时间排序，才把应用迁移准备与其他应用的 I/O 错误串联起来。

调查同类症状时，先记下操作时间、目标盘、Docker 虚拟磁盘位置与错误文字，有助于缩小范围。确认本机有哪些日志通道可用，并从现有记录读起。本次追查没有启用额外诊断设置，也没有重现引发故障的操作。

本文不公开用户名、用户 SID、设备序列号、凭据或容器环境变量。分享日志时，只提取必要时间、错误码及操作名称，也更容易理清原因。

迁移前应确定的事项

本次不足在于：迁移前的说明侧重停止和备份 ChatGPT，没有充分考虑 D 盘上已运行的 Docker 和 Unity。以后执行类似任务，会从整个盘的层面确定哪些工作需要停止。

1. 确认所有使用目标盘的进程。检查 Docker 和虚拟机磁盘、数据库、编辑器项目，以及其他持续打开 D 盘文件的进程。
2. 保留未保存的工作及恢复所需数据。确保活跃工作能够恢复，而不只是复制应用本体。
3. 选择可以停止使用该盘的进程的时间。涵盖其他聊天与其他负责人进行的工作，并防止迁移期间启动新进程。
4. 使用 Windows 支持的移动功能。不要修改 WindowsApps 或 WpSystem 的所有者与权限后，只手动移动文件夹。
5. 分别检查迁移与其他应用。按应用启动、保存项目、浏览器、Docker 引擎和所需服务的顺序，验证实际需要的功能。

日志确认，这是 D 盘首次注册为应用存储位置。但注册完成不代表同一故障以后绝不会再发生。我们没有为了测试而反复注册或卸载实际工作的磁盘，而是保留当前正常运行的配置。

将应用移到 D 盘，也不会把所有相关文件都集中到那里。本次应用本体和主要数据在 D 盘，正在使用的 CLI 等组件仍在 C 盘。整体存储布局与容量见ChatGPT 和 Codex 跨盘迁移记录。

迁移成功不代表其他应用未受影响

ChatGPT 应用本体成功迁到 D 盘，之后也检查了浏览器操作与保存项目。但在准备目标位置时，整个 D 盘曾被卸载，导致 Docker 等使用该盘虚拟磁盘的应用出错。单凭迁移成功事件，无法证明周边应用未受影响。

日志说明了本次直接故障链。尚未确定 Windows 内部哪条调用分支请求卸载，也未验证其他电脑或 Windows 版本是否出现相同行为。本案例支持的具体预防措施是：开始前，不仅停止待迁移应用，也要停止正在使用 D 盘的进程。

常见问题

重装 WSL 能修复“There was a problem with WSL”吗？

本次故障链是虚拟磁盘失去访问。只重启 Docker 就恢复了引擎，没有重装或注销 WSL。先检查故障时的日志，更有利于保护已有数据。

这代表 D 盘 SSD 坏了吗？

我们找到的是 Storage Service 卸载 D 盘的直接记录，没有找到同一时刻物理断开的记录。本案例没有依据断定 SSD 损坏。

应避免使用 Windows 内置应用移动功能吗？

将应用包移动到其他卷是 Windows 支持的功能。根据本次经验，我们会预留时间，停止同一目标盘上的其他应用、备份并检查，而不是在迁移时让它们继续运行。

Docker 能启动，就能认为一切都恢复了吗？

引擎响应与各容器中的服务、数据库内容是两回事。我们确认了引擎恢复并取得列表；所需项目的功能检查仍是独立任务。