2.1 表面现象#

• 设备管理器里 Generic Bluetooth Radio 带黄色感叹号
• 属性显示：代码 31（CM_PROB_FAILED_ADD），提示”该设备无法启动”
• 直觉判断：驱动坏了 → 重装驱动 → 无效

2.2 关键证据：不是驱动问题#

# 驱动仓库里 bth.inf 完好
pnputil /enum-drivers | Select-String 'bth'
# 文件签名与版本正常
Get-AuthenticodeSignature 'C:\Windows\System32\DriverStore\FileRepository\bth.inf_amd64_4bae36cc9672513d\bth.inf'

驱动 bth.inf 版本 10.0.19041.5848，微软官方签名，文件完好无损。

决定性证据在系统日志：

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='BTHUSB'} -MaxEvents 30 |
  Select-Object TimeCreated,Id,Message | Format-List

BTHUSB 事件 ID 6：一次仅支持一个活动的蓝牙无线收发器。

这条日志的时间点与你插上模块的时刻精确吻合。

2.3 真因#

Windows 的蓝牙栈同一时刻只允许一个活动无线电。内置 Intel 蓝牙已经占住槽位，USB 模块在初始化阶段被拒绝，AddDevice 失败 → 报代码 31。

代码 31 有两种含义，必须区分：

• CM_PROB_FAILED_ADD + 有 BTHUSB 事件 6 → 无线电冲突（不是驱动问题）
• 只有代码 31 且无事件 6 → 才可能是驱动/硬件问题

2.4 修复流程#

# 1) 禁用内置蓝牙，腾出槽位
Disable-PnpDevice -InstanceId 'USB\VID_8087&PID_0AAA\5&F152990&0&14' -Confirm:$false

# 2) 移除模块的失败记录（关键，否则残留记录会干扰）
pnputil /remove-device "USB\VID_0A12&PID_0001\5&F152990&0&11"

# 3) 重新扫描硬件
pnputil /scan-devices

# 4) 验证
Get-PnpDevice -Class Bluetooth -PresentOnly |
  Where-Object InstanceId -match 'VID_0A12|VID_8087' |
  Select-Object Status,Problem,FriendlyName

2.5 ⚠️ 最容易踩的坑：先到先得#

这个限制是”先到先得”，不是”硬件好坏优先”。

实测：模块工作正常时再启用内置蓝牙 → 内置蓝牙立刻变成代码 31，日志同样报事件 6。

也就是说，“内置蓝牙用不了”不是它坏了，而是它抢不到槽位。

反过来做，两边互相报错，最后谁都用不了。

3.1 表面现象#

点「设置 → 蓝牙和其他设备 → 添加设备」，窗口一打开就瞬间消失，无任何报错提示。

Win+R → bthprops.cpl（传统控制面板）→ 点”添加设备”，同样秒退。

3.2 第一层误判：以为是搜索组件 SearchApp#

应用日志里确实有：

SearchApp.exe 在 Search.Core.dll 中崩溃
异常代码 0xc0000005（内存访问违规）  偏移 0x7205
24 小时内 13 次，偏移量和异常码完全一致

0xc0000005 + 固定偏移 = 确定性代码缺陷，不是硬件偶发。

但 bthprops.cpl 不依赖 SearchApp，它也会秒退 → 说明崩的不是搜索层。

3.3 真因：ShellExperienceHost 栈缓冲区溢出#

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Application Popup'} -MaxEvents 20 |
  Select-Object TimeCreated,Id,Message

ShellExperienceHost.exe - 系统在此应用程序中检测到基于堆栈的缓冲区溢出。

ShellExperienceHost.exe 是 Windows Shell 体验宿主，负责托管几乎所有系统弹窗面板，包括蓝牙”添加设备”向导。

溢出被 /GS 栈保护检测到 → 进程被强制终止 → 窗口瞬间消失。

3.4 🔑 为什么”没有崩溃日志”#

/GS 是主动终止进程，走的是弹框通告路径，不走 WER 崩溃上报。这就是为什么”查应用日志一片空白”—— 日志没丢，是根本不在那个通道里。

3.5 为什么换入口没用#

