Win10-11日志警告⚠️Dcom错误：Microsoft.Windows.ShellExperienceHost_10.0.19041.5072_neutral_neutral错误的跟踪与分析

我的Win10日志中一直出现如下的警告(如下日志中的sid我做了处理和大家可能不同)
计算机-默认 权限设置并未向在应用程序容器 Microsoft.Windows.ShellExperienceHost_10.0.19041.5072_neutral_neutral_cw5n1h2txyewy SID (S-1-15-xxxxxxxxxxxxx)中运行的地址 LocalHost (使用 LRPC) 中的用户 DESKTOP-G2PR2F2\Donglxd SID (S-1-5-21-xxxxxxxxxxxxx)授予针对 CLSID 为
{C2F03A33-21F5-47FA-B4BB-156362A2F239}
、APPID 为
{316CDED5-E4AE-4B15-9113-7055D84DCC97}
的 COM 服务器应用程序的 本地 激活 权限。此安全权限可以使用组件服务管理工具进行修改。
通过微软日志记录工具sysmon跟踪发现和微软的底层音频程序有关，sysmon相关日志如下(日志中有些部分我做了隐私处理)：
Process Create:
RuleName: -
UtcTime: 2025-10-16 08:49:50.066
ProcessGuid: {eefdf14a-b1ae-68f0-3b01-00000000bb02}
ProcessId: 4028
Image: C:\Windows\System32\audiodg.exe
FileVersion: 10.0.19041.5794 (WinBuild.160101.0800)
Description: Windows Audio Device Graph Isolation
Product: Microsoft® Windows® Operating System
Company: Microsoft Corporation
OriginalFileName: audioadg.exe
CommandLine: C:\WINDOWS\system32\AUDIODG.EXE 0x6b4 0x6fc
CurrentDirectory: C:\WINDOWS\system32
ParentImage: C:\Windows\System32\svchost.exe
ParentCommandLine: C:\WINDOWS\System32\svchost.exe -k LocalServiceNetworkRestricted -p

根据我的一些测试发现，确实和这个音频控制程序audiodg.exe有关，触发这个警告日志的过程如下，当win10右下的消息窗口出现消息、使用任务栏上音量调节、U盘退出后的弹出提示窗口，这些操作需要微软的UWP通过Dcom分布式服务调用底层音频端口audiodg.exe，有人可能搞不懂，为什么UWP要调用Dcom分布式服务来驱动系统音频程序。简单的说，“UWP” 是 Windows 10 和 Windows 11 上的一个重要应用平台，全称是 “Universal Windows Platform”，中文一般叫“通用 Windows 平台”，简单的说它是微软的新UI语言，微软在设计此之初，是想替代win32，但是实际效果有限，虽然现在不流行了，但是win10-11的很多消息、设置、系统界面都使用了UWP。UWP运行在名叫AppContainer沙箱中，可以单独设置权限，包括摄像头、麦克风、隐私等权限。而Dcom可能大家不太熟悉，但是这个技术老早就有了，属于com接口技术的一种分布式拓展，可以通过客户端调用服务端的远程服务接口，这种方式有点像RPC服务，而UWP就是通过沙箱，作为客户端，来使用DCOM这个服务端，间接调用微软的底层音频程序，这样虽然有点绕，我们可以理解为UWP应用和window的底层硬件程序使用沙箱和DCOM技术隔离，使用DCOM的好处是，DCOM是服务端，可以一对多客户端，也就是可以同时多个不同沙箱不同权限UWP程序同时访问同一个DCOM服务程序来调用底层模块，可能有人会想到window完全可以用其他多种方法调用这个Audiodg.exe，这个说法没错很正确，请看我下面的说明就知道了。
大家有可能没有看不懂上面的东西，这不要紧，我就在这点到为止，感兴趣想深入了解DCOM的同学，可以看下一本经典老书《DCOM入门》。关于这个警告日志，大家应该已经猜到了原因，据我分析就是因为 UWP 应用是受限身份运行的，当它们尝试使用一些系统 COM 组件（比如 Immersive Shell）时，没有显式授权就会被安全子系统记录成“未授予激活权限”的事件日志。而这里
1.触发链路：
“桌面左下角弹出消息提示 + 打开声音” -> 通知中心/外壳体验 Host（ShellExperienceHost，UWP 容器）要发出提示音 -> 关联到音频子系统 -> 你看到 audiodg.exe（Windows Audio Device Graph Isolation）
2.权限问题：
ShellExperienceHost 以 UWP 应用容器身份（AppContainer SID） 发起了对 Immersive Shell（CLSID/APPID） 的本地激活请求，以便用Audiodg.exe，但是该 APPID/CLSID 当前的“启动和激活权限”里没有显式包含这个 AppContainer（或者包含的主体不匹配），因而记录“未授予本地激活权限”的警告（非错误）。随后系统可能通过一个被允许的中介/代理进程（如 RuntimeBroker、svchost 某组、或外壳里的另一路）完成动作，所以功能看上去没坏，因此微软对于这类10016号日志警告，只是为了做了提醒用户的操作，官网相关此类问题也是让用户不用处理，只是知晓就好。可能有人要问，之前为什么是好的，突然出现此类错误，我估计原因和系统更新和设置有关，导致了权限失效，这种失效除非格式化硬盘，重新安装系统解决以外，并无他法，包括覆盖安装我也试过，并不能修复问题。
那么对于一些纠结于此日志的网友，我还是给出些解决思路，在我测试中，把音量调成0后，这个日志就不会出现了，当然调成0当前这次操作还是会出现一次，之后使用消息窗口、u盘弹出、截图都不会有10016日志出现。
本人也尝试过升级声卡驱动，但是并没有什么用，反而微软自动更新的驱动版本更高，显然不是驱动的问题，因为这个audiodg.exe是微软的音频设备图像隔离程序，具体如下：
在 Windows 系统中，声音的播放和处理并不是直接由应用程序访问声卡驱动完成的。
系统中有一个“音频引擎”，负责：
统一管理音频设备（比如扬声器、耳机、HDMI 输出）
混合多个应用程序的声音（比如你同时听音乐、打游戏、视频会议）
应用音效增强、音量调节、均衡器、环境音效等 DSP（数字信号处理）
把最终混合后的信号送给驱动程序，再送到声卡/设备播放
audiodg.exe 就是承载这个音频引擎的 隔离进程。

为什么叫“隔离”进程？
在 Windows Vista 之前，音频处理是在 svchost.exe 等系统进程中进行的，
如果第三方音频插件或驱动崩溃，会直接拖垮系统，造成蓝屏或系统卡死。
为了避免这种情况，微软在 Vista 起将音频处理部分独立出来：
把音频服务放进一个单独的进程：audiodg.exe
这样即便它崩溃，系统本身不会被影响，只是声音暂时中断。
这就是“Graph Isolation（图形隔离）”名字的由来。
以上是我个人的一些拙见，如有不妥之处请见谅，这篇文章我做公开查看权限给真正需要的朋友，对DCOM和系统日志跟踪有研究的小伙伴也可以在评论区留言，互相交流下，谢谢大家的观看，再见！