机械革命“自动修复”无法修复你的电脑

Windows 11 突然卡死黑屏、C 盘损坏无法启动：从 WinRE 修复到 WinDbg 定位 UCSI 固件异常的完整排查记录

这篇记录一下我最近一次比较完整的 Windows 故障排查过程。

故障表现是：

电脑正常使用过程中突然完全卡死，随后黑屏。重启后 Windows 无法进入系统，自动修复失败。

更麻烦的是，这并不是第一次发生。

上一次出现类似问题后直接重装了 Windows，之后正常使用了一段时间。这次再次出现后，我没有重装系统，而是从 Windows 恢复环境开始，一步一步检查磁盘、NTFS、事件日志、SMART、Live Kernel Dump，最后发现机器长期存在 UCSI / USB-C 平台固件通信异常。

目前尚不能 100% 证明 UCSI 就是本次卡死的直接原因，但已经找到了一条相当明确、反复出现的底层异常。

下面把整个过程和使用过的命令完整记录下来。

一、机器和故障背景

机器：

机械革命蛟龙 16S
平台/主板：GM6HG0X
Windows 11
系统盘：512 GB NVMe SSD
平时会连接 SanDisk Portable SSD 等 USB 外接存储

故障发生时没有刷 BIOS、改分区或者进行其他特殊操作，就是正常使用。

大致过程：

text 复制代码

正常使用
↓
突然卡死
↓
黑屏
↓
重新开机
↓
进入 Windows 自动修复
↓
"自动修复无法修复你的电脑"

因为上一次也是类似情况，最后靠重装系统解决，所以这次决定不重装，先找原因。

二、第一步：进入 WinRE，确认系统盘到底是哪一个

在自动修复界面进入：

text 复制代码

高级选项
→ 疑难解答
→ 高级选项
→ 命令提示符

进入以后命令行显示：

text 复制代码

X:\Windows\System32>

需要注意：

这里的 X: 不是系统盘。

这是 Windows Recovery Environment，也就是 WinRE 临时运行的恢复系统。

首先输入：

cmd 复制代码

diskpart

进入 Windows 自带的磁盘分区管理工具。

然后输入：

cmd 复制代码

list vol

作用是：

列出电脑当前所有卷，包括盘符、文件系统、容量等。

当时看到类似：

text 复制代码

卷 0   C:     Unknown   475 GB
卷 1          FAT32     200 MB
卷 2   D:     NTFS      907 MB

判断：

475 GB 的 C: 显然是 Windows 系统盘；
200 MB FAT32 是 EFI 启动分区；
907 MB NTFS 大概率是 Recovery 分区。

但最异常的是：

text 复制代码

C:   475 GB   Unknown

正常情况下应该显示：

text 复制代码

NTFS

所以第一怀疑是：

系统盘文件系统已经无法正常识别。

退出 DiskPart：

cmd 复制代码

exit

三、第二步：尝试直接读取 C 盘

执行：

cmd 复制代码

dir C:\

dir 就是列目录。

正常情况下应该看到：

text 复制代码

Windows
Users
Program Files
Program Files (x86)

但当时返回：

text 复制代码

磁盘结构损坏且无法读取。

这一步非常关键。

它说明问题已经不是：

"Windows 启动项没配好"

这么简单。

而是：

WinRE 连 C 盘自己的文件目录结构都无法正常读取。

四、第三步：排除 BitLocker 没解锁

因为 Windows 11 很多机器默认开启设备加密，所以还要排除：

是不是 C 盘其实只是 BitLocker 锁住了？

运行：

cmd 复制代码

manage-bde -status C:

结果显示类似：

text 复制代码

已加密百分比：100.0%
加密方法：XTS-AES 128
保护状态：保护关闭
锁定状态：已解锁

关键是：

text 复制代码

锁定状态：已解锁

所以问题不是：

BitLocker 没解锁导致读不了 C 盘。

此时可以继续查 NTFS。

五、第四步：先只读运行 CHKDSK

没有马上执行修复，而是先运行：

cmd 复制代码

chkdsk C:

这里没有加 /f。

原因是：

