绿联 USB 蓝牙适配器频繁断连排查记：从事件日志到 CSR Harmony 驱动

Get-PnpDevice -Class Bluetooth | Where-Object { $_.FriendlyName -match 'Radio' }

FriendlyName          : Generic Bluetooth Radio
Status                : OK
厂商                 : Cambridge Silicon Radio Ltd.
驱动版本              : 10.0.19041.5848
驱动日期              : 2006/6/21
InstanceId            : USB\VID_0A12&PID_0001\5&47B74AE&0&2

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='BTHUSB';
  StartTime=(Get-Date).AddDays(-1)} |
  Where-Object { $_.Id -eq 18 } |
  Group-Object { $_.TimeCreated.ToString("HH:mm") } | Sort-Object Name

01:08  01:38  01:52  02:43
14:08  14:13  14:27  14:53  16:32  18:00
18:40  18:41                        ← 1 分钟内连断两次
20:45  20:46  20:47  20:50          ← 5 分钟内连断四次

powercfg /q SCHEME_CURRENT

powercfg /setacvalueindex SCHEME_CURRENT 2a737441-1930-4402-8d77-b2bebba308a3 `
  48e6b7a6-50f5-4782-a5d4-53bb8f07e226 0
powercfg /setdcvalueindex SCHEME_CURRENT 2a737441-1930-4402-8d77-b2bebba308a3 `
  48e6b7a6-50f5-4782-a5d4-53bb8f07e226 0
powercfg /setactive SCHEME_CURRENT

Generic Bluetooth Radio
 └─ USB 根集线器(USB 3.0)          USB\ROOT_HUB30\4&163CF0F&0&0
     └─ Intel(R) USB 3.20 可扩展主机控制器  PCI\VEN_8086&DEV_7AE0

Get-PnpDevice | Where-Object { $_.FriendlyName -match
  'eXtensible|Enhanced|Open Host Controller' }

(空 —— 没有 EHCI / OpenHCI，只有 xHCI)

USB\VID_0A12&PID_0001\5&47B74AE&0&2    OK
USB\VID_0A12&PID_0001\5&47B74AE&0&3    Unknown
USB\VID_0A12&PID_0001\5&47B74AE&0&4    Unknown
USB\VID_0A12&PID_0001\5&47B74AE&0&7    Unknown
USB\VID_0A12&PID_0001\5&47B74AE&0&14   Unknown

Windows 无法在本地适配器上存储蓝牙身份验证代码(链接密钥)。
启动时，蓝牙键盘可能无法在系统 BIOS 中工作。

Test-Path  → True
Get-Acl    → Owner=(空)，ACE 数=0
Get-ChildItem → 不允许所请求的注册表访问权

Get-WinEvent -FilterHashtable @{LogName='System';
  StartTime='2026-10-07 23:55:00'; EndTime='2026-10-08 00:01:00'} |
  Sort-Object TimeCreated

23:58:10  [BTHUSB] ID=18   蓝牙无线电被重新初始化
23:58:10  [BTHUSB] ID=34   （LE 外设模式警告，与本问题无关）