所有 UI 入口最终都汇聚到 DevicesFlowUI.dll 这一个组件，所以换入口无效。

应急方案（最快恢复配对能力）：

Win+X → 设备管理器 → 展开「蓝牙」→ 右键适配器 → 「添加蓝牙设备」

3.6 排查过程中的两次判断修正（重要）#

这个故障我判断错过两次，记录下来避免重犯：

修正 ①：曾经认为”包清单版本 vs 文件版本不一致”是版本错配

• 实际：包清单声明 10.0.19041.5072，exe 文件是 6280，相差 1208
• 但 Appx 清单版本与二进制文件版本本来就是两套体系，不要求相同
• 该目录下 12 个文件版本完全一致（全 6280），包内无混搭
• 教训：不要拿清单版本和文件版本直接比较

修正 ②：曾经认为 ucrtbase.dll 停在 3636 是”版本断层”

• 实际：查完更新历史（2023/11 至 2026/9 累积更新从未中断）后确认 —— 3636 就是 19041 分支的最终版本
• 微软后期累积更新不再改动 CRT
• 正常机器上 DevicesFlowUI.dll(6280) + ucrtbase.dll(3636) 就是这个搭配
• 教训：判断”版本过旧”前，先查更新历史确认该组件是否还有新版本

3.7 为什么 DISM / SFC 全都无效#

这是最有价值的一条经验。

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

实际结果：

原因三角：

1. SFC 只校验文件哈希，哈希合法就认为”没问题”——它检测不出”版本漂移”
2. C:\Windows\SystemApps\ 下的 Appx 包不在 SFC 修复范围（SFC 只管 WinSxS）
3. DISM /RestoreHealth 只从 WinSxS 或 Windows Update 拉取系统组件，不替换 Appx 包内容

所以在这类”版本漂移”故障里，DISM/SFC 会都报正常，而问题依旧。它们没坏，只是不在它们的能力模型内。

3.8 最终解决：统一组件版本#

真正的修复是让整套 Shell 组件回到同一补丁级别。

本次通过就地升级（重新部署系统镜像）到 19045.3803 实现：所有 Shell 二进制统一为 3803 级别，DevicesFlowUI.dll 与依赖组件重新对齐 → 栈溢出消失 → 秒退彻底解决。

⚠️ 代价必须说清楚：这是从 6456 回退到 3803，等于丢掉近两年的安全补丁。这不是”标准升级”，而是”用旧镜像重装”。正确的做法是用同版本或更新版本的 ISO 做就地升级，才能既修复又不降级。

标准就地升级步骤：

1. 微软官网下载 Media Creation Tool → 选择「为另一台电脑创建安装介质」→ 生成 ISO
2. 双击 ISO 挂载，运行 setup.exe
3. 关键：务必勾选「保留个人文件和应用」
4. 全程 40–60 分钟，多次重启，不可断电
5. 期间会关闭所有程序（包括正在使用的远程工具）

备用方案（未验证，成本最低）：

Get-AppxPackage Microsoft.Windows.ShellExperienceHost | Reset-AppxPackage
Get-AppxPackage Microsoft.Windows.Search | Reset-AppxPackage

4.1 这是同一个根因#

搜索框的”无反应”，日志表现是：

SearchApp.exe 在 Search.Core.dll 中崩溃
0xc0000005 @ 0x7205，24 小时内 13 次
相对应用程序 ID = CortanaUI

SearchApp.exe 与 ShellExperienceHost.exe 共用同一批 Shell 组件（XAML、组合器、Shell 契约层），崩溃节奏完全同步（9<09>–9<19> 崩 13 次，9<31>–9<36> 栈溢出 4 次）。

所以这不是两个 bug，是一件事。

4.2 为什么以前怎么修都没用#

常见的”修搜索框”手段全部无效，原因很具体：

核心原因：所有人（包括我一开始）都在”修复文件”，而实际问题是”组件版本不齐”。

4.3 解决#

与现象 B 同一次修复：Shell 组件统一版本后，SearchApp 与 ShellExperienceHost 同时恢复正常。

验证方法：

# 崩溃频率归零即解决
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Application Error';
  StartTime=(Get-Date).AddHours(-1)} |
  Where-Object { $_.Message -match 'SearchApp|ShellExperienceHost' } |
  Select-Object TimeCreated,Message