不带 /f 时主要用于检查，可以先观察文件系统到底坏成什么程度，而不主动修改。

CHKDSK 首先显示：

text 复制代码

文件系统的类型是 NTFS。

这其实是个好消息。

意味着：

C 盘并没有彻底变成 RAW，NTFS 的核心结构仍然能够识别。

随后开始检查：

text 复制代码

阶段 1：检查基本文件系统结构......
已处理 1132032 个文件记录。

但是之后出现大量：

text 复制代码

文件记录段 xxxx 是孤立项。

最后：

text 复制代码

发现错误。CHKDSK 无法在只读模式下继续。

说明：

NTFS 文件系统中存在大量元数据不一致，需要真正修复。

六、第五步：使用 CHKDSK /F 修复 NTFS

确认没有其他更安全的数据抢救需求后，运行：

cmd 复制代码

chkdsk C: /f

这里：

text 复制代码

/f

表示：

Fix，真正修复文件系统逻辑错误。

没有直接使用：

cmd 复制代码

/r

因为 /r 还会进行坏扇区扫描和数据恢复尝试，耗时和磁盘读写量明显更大。

本次 CHKDSK 修复过程中明确出现：

text 复制代码

正在更正主文件表(MFT)镜像的错误。
正在修复属性定义表的错误。
正在更正启动文件的错误。
正在更正主文件表(MFT) BITMAP 属性的错误。
正在更正卷位图的错误。

最后：

text 复制代码

Windows 已更正文件系统。
无需采取进一步操作。

并且：

text 复制代码

坏扇区 0 KB

所以直接可以确认：

C 盘 NTFS 元数据确实发生过严重损坏。

涉及的不是一个小目录，而包括：

MFT
MFT Mirror
Bitmap
Boot file
Volume bitmap

等 NTFS 核心结构。

七、第六步：重新确认 C 盘是否恢复

再次运行：

cmd 复制代码

dir C:\

这次已经正常出现：

text 复制代码

Program Files
Program Files (x86)
Users
Windows
...

也就是说：

文件系统重新恢复到了可以挂载、可以读取的状态。

然后退出命令提示符：

cmd 复制代码

exit

选择：

text 复制代码

继续
→ 退出并继续使用 Windows 11

Windows 成功进入系统。

八、第七步：系统进去了，但 C 盘却"拒绝访问"

进入 Windows 后又出现一个新问题：

资源管理器双击 C 盘提示：

text 复制代码

无法访问 C:\
拒绝访问。

这时候要区分：

到底还是文件系统坏了，还是权限坏了？

打开：

text 复制代码

Win + X
→ 终端（管理员）

先输入：

cmd 复制代码

whoami

作用：

查看当前执行命令的 Windows 用户。

然后：

cmd 复制代码

icacls C:\

icacls 是 Windows 用来查看和修改 NTFS ACL 权限的工具。

结果发现 C:\ 根目录权限中主要只有：

text 复制代码

NT AUTHORITY\SYSTEM:(F)
BUILTIN\Administrators:(F)

这里：

text 复制代码

F = Full Control

也就是：

SYSTEM 和 Administrators 有完全控制权限。

但是普通已登录用户正常访问根目录需要的 ACL 条目缺失。

这也解释了为什么：

管理员 PowerShell 可以 dir C:\，但普通权限运行的 Explorer 打不开 C 盘。

九、第八步：只修 C:\ 根目录 ACL

没有使用网上常见的：

cmd 复制代码

takeown /R

或者：

cmd 复制代码

icacls C:\ /reset /T

因为 /T 会递归修改整个系统盘，非常容易把 Windows、Program Files 等目录原本复杂的 ACL 权限体系全部搞乱。

只给 C:\ 根目录补权限：

cmd 复制代码

icacls C:\ /grant "Authenticated Users":(RX)

如果在 PowerShell 里括号解析出问题，可以写：

powershell 复制代码

icacls C:\ /grant "Authenticated Users:(RX)"

其中：

text 复制代码

Authenticated Users

表示已经通过 Windows 身份验证的用户。

text 复制代码

R = Read
X = Execute / Traverse

