Docker Desktop启动失败需查三类日志：%LOCALAPPDATA%\Docker\log.txt（客户端操作）、%PROGRAMDATA%\DockerDesktop\service.txt（后台服务状态）及WSL层日志；首要执行wsl --list --verbose确认docker-desktop状态与版本，再结合Get-Service WSLService和事件日志定位根因。
启动失败时，日志根本不在 Docker Desktop 界面里
你点开 Docker Desktop 设置里的 Diagnostic 或右下角鲸鱼图标 → Support，看到的只是摘要和上报入口，不是原始日志。真正记录启动卡在哪一步的，是 Windows 服务日志 + WSL 启动痕迹 + Docker Desktop 自身的 debug 日志文件，三者缺一不可。
关键路径有三个：
-
%LOCALAPPDATA%\Docker\log.txt：主客户端日志，记录界面操作、配置加载、服务连接尝试，比如反复出现Failed to connect to docker daemon就说明还没走到引擎层 -
%PROGRAMDATA%\DockerDesktop\service.txt：后台服务com.docker.service的输出，START_PENDING 卡住时这里常有Waiting for WSL2 VM...或Failed to start engine: timeout - WSL 层日志需手动触发：
wsl -d docker-desktop -u root cat /var/log/docker.log（如果发行版能进），但多数情况下这步会失败——因为wsl -l -v显示状态是STOPPED或START_PENDING，得先让它跑起来才能读
wsl --list --verbose 是第一道诊断命令
它不打印日志，但它告诉你整个链条最底端是否就绪。Docker Desktop 启动失败，80% 的情况在这一步就能定位到根因。
执行后重点关注三列：
-
NAME列是否包含docker-desktop和docker-desktop-data（新版本可能只显示前者） -
STATE列是否为Running；若为STOPPED，说明 WSL2 底层没拉起；若为START_PENDING，说明 WSL 服务（WSLService）卡在初始化，大概率是虚拟化没开或磁盘权限异常 -
VERSION列是否为2；如果是1，Docker Desktop 会拒绝启动，即使界面没报错
如果 wsl --list --verbose 命令本身卡住或报错，问题已下沉到系统级：检查 Get-Service LxssManager（旧版）或 Get-Service WSLService（新版）是否 Running，以及 dism /online /get-features | findstr "Linux" 是否确认两个功能都已启用。
com.docker.service 服务日志要结合 Get-Service 看
Windows 服务面板里看到 com.docker.service 状态是 START_PENDING，不代表它真在“启动中”，更可能是死锁或等待超时。直接看它的日志比刷新服务管理器有用得多。
管理员 PowerShell 中运行：
Get-EventLog -LogName Application -Source "Docker Desktop Service" -Newest 50
常见线索包括：
-
Failed to launch WSL distribution 'docker-desktop': exit code: 42→ WSL 发行版注册损坏，需wsl --unregister docker-desktop后重启 Docker Desktop 触发重建 -
Failed to start com.docker.service: The service did not respond to the start or control request in a timely fashion→ 通常是VirtualMachinePlatform功能未真正生效，或 BIOS 虚拟化被禁用（任务管理器性能页看不到“虚拟化: 已启用”） - 空日志或只有
Service started无后续 → 服务进程启动了但没往下走，大概率是 WSL2 内核没加载，运行wsl --update并重启
别信“重启大法”，先查磁盘和临时目录是否被安全软件锁死
0x80070570 和 1603 错误背后，90% 是文件系统层面的问题，而不是 Docker 或 WSL 代码缺陷。
典型诱因：
- 杀毒软件（尤其是 McAfee、Bitdefender、火绒）把
%LOCALAPPDATA%\Docker或%USERPROFILE%\AppData\Local\Packages\下的 AppX 缓存目录加了写保护 - 磁盘坏道或 SSD 寿命告急，导致
docker-desktop-data的ext4.vhdx文件读取校验失败 - Windows Update 过程中强制释放了
%TEMP%，而 Docker Desktop 安装/升级时正往那里解压 MSI 临时文件，残留锁句柄没释放
验证方法很简单：以管理员身份运行 chkdsk C: /f（需重启），再用 resmon.exe 打开“资源监视器” → “CPU”页 → “关联的句柄”，搜索 docker 或 vhdx，看是否有进程长期占用却无响应。
