音频巡检脚本的三次迭代：为什么"设备状态 OK"不等于音频可用

摘要

一批办公机的音频问题要一次性清一遍：有人在系统更新后找不到音频面板，有人报没声音，有人报插上耳机还是外放。这些机器分散在不同楼层，逐台去看不现实，于是写了个巡检脚本，按结果批量处置。

脚本改了三版。真正值钱的不是脚本本身，是三次误报逼我把判据重新排了一遍。 下面按版本记录。

v1：只看设备状态

第一版最直接，枚举媒体类设备，看有没有异常标记：

Get-PnpDevice -Class Media |
  Select-Object FriendlyName, Status, Class |
  Format-Table -AutoSize

跑完一遍，绝大多数机器都是 OK。按这个结果，结论应该是"这批机器音频层没问题"，但报修还在继续。

漏掉的是端点层。 设备状态 OK 只说明驱动正常、硬件被系统识别，不代表声音会送到用户正在用的那个设备上。默认输出停在已经拔掉的耳机上，设备列表照样全绿，用户照样听不到声音。

v1 的结论是"没问题"，实际问题是"问题不在这一层"。

v2：加上端点与默认设备

第二版补上默认播放设备的检查，用 AudioDeviceCmdlets 模块读端点信息：

# 需要先安装：Install-Module AudioDeviceCmdlets -Scope CurrentUser -Force
Get-AudioDevice -List |
  Where-Object { $_.Type -eq 'Playback' } |
  Select-Object Index, Default, Name |
  Format-Table -AutoSize

这一版抓出了"默认设备指向已断开端点"的机器，处置也简单：把默认切回实际在用的扬声器，一条命令结束。

但仍然有误报，原因是三类信息它拿不到：

• 被禁用的端点：禁用的设备不会出现在枚举结果里，脚本只会看到"少了几个设备"，判断不出是禁用还是不存在；
• 服务层：Audiosrv 或 AudioEndpointBuilder 没跑起来时，端点枚举可能为空，脚本会误判成"没有音频设备"；
• 界面层：报"找不到音频面板"的机器，脚本答不上来——面板属于哪套驱动体系、界面包在不在，v2 完全不看。

v3：分层输出，而不是给一个结论

第三版改成按层采集、按层输出。每一层对应一种处置动作，脚本不做判断，只把范围缩小：

function Get-AudioHealth {
    $r = [ordered]@{}
    $r.Time      = Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
    $r.Devices   = @(Get-PnpDevice -Class Media |
                     ForEach-Object { "$($_.FriendlyName)|$($_.Status)" })
    $r.Driver    = @(Get-CimInstance Win32_PnPSignedDriver |
                     Where-Object { $_.DeviceName -like '*Realtek*' } |
                     ForEach-Object { "$($_.DeviceName)|$($_.DriverVersion)|$($_.InfName)|$($_.DriverProviderName)" })
    $r.Endpoints = @(Get-AudioDevice -List -ErrorAction SilentlyContinue |
                     Where-Object { $_.Type -eq 'Playback' } |
                     ForEach-Object { "$($_.Name)|default=$($_.Default)" })
    $r.Console   = if (Get-AppxPackage *RealtekAudioControl*) { 'uwp-console' } else { 'none' }
    $r.LegacyUI  = if (Test-Path "$env:ProgramFiles\Realtek\Audio\HDA") { 'legacy-panel' } else { 'none' }
    $r.Services  = @(Get-Service Audiosrv, AudioEndpointBuilder |
                     ForEach-Object { "$($_.Name)=$($_.Status)/$($_.StartType)" })
    [pscustomobject]$r
}

Get-AudioHealth | Format-List

四层的处置分工：

v3 之后，一台机器的输出能直接决定要不要碰驱动。界面层显示 uwp-console 的机器，一律不动驱动——那类机器的"找不到面板"是驱动体系的正常结果，装了也不会出现。

输出怎么被消费

Format-List 是给人看的。要汇总成一张表，把函数结果转成 JSON 落盘更省事：

Get-AudioHealth | ConvertTo-Json -Depth 3 |
  Out-File "$env:USERPROFILE\audio-health.json" -Encoding utf8

字段名直接就是层名，汇总的时候不用再翻译一遍，一眼能看出这批机器卡在哪一层。这个约定是第三版才定下来的：字段名即分层名，比事后写映射表可靠。

为什么不把它做成常驻服务

试过做成开机自启的守护脚本，跑了两天撤掉了。原因是这批机器的音频问题是一次性的——系统大版本更新之后集中爆发，处理完就结束。常驻方案要额外处理权限、输出编码、自启开销，还得保证它自身不出故障，维护成本比它省下来的时间高。

脚本加一个计划任务，按周跑一次，结果落盘，够用。巡检类工具的价值在上限而不是下限，没有必要为它加一层常驻依赖。

判据的可靠性不一样，别混着用

最后一行是踩过的坑：早期版本拿版本号形态当判据，结果在一批 OEM 定制包上判断全错。能直接观测到的事实才是判据，推断出来的特征只能当线索。

修复动作的边界

• pnputil /delete-driver oemXX.inf /uninstall /force 是破坏性操作，它删的是系统驱动库里的真实条目。执行前确认能拿到对应的驱动包，别在唯一的机器上试；
• pnputil /add-driver "D:\drv\Realtek\*.inf" /subdirs /install 适合部署，比运行厂商的 setup.exe 可控：不出界面、退出码可判断。而 setup.exe 的静默参数没有通用答案，先执行一次 setup.exe /? 探测；
• 音频服务重启要按依赖顺序：先停 Audiosrv 再停 AudioEndpointBuilder，启动时反过来。顺序错了会留下半启动状态，表现为声音时有时无；
• RtkAudUService64.exe 对应的服务不要在排查里停掉。它负责插孔检测与设备状态上报，停了的典型后果是插孔检测失效、面板选项变灰——问题不会变好；
• OEM 驱动包不能跨品牌通用，批量部署要按机型分发；音频驱动更新后一般需要重启才生效，脚本里要么安排重启，要么在输出里写明。

部署时留意的三点

1. 权限：部分设备属性需要管理员权限才能读全，巡检脚本统一用提权方式跑；
2. 编码：输出含中文时先设 [Console]::OutputEncoding = [Text.Encoding]::UTF8，否则重定向到文件后容易乱码；
3. 频率：别把它放进每次登录都执行的启动项。日常巡检一天一次足够，高频执行反而会拖慢登录。

判据设计上我改掉的两个习惯

第一个：不再用"版本号"这类推断特征当判据。 换成能直接观测到的事实——设备状态、默认端点、界面包存在性、服务状态。

第二个：不再输出单一结论。 早期版本最后会给一句"正常/异常"，但"异常"这个词对处置毫无帮助。现在按层输出，看到哪一层不对，就知道该动哪里——音频问题的成本从来不在动手，而在动手前把范围缩到哪一层。

Realtek 高清晰音频管理器 最新下载

附录：平台免责声明

本文为开发者视角的技术实践记录，示例脚本仅用于说明巡检与判据设计思路；所涉软件、驱动与第三方组件版权归其各自开发者所有。文中涉及驱动包删除与卸载的操作具有破坏性，请先在测试机或可回退环境验证后再用于实际设备。