也就是：

允许正常登录 Windows 的用户读取和进入 C:\ 根目录。

执行完成以后再次：

cmd 复制代码

icacls C:\

确认 ACL 已增加。

随后资源管理器可以正常进入 C 盘。

到这里，电脑已经完全恢复可用。

十、问题虽然修好了，但为什么会坏？

因为这已经是第二次出现类似情况。

上一次：

text 复制代码

突然卡死
→ 黑屏
→ 系统坏掉
→ 重装 Windows

这一次：

text 复制代码

突然卡死
→ 黑屏
→ NTFS 严重损坏
→ CHKDSK 修复

所以很自然开始怀疑：

NTFS 损坏可能并不是最初的原因，而只是卡死后的结果。

于是继续查日志。

十一、第九步：查看 Windows 事件日志

按：

text 复制代码

Win + R

输入：

text 复制代码

eventvwr.msc

打开：

text 复制代码

事件查看器
→ Windows 日志
→ 系统

重点查看故障前后的：

关键
错误
警告

尤其关注来源：

text 复制代码

disk
Ntfs
stornvme
storport
WHEA-Logger
Kernel-Power
volmgr

发现了大量：

text 复制代码

disk
Event ID 51

内容：

text 复制代码

传呼期间在设备 \Device\Harddisk2\DR2 上检测到一个错误。

并且有：

text 复制代码

disk
Event ID 11

内容：

text 复制代码

驱动程序在 \Device\Harddisk2\DR2 上检测到控制器错误。

一开始因此很怀疑：

SSD 本身是不是坏了？

十二、第十步：确认 Harddisk2 到底是哪块盘

运行：

powershell 复制代码

Get-Disk | Format-Table Number,FriendlyName,SerialNumber,BusType,Size,HealthStatus,OperationalStatus

作用：

把 Windows 里的磁盘编号和实际设备对应起来。

结果发现：

text 复制代码

Disk 0 = 系统 NVMe SSD
Disk 2 = SanDisk Portable SSD

所以事件日志中的：

text 复制代码

Harddisk2

实际对应的是：

SanDisk 外置 SSD

而不是 C 盘。

所以 Event 11 / 51 虽然确实说明：

外接 SSD 或 USB 链路发生过真实 I/O / Controller 错误，

但不能直接证明：

系统 NVMe SSD 有问题。

十三、第十一步：检查系统 NVMe SSD SMART / Reliability

运行：

powershell 复制代码

Get-PhysicalDisk | Format-Table FriendlyName,MediaType,HealthStatus,OperationalStatus,Size

然后只针对系统盘检查：

powershell 复制代码

Get-PhysicalDisk |
Where-Object FriendlyName -like "*PC411*" |
Get-StorageReliabilityCounter |
Format-List Temperature,TemperatureMax,PowerOnHours,Wear,ReadErrorsTotal,ReadErrorsUncorrected,WriteErrorsTotal,WriteErrorsUncorrected

系统盘得到的数据大致为：

text 复制代码

Temperature              : 37
TemperatureMax           : 70
PowerOnHours             : 238
Wear                     : 0
ReadErrorsTotal          : 0
ReadErrorsUncorrected    : 0
WriteErrorsTotal         : 0
WriteErrorsUncorrected   : 0

所以：

目前没有找到系统 NVMe NAND/介质已经损坏的直接证据。

当然，这不能排除：

NVMe 控制器瞬态掉线；
PCIe 链路异常；
固件问题；
电源状态切换异常；

因为这类瞬间故障不一定会增加 SMART 的不可纠正错误计数。

十四、第十二步：一次性筛选故障前后的系统日志

为了避免在事件查看器里一条条翻，使用 PowerShell：

powershell 复制代码

$start = Get-Date "2026-08-13 22:30:00"
$end   = Get-Date "2026-08-14 01:30:00"

Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    StartTime = $start
    EndTime   = $end
} |
Where-Object {
    $_.LevelDisplayName -in @('Critical','Error','Warning') -or
    $_.ProviderName -match 'disk|stor|nvme|ntfs|volmgr|WHEA|Kernel-Power|Kernel-Boot|Kernel-General'
} |
Select-Object TimeCreated,Id,LevelDisplayName,ProviderName,Message |
Format-List