5.1 症状发展过程#

关键陷阱：设备管理器里 Status 一直显示 OK、ProblemCode = 0，但设备实际已死。

状态字段只反映 PnP 注册状态，不反映设备是否还在响应。永远以功能测试为准，不要相信 Status。

5.2 真因：USB 选择性挂起#

$p = 'HKLM:\SYSTEM\CurrentControlSet\Enum\USB\VID_0A12&PID_0001\<实例号>\Device Parameters'
Get-ItemProperty $p | Select-Object DeviceSelectiveSuspended,SelectiveSuspendEnabled

读到：

DeviceSelectiveSuspended : 1     ← 模块正在被 USB 节能挂起

系统把它判定为空闲 → 切断供电 → 它再也醒不过来。这就是周期性 HCI 超时的直接原因。

5.3 修复#

$p = 'HKLM:\SYSTEM\CurrentControlSet\Enum\USB\VID_0A12&PID_0001\<实例号>\Device Parameters'
foreach($n in @('SelectiveSuspendEnabled','EnhancedPowerManagementEnabled','AllowIdleIrpInD3')){
  New-ItemProperty -Path $p -Name $n -PropertyType DWord -Value 0 -Force
}

注意事项：

• 换了 USB 口，实例号会变（本次 &0&11 → &0&2），旧设置随之失效，必须重设
• 该设备在 root\wmi MSPower_DeviceEnable 中没有实例，所以无法用 CIM 设置，只能走注册表
• 设置需重新插拔或重启后才完全生效
• 卡死后软件无法复位，只能物理拔插

5.4 硬件层面的建议#

• 优先插黑色 USB 2.0 口：USB 3.0 的辐射噪声正好落在 2.4 GHz，与蓝牙同频
• 台式机后置面板是金属，会遮挡信号 → 用短延长线引到桌面
• 不要用 USB Hub 转接

6.1 症状#

• 已配对的耳机、键盘连接正常（在桌面 1 米内）
• 但打开”添加设备”0 台

6.2 判据：被动 BLE 扫描测 RSSI#

BLE 广播是持续的（手机、手表、电视都在广播），不需要目标设备进入配对模式就能收到。

# pip install bleak
import asyncio
from bleak import BleakScanner

async def main():
    found = {}
    def cb(dev, adv):
        found[dev.address] = (dev.name or "", adv.rssi)
    async with BleakScanner(detection_callback=cb):
        await asyncio.sleep(30)
    for a,(n,r) in sorted(found.items(), key=lambda x:-x[1][1]):
        print(f"{r:>5} dBm  {a}  {n}")

asyncio.run(main())

6.3 实测对比#

参照系：

• -50 dBm ≈ 贴身
• -70 dBm ≈ 同房间
• -90 dBm 以下 ≈ 几乎收不到
• 正常环境手机同位置应可见 20+ 个设备，最强在 -60 ~ -75

同期 Wi-Fi 扫描佐证：最强 AP 仅 60%（≈ -70 dBm），其余 14%–57%。

6.4 结论与排查点#

台式机 + Intel CNVi 模块：Wi-Fi 与蓝牙共用外置天线，但走不同支路。

只接 Wi-Fi 那一根天线时：Wi-Fi 表现为”能用但偏弱”，而蓝牙近乎聋 —— 完美对应”能连近处、搜不到远处”。

要检查两个地方：

1. 机箱后置 I/O 面板：两个金色 RP-SMA 螺纹接口，两根都要拧紧（只接一根不算完）
2. 机箱内部网卡：M.2 无线小卡上有两根极细 U.FL 馈线（一黑一白 MAIN/AUX），确认两根都扣紧。搬机箱、装显卡时极易碰掉

6.5 ⚠️ 一个必须澄清的对比误区#

“手机能看到很多设备，电脑一台看不到” —— 这个对比本身不公平。

正确测试方法：把目标设备主动进入配对模式（耳机通常长按 5–10 秒直到指示灯快闪），再搜索。

7.1 为什么必须清#

旧配对记录挂在旧无线电上，链路密钥对新无线电无效。系统会后台反复重连 → 拖住 HCI 通道，加剧超时。