<blockquote> <p>环境：Windows 台式机 + 绿联 USB 蓝牙 4.0 适配器（CSR8510）+ 蓝牙音响 ｜ 关键词：BTHUSB ID=18、CSR Harmony、xHCI</p> </blockquote> <h2>一、现象</h2> <p>台式机用一枚<strong>绿联 USB 蓝牙 4.0 适配器</strong>连接蓝牙音响，放歌放着放着就断了。手动断开蓝牙再重连，声音立刻恢复——但过一会儿又会断。</p> <p>更烦人的是它断得毫无规律：有时十几分钟一次，有时一小时几次。一天下来，重连十几次是常态。</p> <blockquote> <p><strong>先说结论：</strong>问题不在系统设置，也不在音响，而在于 Windows 自带的 <code>Generic Bluetooth Radio</code> 通用驱动跑不稳这枚 CSR 芯片的适配器。换上绿联官方的 <strong>CSR Harmony 无线软件栈 2.1.63.0</strong> 后恢复正常。</p> </blockquote> <p>下面是完整的排查过程。走了不少弯路，弯路本身也值得记录。</p> <h2>二、先认识这个适配器</h2> <p>排查任何硬件问题，第一步是搞清楚它到底是谁。用 PowerShell 查设备实例：</p> <pre><code class="language-powershell">Get-PnpDevice -Class Bluetooth | Where-Object { $_.FriendlyName -match 'Radio' } </code></pre> <pre><code class="language-text">FriendlyName : Generic Bluetooth Radio Status : OK 厂商 : Cambridge Silicon Radio Ltd. 驱动版本 : 10.0.19041.5848 驱动日期 : 2006/6/21 InstanceId : USB\VID_0A12&PID_0001\5&47B74AE&0&2 </code></pre> <p>三个关键信息：</p> <ul> <li><code>VID_0A12&PID_0001</code> —— 这是 <strong>CSR8510 A10</strong> 芯片方案，蓝牙 4.0，绿联/奥睿科等白牌适配器最常见的方案；</li> <li>驱动名是 <code>Generic Bluetooth Radio</code>，厂商显示 CSR —— 意味着用的是 <strong>Windows 自带通用驱动</strong>；</li> <li>驱动日期 2006/6/21 —— 那是微软内置驱动包的日期，不是真实固件日期。</li> </ul> <p>「通用驱动」这个细节，最后被证明就是答案所在。但当时我还不知道。</p> <h2>三、第一轮：让事件日志把断连时刻全说出来</h2> <p>用户视角的「断连」很主观，但系统日志不会骗人。蓝牙无线电相关的日志挂在 <code>System</code> 下、来源为 <code>BTHUSB</code>：</p> <pre><code class="language-powershell">Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='BTHUSB'; StartTime=(Get-Date).AddDays(-1)} | Where-Object { $_.Id -eq 18 } | Group-Object { $_.TimeCreated.ToString("HH:mm") } | Sort-Object Name </code></pre> <p>一天之内的「重新初始化」时刻：</p> <pre><code class="language-text">01:08 01:38 01:52 02:43 14:08 14:13 14:27 14:53 16:32 18:00 18:40 18:41 ← 1 分钟内连断两次 20:45 20:46 20:47 20:50 ← 5 分钟内连断四次 </code></pre> <p><strong>一天 16 次</strong>，其中两簇是分钟级连续抖动——典型的「掉线 → 重连 → 再掉」。这些时间点，就是用户感知到的每一次「断了」。</p> <blockquote> <p><strong>这一步的价值在于：</strong>它把一个模糊的主观抱怨（「总是断连」）变成了一组可以精确对齐的客观时间戳。后面所有的假设，都要拿这些时间戳来检验。</p> </blockquote> <h2>四、第二轮：省电策略与 USB 口</h2> <h3>4.1 USB 选择性暂停</h3> <p>头号嫌疑永远是「省电策略把设备挂起了」。</p> <pre><code class="language-powershell">powercfg /q SCHEME_CURRENT </code></pre> <p>USB 设置子组下，<code>USB 选择性暂停设置</code> 的交流/直流索引都是 <code>0x1</code>（已启用）。顺手关掉：</p> <pre><code class="language-powershell">powercfg /setacvalueindex SCHEME_CURRENT 2a737441-1930-4402-8d77-b2bebba308a3 ` 48e6b7a6-50f5-4782-a5d4-53bb8f07e226 0 powercfg /setdcvalueindex SCHEME_CURRENT 2a737441-1930-4402-8d77-b2bebba308a3 ` 48e6b7a6-50f5-4782-a5d4-53bb8f07e226 0 powercfg /setactive SCHEME_CURRENT </code></pre> <p>回退就是把末尾的 <code>0</code> 改成 <code>1</code>。这一步该做，但<strong>它没有解决问题</strong>。</p> <h3>4.2 一个值得记下来的坑：ROOT_HUB30 ≠ USB 3.0 口</h3> <p>追溯适配器的父级链路时，看到的是：</p> <pre><code class="language-text">Generic Bluetooth Radio └─ USB 根集线器(USB 3.0) USB\ROOT_HUB30\4&163CF0F&0&0 └─ Intel(R) USB 3.20 可扩展主机控制器 PCI\VEN_8086&DEV_7AE0 </code></pre> <p>我当时据此断定「插在 USB 3.0 口上，会被 SuperSpeed 的 2.4GHz 底噪干扰」，并建议换到黑色 USB 2.0 口。用户照做了——然后我发现<strong>这个判断方法是错的</strong>。</p> <p>再查一遍主机的 USB 控制器：</p> <pre><code class="language-powershell">Get-PnpDevice | Where-Object { $_.FriendlyName -match 'eXtensible|Enhanced|Open Host Controller' } </code></pre> <pre><code class="language-text">(空 —— 没有 EHCI / OpenHCI，只有 xHCI) </code></pre> <p>这台机器<strong>只有 xHCI 一个控制器，连 USB 2.0 主控制器都不存在</strong>。在 xHCI 架构下，主板上<strong>所有</strong> USB 口——包括黑色 USB 2.0 口——全部挂在 <code>ROOT_HUB30</code> 下面。所以「父级是 ROOT_HUB30」<strong>不能</strong>用来判断插的是 USB 3.0 还是 2.0 口。</p> <blockquote> <p>⚠️ <strong>教训：</strong>在只有 xHCI 的现代主板上，用根集线器名字判断端口版本是无效指标。想确认端口速率，应该看设备自身的连接速度，而不是父集线器的名字。</p> </blockquote> <h3>4.3 顺手发现：幽灵设备实例</h3> <pre><code class="language-text">USB\VID_0A12&PID_0001\5&47B74AE&0&2 OK USB\VID_0A12&PID_0001\5&47B74AE&0&3 Unknown USB\VID_0A12&PID_0001\5&47B74AE&0&4 Unknown USB\VID_0A12&PID_0001\5&47B74AE&0&7 Unknown USB\VID_0A12&PID_0001\5&47B74AE&0&14 Unknown </code></pre> <p><strong>5 个实例，只有 1 个在线。</strong>每重新枚举一次，Windows 就留一个幽灵。这个数字后来成了重要线索——它侧面说明适配器被反复重置过很多次。</p> <h2>五、第三轮：一次误判与自我修正</h2> <p>注意到 <code>BTHUSB</code> 日志里每次都伴随一条 ID=18：</p> <pre><code class="language-text">Windows 无法在本地适配器上存储蓝牙身份验证代码(链接密钥)。 启动时，蓝牙键盘可能无法在系统 BIOS 中工作。 </code></pre> <p>于是去查蓝牙链接密钥的存储位置 <code>HKLM\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys</code>。在<strong>非管理员</strong>会话下，得到的结果是：</p> <pre><code class="language-text">Test-Path → True Get-Acl → Owner=(空)，ACE 数=0 Get-ChildItem → 不允许所请求的注册表访问权 </code></pre> <p>我一度据此断言「一个链接密钥都没存下来，这就是断连原因」。但继续推敲就发现问题了：</p> <table> <thead> <tr> <th>现象</th> <th>能推出的结论</th> </tr> </thead> <tbody> <tr> <td>能枚举且子项数 = 0</td> <td>真的为空 ✅</td> </tr> <tr> <td>抛「不允许所请求的注册表访问权」</td> <td><strong>只是没权限读，里面有什么根本不知道</strong> ⚠️</td> </tr> </tbody> </table> <p>我踩的是第二种。非管理员会话读 HKLM 受保护项，看到的一片黑不代表里面是空的。</p> <blockquote> <p>⚠️ <strong>教训：</strong>「读不到」和「不存在」是两回事。在权限不足的会话里对受保护资源下「为空」的结论，本质上是在拿测量工具的误差当测量结果。</p> </blockquote> <h2>六、转折点：一个关键提问</h2> <p>绕了两圈没有收敛之后，我换了一个问题问用户：</p> <blockquote> <p>断连是「放着不动几分钟就断」，还是「正在放歌突然断」？</p> </blockquote> <p>答案：<strong>「正在放歌突然断，手动断开蓝牙重新连接，声音就恢复了。」</strong></p> <p>这句话的信息量极大，因为它一次性否掉了好几个假设：</p> <table> <thead> <tr> <th>假设</th> <th>为什么被否掉</th> </tr> </thead> <tbody> <tr> <td>音箱空闲自动断蓝牙省电</td> <td>是播放中突然断，不是闲置时断</td> </tr> <tr> <td>链接密钥 / 认证问题</td> <td><strong>重连不需要重新配对</strong>，密钥工作正常</td> </tr> <tr> <td>2.4GHz 射频干扰导致链路超时</td> <td>见下一节，日志对不上</td> </tr> </tbody> </table> <p>尤其是「重连不用重新配对」这一条——它是最快的一票否决指标：认证数据要是真丢了，重连时必然会要求重新配对。</p> <h2>七、决定性证据：断连时刻 = 无线电复位时刻</h2> <p>拿 23:58:10 那次断连做样本，把前后 6 分钟内<strong>所有</strong>系统事件拉出来：</p> <pre><code class="language-powershell">Get-WinEvent -FilterHashtable @{LogName='System'; StartTime='2026-10-07 23:55:00'; EndTime='2026-10-08 00:01:00'} | Sort-Object TimeCreated </code></pre> <pre><code class="language-text">23:58:10 [BTHUSB] ID=18 蓝牙无线电被重新初始化 23:58:10 [BTHUSB] ID=34 （LE 外设模式警告，与本问题无关） </code></pre> <p><strong>断连那一秒，日志里只有「无线电重新初始化」这一件事。</strong></p> <p><code>ID=18</code> 只在蓝牙无线电（也就是那枚 dongle）重启时才会记录。它意味着：不是链路层超时（那不会引发无线电重启），不是音响的问题（音响不可能让 PC 端的 dongle 复位），而是 <strong>dongle 自己复位了，音频流是被复位掐断的</strong>。</p> <p>回头再对上另外两条证据，整个链条就闭合了：</p> <ul> <li>一天 17 次复位 —— 频率远超正常水平；</li> <li>5 个幽灵设备实例 —— 每复位一次，Windows 就记一个新实例。</li> </ul> <blockquote> <p>✅ <strong>根因：</strong>Windows 自带的 <code>Generic Bluetooth Radio</code> 通用驱动，跑不稳这枚 CSR8510 适配器，导致 dongle 反复复位。</p> </blockquote> <h2>八、解决：换官方 CSR Harmony 驱动</h2> <p>既然是驱动问题，就去厂商那里要驱动。绿联官网的驱动下载页：<a href="https://www.lulian.cn/download/22.html">UGREEN绿联 蓝牙4.0适配器驱动下载丨CM109</a></p> <table> <thead> <tr> <th>项目</th> <th>内容</th> </tr> </thead> <tbody> <tr> <td>文件版本</td> <td>最新版（CSR Harmony 无线软件栈 <strong>2.1.63.0</strong>）</td> </tr> <tr> <td>适用型号</td> <td>30443</td> </tr> <tr> <td>芯片方案</td> <td>CSR 芯片 蓝牙4.0 驱动</td> </tr> <tr> <td>文件大小</td> <td>397.8 MB</td> </tr> <tr> <td>更新时间</td> <td>2024-08-06</td> </tr> <tr> <td>产品页</td> <td><a href="https://www.lulian.cn/product/44-cn.html">www.lulian.cn/product/44-cn.html</a></td> </tr> </tbody> </table> <p>安装后重新配对音响，断联频率明显下降，日常使用恢复正常。</p> <blockquote> <p>✅ <strong>验证方式：</strong>修复后重跑同一条日志查询命令，<code>BTHUSB ID=18</code> 的出现次数就是最直接的指标——修复前一天 17 次，修复后应趋近于 0（或只在开机时出现一次）。</p> </blockquote> <h2>九、副作用：蓝牙界面变了</h2> <p>装上 CSR Harmony 后有一个需要适应的变化：<strong>Windows 自己的蓝牙 UI 被接管了</strong>。</p> <p>系统通知中心里原来的蓝牙开关不见了，蓝牙变成了一个托盘图标。右键它，看到的是 CSR Harmony 自己的菜单，而不是 Windows 的快捷开关：</p> <p><img alt="CSR Harmony 托盘菜单" src="/upload/bt-csr-harmony-tray.png" /></p> <p><em>托盘右键菜单：CSR Harmony 无线软件栈 2.1.63.0，提供「打开发现 / 添加 Bluetooth 设备 / 显示我的 Bluetooth 设备」等入口</em></p> <p>要搜索和连接新设备，走菜单里的「添加 Bluetooth 设备」，会打开下面这个界面。已配对的设备以 MAC 地址形式列在这里，右键设备可以「打开 Services / 刷新服务 / 删除设备 / 属性」：</p> <p><img alt="我的 Bluetooth 设备窗口" src="/upload/bt-csr-harmony-devices.png" /></p> <p><em>「我的 Bluetooth 设备」窗口——CSR Harmony 的设备管理界面，图中设备 dcd8:7c:02:56:32 即蓝牙音响</em></p> <p>也就是说，装了厂商驱动之后，蓝牙的日常操作入口从「Windows 设置 → 蓝牙和其他设备」变成了「托盘图标 → CSR Harmony」。习惯需要一点时间调整，但换来的是稳定，值。</p> <h2>十、复盘</h2> <p>整个排查走了三个弯：省电策略、USB 端口版本、注册表密钥权限。回头看，真正让问题收敛的只有两件事——</p> <h3>1. 把主观抱怨翻译成时间戳</h3> <p>「总是断连」没法定位问题，但「一天 16 次、时间点如下」可以。事件日志里的 <code>BTHUSB ID=18</code> 就是这类问题的天然锚点。</p> <h3>2. 用一次提问砍掉一半假设</h3> <p>「闲置时断」和「播放中断」指向完全不同的方向；「重连要不要重新配对」能一票否决所有认证类假设。与其在假设里打转，不如问一个能把假设分成两半的问题。</p> <h3>3. 三条可复用的经验</h3> <ul> <li><strong>不要把 ID=18 当噪声。</strong>它是「无线电重新初始化」的强信号，拿它和断连时刻做时间对齐，能一刀切开「链路层超时」与「设备复位」两类根因。</li> <li><strong>「读不到」不等于「不存在」。</strong>在权限不足的会话里，不要对受保护资源下「为空」的结论。</li> <li><strong>xHCI 机器上，ROOT_HUB30 判断不了 USB 2.0 / 3.0 口。</strong>没有 EHCI 的主板，所有端口都挂在同一个根集线器下面。</li> </ul> <hr /> <blockquote> <p>附：排查过程中用到的关键命令汇总——<code>Get-PnpDevice -Class Bluetooth</code>（设备与驱动信息）、<code>Get-WinEvent -FilterHashtable @{LogName='System';ProviderName='BTHUSB'}</code>（断连时刻）、<code>powercfg /q SCHEME_CURRENT</code>（USB 选择性暂停）、<code>Get-PnpDeviceProperty -KeyName DEVPKEY_Device_Parent</code>（USB 拓扑追溯）。</p> </blockquote>