得到比较清楚的时间线：

text 复制代码

23:08 左右
电脑从 Modern Standby 唤醒

23:09
Harddisk2 Event 11

23:10
Harddisk2 连续大量 Event 51

00:33
Harddisk2 再次 Event 11

之后系统日志中断

01:08
系统重新启动

01:08
Kernel-Power Event 41

这里比较值得注意的是：

系统真正卡死时，并没有留下很完整的最后一条"死因"。

这在整机硬挂时并不少见。

十五、第十三步：分析 Kernel-Power Event 41

Kernel-Power 41 只表示：

上一次 Windows 没有正常关机。

它本身不是死机原因。

通过 PowerShell读取详细字段：

powershell 复制代码

$e = Get-WinEvent -FilterHashtable @{
    LogName='System'
    ProviderName='Microsoft-Windows-Kernel-Power'
    Id=41
} -MaxEvents 1

[xml]$x = $e.ToXml()

$x.Event.EventData.Data | ForEach-Object {
    "{0} = {1}" -f $_.Name, $_.'#text'
}

得到：

text 复制代码

BugcheckCode = 0
BugcheckParameter1 = 0
BugcheckParameter2 = 0
BugcheckParameter3 = 0
BugcheckParameter4 = 0

PowerButtonTimestamp = 0
LongPowerButtonPressDetected = false

WHEABootErrorCount = 0

这很重要。

因为：

text 复制代码

BugcheckCode = 0

意味着这次不是一个典型的：

text 复制代码

Windows发现致命错误
→ BugCheck
→ 蓝屏
→ 写 dump
→ 重启

更像是：

text 复制代码

系统整个失去响应
→ Windows来不及BugCheck
→ 异常重启

十六、第十四步：检查有没有蓝屏 Dump 或 Live Kernel Dump

运行：

powershell 复制代码

Get-ChildItem C:\Windows\Minidump -ErrorAction SilentlyContinue |
Select Name,Length,LastWriteTime

没有本次对应的 Minidump。

再看：

powershell 复制代码

Get-ChildItem C:\Windows\MEMORY.DMP -ErrorAction SilentlyContinue |
Select Name,Length,LastWriteTime

也没有。

但是运行：

powershell 复制代码

Get-ChildItem C:\Windows\LiveKernelReports -Recurse -File -ErrorAction SilentlyContinue |
Select FullName,Length,LastWriteTime |
Sort-Object LastWriteTime -Descending |
Select-Object -First 30

发现历史上存在：

text 复制代码

UcmUcsiCx.sys-20260723-1243.dmp

UcmUcsiCx.sys-20260624-1218.dmp

WATCHDOG-20260529-2158.dmp

AMD_WATCHDOG-20260402-1343.dmp
AMD_WATCHDOG-20260402-1342.dmp
AMD_WATCHDOG-20260402-1341.dmp
AMD_WATCHDOG-20260402-1340.dmp

UcmUcsiCx.sys-20260217-0726.dmp

PoW32kWatchdog...

这时候 UcmUcsiCx.sys 引起了注意。

因为它不是一次，而是：

text 复制代码

2 月
6 月
7 月

多次生成 Live Kernel Dump。

十七、第十五步：使用 WinDbg 分析 UCSI Dump

安装 Microsoft WinDbg。

例如打开：

text 复制代码

C:\Windows\LiveKernelReports\UcmUcsiCx.sys-20260723-1243.dmp

在 WinDbg 命令窗口输入：

text 复制代码

!analyze -v

结果：

text 复制代码

UCMUCSI_LIVEDUMP (1d4)

并明确写道：

text 复制代码

The UcmUcsi driver has encountered an error.
This is usually indicative of a problem with
the UCSI firmware on the platform or device.

其中一次：

text 复制代码

Arg1 = 1
Arg2 = 0x12

解释为：

text 复制代码

A UCSI command execution failed because
the UCSI firmware returned error or invalid data length.

故障分类：