7.2 正确顺序：先删 PnP 节点，再删注册表键#

顺序反了，设备节点会重新写出注册表键，白删。

# ① 备份（reg.exe 可能被安全策略拦截，用 PowerShell 原生导出）
$root = 'HKLM:\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Devices'
Get-ChildItem $root | ForEach-Object {
  "[$($_.PSChildName)]"
  (Get-ItemProperty $_.PSPath).PSObject.Properties |
    Where-Object Name -notlike 'PS*' |
    ForEach-Object { "  $($_.Name)=$($_.Value)" }
} | Out-File 'bthport_devices_backup.txt' -Encoding UTF8

# ② 移除设备节点（非在线、非目标设备）
Get-PnpDevice | Where-Object {
  $_.InstanceId -match '^(BTHENUM|BTHLE|BTHHFENUM)\\' -and $_.Present -ne $true
} | ForEach-Object { pnputil /remove-device $_.InstanceId }

# ③ 删除注册表键（保留要用的那台）
$keep = '<目标设备地址，12位十六进制，无冒号>'
Get-ChildItem $root | Where-Object { $_.PSChildName -ne $keep } |
  ForEach-Object { Remove-Item $_.PSPath -Recurse -Force }

# ④ 验证
(Get-ChildItem $root).Count    # 应为 1

7.3 本次清理结果#

清理内容：PaMu 全链路（Stereo / Hands-Free AG / Avrcp ×2）、Baseus Bowie M2s 全链路、ikbc W210、10 条无名称历史残留、6 个蓝牙串口占位（COM3–COM8）、1 个 Airoha App 残留。

8.1 五条硬经验#

① 代码 31 不等于驱动坏。
先查 BTHUSB 事件 6。有它 = 无线电冲突；没它 = 才轮到怀疑驱动。

② 状态字段会骗人。
Status=OK / ProblemCode=0 只代表 PnP 注册正常。设备死了照样显示 OK。判定必须靠功能测试（能不能扫到设备），不靠属性面板。

③ 栈溢出不在崩溃日志里。
“查应用日志一片空白” ≠ “没有崩溃”。/GS 保护走 Application Popup ID 26，不走 Application Error 1000。查崩溃要同时看这两个 Provider。

④ DISM / SFC 只修”损坏”，不修”不齐”。
它们校验哈希合法性。版本漂移、Appx 包内容、服务阶段未完成，全部在能力范围之外。它们报”未检测到损坏”是如实汇报，不是工具失效。

⑤ 同一个现象可能有完全不同的层。
“搜索框没反应”可能崩在：输入法层 / 索引层 / 搜索服务层 / UI 宿主层。本次崩在最下面的 UI 宿主（ShellExperienceHost）。定位方法：看崩溃模块名（Search.Core.dll）出现在哪个宿主进程里，而不是看现象名称。

8.2 排查动作优先级#

1. 看事件日志的 Provider（BTHUSB / Application Popup / Kernel-PnP）
   → 而不是从现象名称反推
2. 用"绕过界面"的方式做功能测试（Python/命令行直接调 API）
   → 区分"硬件搜不到"和"界面显示不出"
3. 对比时间戳：日志时间 vs 用户操作时间
   → 因果链自然浮现
4. 最后才动文件（DISM/SFC/重装）

8.3 一个反面教材#

本次排查中我判断修正了三次（包清单版本、CRT 版本断层、就地升级方向），全部源于在没有充分证据时提前下结论。

正确做法：每下一个结论前，先问”如果这个结论错了，什么证据会推翻它”，然后去拿那个证据。

当前配置#

已知限制（CSR8510 廉价方案特征）#

待办#

• 把音量输出切到 Baseus Bowie MP1 Stereo（默认仍是 Realtek 音箱）
  —— 不要选 Hands-Free AG，那是单声道低质量通话链路
• 检查并拧紧主板后置的两根天线（如要回到内置蓝牙）
• 考虑用更新版本的 ISO 做一次就地升级，把 3803 补回 6456+ 的安全补丁
• 若需 reg.exe：到「安全中心 → 命令安全 → 程序黑名单」移除