RegisterEventSource匹配EventMessageFile的搜索顺序是深度优先还是广度优先？

基础搜索逻辑 #

RegisterEventSource 接口的搜索行为并非无差别全层级遍历，遵循固定的优先级规则：

• 第一优先级：系统首先扫描 HKLM\SYSTEM\CurrentControlSet\Services\EventLog 下所有日志分类子项（常见如 Application、System、Security 或自定义日志项）的直接子项，匹配你传入的源名称参数。如果找到名称完全匹配的子项，直接读取该子项下的 EventMessageFile 值，搜索终止。
• 第二优先级：如果直接子项未找到匹配项，系统会对每个日志分类子项执行深度优先递归搜索，遍历所有层级的子项，直到找到第一个名称匹配的源子项，读取该子项自身的 EventMessageFile 值后终止搜索。

场景对应说明 #

你观察到的两种配置场景完全符合上述规则：

• Chrome 的配置属于第一优先级场景：Chrome 作为 Application 日志的直接子项存在，EventMessageFile 直接放在该子项根目录下，系统第一步即可匹配命中。
• Windows PowerShell 的配置属于第二优先级场景：PowerShell 源子项嵌套在 Windows PowerShell 父项之下，系统在直接子项扫描阶段未找到匹配的 PowerShell 项，进入递归搜索后命中嵌套子项，读取对应 EventMessageFile 值。

多匹配项处理规则 #

如果同一日志路径下存在多个名称相同的源子项，生效优先级如下：

• 日志分类直接子级的匹配项优先级高于所有嵌套层级的匹配项
• 同属嵌套层级的匹配项，按深度优先搜索的顺序生效，搜索顺序遵循注册表子项的默认字母序排列，先命中的项对应的 EventMessageFile 生效，后续匹配项会被忽略。

内容的提问来源于stack exchange，提问作者HaeRim Lee