text 复制代码

USB.UCM.UCSI.Desc = COMMAND_EXECUTION_FAILED
USB.UCM.UCSI.Driver = UcmUcsiAcpiClient

Failure Bucket：

text 复制代码

LKD_0x1D4_COMMAND_EXECUTION_FAILED_0x12_
UcmUcsiAcpiClient_
UcmUcsiCx!UcmUcsiCx::GenerateUcsiFailureDump

十八、第十六步：分析另一份 UCSI Dump

打开：

text 复制代码

UcmUcsiCx.sys-20260217-0726.dmp

再次：

text 复制代码

!analyze -v

这次不是 execution failed，而是：

text 复制代码

UCMUCSI_LIVEDUMP (1d4)

Arg1 = 0
Arg2 = 0x5

WinDbg 解释：

text 复制代码

A UCSI command has timed out because
the firmware did not respond to the command in time.

也就是说：

Windows 给 UCSI 固件发送命令，但固件直接超时没有响应。

Failure Bucket：

text 复制代码

LKD_0x1D4_COMMAND_TIMEOUT_0x5_
UcmUcsiAcpiClient_
UcmUcsiCx!UcmUcsiCx::GenerateUcsiFailureDump

十九、第十七步：发现 6 月和 7 月是完全相同的故障

6 月：

text 复制代码

COMMAND_EXECUTION_FAILED
Command = 0x12

7 月：

text 复制代码

COMMAND_EXECUTION_FAILED
Command = 0x12

两次的：

text 复制代码

FAILURE_BUCKET_ID

一致。

甚至：

text 复制代码

FAILURE_ID_HASH

也是完全相同。

说明：

Windows 把 6 月和 7 月两次异常识别为同一种故障。

因此 UCSI 问题不是一次随机事件。

至少可以确认：

text 复制代码

2 月：UCSI firmware command timeout

6 月：UCSI firmware command execution failed

7 月：完全相同 execution failure 再次出现

二十、第十八步：从调用栈判断到底哪一层在报错

WinDbg 的 STACK_TEXT 中可以看到类似：

text 复制代码

ACPI!DispatchNotificationWorker

UcmUcsiAcpiClient!
UcmUcsiAcpiClient::Acpi::NotificationCallback

UcmUcsiCx!
PpmNotificationReceived

UcmUcsiCx!
UnrecoverableFailureEncountered

UcmUcsiCx!
GenerateUcsiFailureDump

这条链路大致是：

text 复制代码

BIOS / EC / 平台固件
        ↓
       ACPI
        ↓
UcmUcsiAcpiClient
        ↓
   UcmUcsiCx
        ↓
   UCSI 命令
        ↓
固件没有响应 / 返回异常
        ↓
Windows 判断不可恢复
        ↓
生成 Live Kernel Dump

所以：

UcmUcsiCx.sys 更像是检测到问题并报警的组件，而不是一定意味着 Microsoft 这个驱动本身坏了。

真正更值得怀疑的是：

BIOS
EC
USB-C PD firmware
UCSI firmware
ACPI 实现
平台 USB-C 控制器

等下层组件。

二十一、第十九步：确认 Windows 里的 UCSI 设备

PowerShell：

powershell 复制代码

Get-PnpDevice | Where-Object {
    $_.FriendlyName -match 'UCSI|UCM|USB.*Connector|Type-C'
} |
Format-Table Status,Class,FriendlyName,InstanceId -Auto

结果：

text 复制代码

Status       : OK
Class        : UCM
FriendlyName : UCM-UCSI ACPI 设备
InstanceId   : ACPI\USBC000\0

所以确实存在：

text 复制代码

UCM-UCSI ACPI Device

二十二、第二十步：继续检查 UCSI 设备使用的驱动

运行：

powershell 复制代码

Get-PnpDeviceProperty -InstanceId 'ACPI\USBC000\0' |
Where-Object {
    $_.KeyName -match 'Driver|HardwareId|Manufacturer|Service'
} |
Format-Table KeyName,Data -Auto

得到：

text 复制代码

HardwareId:
ACPI\VEN_USB&DEV_C000
ACPI\USBC000
*USBC000

Service:
UcmUcsiAcpiClient

Manufacturer:
Microsoft

DriverInfPath:
ucmucsiacpiclient.inf

DriverProvider:
Microsoft

再运行：

powershell 复制代码

Get-CimInstance Win32_PnPSignedDriver |
Where-Object {$_.DeviceID -eq 'ACPI\USBC000\0'} |
Format-List DeviceName,DriverProviderName,DriverVersion,DriverDate,InfName,Manufacturer

可以看到：

text 复制代码

DeviceName         : UCM-UCSI ACPI Device
DriverProviderName : Microsoft
InfName            : ucmucsiacpiclient.inf
Manufacturer       : Microsoft

所以这里并不是：

少装了机械革命某个普通 USB-C 驱动。

而是：

Windows 内置 UCSI ACPI Client 正在和厂商平台固件进行通信。

二十三、第二十一步：查询机器 BIOS 和主板信息

PowerShell：

powershell 复制代码

Get-CimInstance Win32_ComputerSystem |
Select Manufacturer,Model

得到：

text 复制代码

MECHREVO
Jiaolong16S Series GM6HG0X

继续：

powershell 复制代码

Get-CimInstance Win32_BIOS |
Select Manufacturer,SMBIOSBIOSVersion,ReleaseDate

得到：

text 复制代码

BIOS：
N.1.04MRO09

日期：
2024-01-26

主板：

powershell 复制代码

Get-CimInstance Win32_BaseBoard |
Select Manufacturer,Product,Version

结果：

text 复制代码

MECHREVO
GM6HG0X

因此下一步排查重点已经不再是重装 Windows，而是：

查找 GM6HG0X 是否存在新版 BIOS / EC / USB-C PD / UCSI firmware。

二十四、目前可以确定什么

目前已经可以比较确定以下事实。

1. C 盘 NTFS 确实严重损坏过

CHKDSK 明确修复：

text 复制代码

MFT Mirror
Attribute Definition Table
Boot File
MFT Bitmap
Volume Bitmap

这不是主观猜测。

2. CHKDSK 修复后 Windows 可以直接恢复

没有重装 Windows。

仅：

cmd 复制代码

chkdsk C: /f

就成功恢复了 C 盘文件系统。

3. C:\"拒绝访问"是 ACL 问题

通过：

cmd 复制代码

icacls C:\

找到根目录 ACL 异常。

通过：

cmd 复制代码

icacls C:\ /grant "Authenticated Users":(RX)

恢复。

4. 外置存储链路确实有 I/O/Controller 错误

事件日志明确存在：

text 复制代码

disk Event 11
disk Event 51

对应：

text 复制代码

Harddisk2

而 Harddisk2 映射到 SanDisk Portable SSD。

5. 暂时没有证据证明系统 NVMe NAND 已经坏掉

Storage Reliability：

text 复制代码

ReadErrorsUncorrected = 0
WriteErrorsUncorrected = 0
Wear = 0

CHKDSK：

text 复制代码

坏扇区 = 0 KB

所以暂时不能直接下结论：

"系统 SSD 坏了。"

6. UCSI / USB-C 平台通信异常是实锤

历史存在多次：

text 复制代码

UCMUCSI_LIVEDUMP 0x1D4

包括：

text 复制代码

COMMAND_TIMEOUT

即：

firmware did not respond in time

以及：

text 复制代码

COMMAND_EXECUTION_FAILED

即：

firmware returned error or invalid data

而且跨数月重复发生。

所以：

这台机器至少长期存在 UCSI firmware / USB-C 平台通信异常。

这一点已经不是猜测。

二十五、目前还不能确定什么

目前仍然不能严格证明：

text 复制代码

UCSI故障
↓
直接导致8月这次整机卡死
↓
直接导致C盘NTFS损坏

因为本次真正死机那个时间点：

没有新 Minidump；
没有 MEMORY.DMP；
没有对应时间的新 UcmUcsiCx LiveDump；
Kernel-Power 41 的 BugcheckCode = 0。

所以本次整机挂死时：

Windows 很可能已经来不及记录真正的最后故障。

二十六、目前最合理的工作假说

现阶段我个人认为比较合理的一条链是：

text 复制代码

BIOS / EC / UCSI / USB-C平台存在间歇性异常
                    ↓
USB-C / 外接设备通信或电源状态异常
                    ↓
外接SSD出现Controller / I/O错误
                    ↓
系统在某些情况下严重卡死
                    ↓
黑屏 / 非正常重启
                    ↓
系统盘正在进行中的NTFS元数据写入被中断
                    ↓
MFT / Bitmap / Boot File 等结构不一致
                    ↓
下次启动无法读取C盘
                    ↓
自动修复失败

这里要强调：

后半段"异常关机 → NTFS 损坏"有直接证据。

而：

前半段"UCSI → 本次系统卡死"目前属于高度怀疑，但尚未完成最终因果证明。

二十七、下一步准备怎么处理

目前暂时采取：

不再重装 Windows；
先备份重要数据；
暂时拔掉 SanDisk Portable SSD，观察是否还会复现；
关注：

text 复制代码

C:\Windows\LiveKernelReports

是否再次生成：

text 复制代码

UcmUcsiCx.sys
AMD_WATCHDOG
WATCHDOG

等 dump；

关注事件查看器里是否再次出现：

text 复制代码

disk 11
disk 51
stornvme
WHEA-Logger

查询机械革命 GM6HG0X 是否存在更新的：

text 复制代码

BIOS
EC
UCSI firmware
USB-C PD firmware

二十八、如果有人遇到类似问题，可以先这样排

如果故障表现也是：

text 复制代码

Windows突然卡死
→ 黑屏
→ 自动修复失败
→ C盘打不开

不要第一时间格式化或重装。

可以先在 WinRE：

cmd 复制代码

diskpart
list vol
exit

确认系统分区。

然后：

cmd 复制代码

dir C:\

看 C 盘是否还能读取。

BitLocker：

cmd 复制代码

manage-bde -status C:

文件系统只读检查：

cmd 复制代码

chkdsk C:

确认有 NTFS 错误以后，再根据数据重要程度决定是否：

cmd 复制代码

chkdsk C: /f

如果修复后 Windows 能进，但 C 盘提示拒绝访问：

cmd 复制代码

icacls C:\

检查 ACL。

不要上来就：

cmd 复制代码

takeown /R

或者：

cmd 复制代码

icacls C:\ /reset /T

因为递归修改整个 Windows 系统盘权限风险很高。

二十九、最后总结

这次最大的收获其实不是"用 CHKDSK 修好了系统"，而是：

第一次重装系统只是把结果清掉了，并没有告诉我为什么会发生。

第二次故障以后，从：

text 复制代码

自动修复失败

一路追到：

text 复制代码

NTFS MFT损坏
↓
ACL异常
↓
disk Event 11/51
↓
Kernel-Power 41
↓
LiveKernelReports
↓
WinDbg
↓
UCMUCSI_LIVEDUMP 0x1D4
↓
COMMAND_TIMEOUT / COMMAND_EXECUTION_FAILED
↓
ACPI\USBC000\0
↓
UcmUcsiAcpiClient
↓
BIOS / EC / UCSI firmware

至少已经确认：

机器本身长期存在 UCSI / USB-C 平台固件通信异常。

至于这个异常是否就是这次整机卡死和 NTFS 损坏的最终根因，目前还需要继续观察和复现。

如果有同型号：

text 复制代码

机械革命 蛟龙16S
GM6HG0X

并且也出现过：

正常使用突然彻底卡死；
黑屏；
USB-C 外设异常；
Event 11 / 51；
C 盘 NTFS 损坏；
UcmUcsiCx.sys Live Kernel Dump；
UCMUCSI_LIVEDUMP (1d4)；
COMMAND_TIMEOUT；
COMMAND_EXECUTION_FAILED；

欢迎交流。

目前尤其想确认：

GM6HG0X 是否存在更新版 BIOS / EC / USB-C PD / UCSI firmware，以及是否有人升级以后解决了类似问题。