事件 ID 2260 的记录来源通常是 Microsoft-Windows-DeviceGuard/Operational 日志，描述为组策略 Device Guard 处理失败。这个事件并不表示某个具体文件一定损坏，而是 Device Guard 或 Windows Defender Application Control（WDAC）策略在组策略刷新、启动或用户登录阶段无法被系统完整接受。管理员如果只删除事件日志或忽略该记录，后续还可能出现代码完整性策略未生效、应用程序被意外拦截或安全功能静默关闭等问题。因此需要从日志细节、策略文件、虚拟化安全状态和注册表配置四个方面进行定位。
一、事件 ID 2260 的产生机制与日志定位
Device Guard 组策略处理由 Group Policy Client 服务完成，具体扩展项会把管理员配置的安全策略写入内核代码完整性子系统。如果写入操作被拒绝、策略签名校验失败或虚拟化安全组件未就绪，客户端扩展会返回失败状态，事件 2260 就会被记录下来。事件属性中通常包含错误码、策略名称和组策略对象（GPO）路径，这些信息是判断故障方向的第一手依据。
要快速提取事件 2260 的完整信息，可以在 Windows PowerShell 中执行以下命令。该命令从 Device Guard 操作日志中筛选最近 20 条事件，并以列表形式显示时间、ID、级别和消息内容。
Get-WinEvent -LogName "Microsoft-Windows-DeviceGuard/Operational" -MaxEvents 20 |
Where-Object { $_.Id -eq 2260 } |
Format-List TimeCreated, Id, LevelDisplayName, Message
查看消息中的错误码时，如果出现 0x80070005（拒绝访问）、0x80070002（找不到文件）或 0x8020001A（策略无效）等，就能直接对应到权限、文件或策略内容问题。还可以通过事件查看器手工打开应用程序和服务日志MicrosoftWindowsDeviceGuardOperational，在右侧筛选当前日志为 2260，查看详细信息中的 XML 视图。
二、排查策略文件与权限问题
Device Guard 的策略文件主要存放在 C:WindowsSystem32CodeIntegrity 目录下，其中 SIPolicy.p7b 是原始策略二进制文件，而 C:WindowsSystem32CodeIntegrityCiPoliciesActive 目录中会存放编译后的策略文件。事件 2260 常常由于 System 账户或 TrustedInstaller 对这些文件的访问权限不足，或者文件被第三方安全软件错误修改而触发。管理员可以先检查目录是否存在，并确认文件的所有者和访问控制列表。
以下命令用于查看 C:WindowsSystem32CodeIntegrity 目录的 ACL 信息，重点确认 NT AUTHORITYSystem 和 BUILTINAdministrators 是否有完全控制权限。
icacls C:WindowsSystem32CodeIntegrity icacls C:WindowsSystem32CodeIntegritySIPolicy.p7b
如果输出中缺少 SYSTEM 的完全控制项，可以使用 icacls 进行修复。修复前建议先备份原 ACL 或策略文件，再执行以下命令恢复默认权限。
icacls C:WindowsSystem32CodeIntegrity /grant "NT AUTHORITYSystem:(OI)(CI)F" icacls C:WindowsSystem32CodeIntegrity /grant "BUILTINAdministrators:(OI)(CI)F"
如果策略文件本身已经损坏，最常见的情况是 SIPolicy.p7b 无法解析或活动策略文件与当前系统版本不兼容。管理员可以尝试从组策略中重新应用 Device Guard 策略，生成新的策略文件。如果确认不再需要 Device Guard，不要直接手动删除所有文件，而应先在组策略中禁用相关设置并执行 gpupdate /force，让系统自动撤销策略。
三、检查虚拟化安全与启动配置
Device Guard 的基于虚拟化的代码完整性保护依赖 Windows 虚拟机监控程序（Hyper-V Hypervisor）和安全启动。如果 hypervisorlaunchtype 被设置为 Off，或者设备没有启用安全启动和 IOMMU，代码完整性服务无法进入受保护模式，组策略处理就可能失败。管理员可以在命令提示符中运行以下命令，查看当前的虚拟化启动状态。
bcdedit /enum {current} | findstr hypervisorlaunchtype
正常启用 VBS 时，hypervisorlaunchtype 应为 Auto。如果显示为 Off，需要执行 bcdedit /set hypervisorlaunchtype auto 并重启计算机。还要进入 UEFI 固件设置确认安全启动已经开启，并在系统信息中检查基于虚拟化的安全性是否处于运行状态。如果硬件不支持必要的虚拟化扩展，即使组策略配置正确，事件 2260 仍可能反复出现。
注册表键 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlDeviceGuardScenariosHypervisorEnforcedCodeIntegrity 中，Enabled 的值应设为 1 表示允许。管理员可以用 PowerShell 读取该值，结合组策略状态判断是否配置成功。
四、通过组策略和注册表重置 Device Guard 配置
当权限和启动配置都没有问题时，处理事件 2260 最直接的办法是重置 Device Guard 组策略。打开本地组策略编辑器（gpedit.msc），依次展开计算机配置管理模板系统Device Guard，找到打开基于虚拟化的代码完整性选项。将策略设为未配置或已禁用，点击应用后再重新启动，以观察事件是否消失。域环境中还应检查中央存储内的 Device Guard 策略是否与本地设置冲突，路径通常位于 \域名SYSVOL域名PoliciesPolicyDefinitions 下。
如果需要彻底清理注册表中的 Device Guard 策略残留，可以谨慎删除或修改以下键值。操作前必须备份注册表，因为错误修改会影响系统启动和代码完整性功能。
reg query HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlDeviceGuard /s reg query HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsDeviceGuard
完成组策略调整后，在管理员权限下运行 gpupdate /force，并重启计算机让策略生效。如果域组策略是主要来源，还需要确保域控制器的组策略版本与客户端操作系统兼容，避免旧的策略模板导致处理失败。
五、修复后的验证与长期维护
重启后可以通过 PowerShell 查询 Device Guard 的运行状态，确认代码完整性策略是否已正确应用。以下命令返回当前 VBS 状态，以及 Device Guard 的启用情况。
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace rootMicrosoftWindowsDeviceGuard | Select-Object SecurityServicesRunning, SecurityServicesConfigured, VirtualizationBasedSecurityStatus
如果 VirtualizationBasedSecurityStatus 显示为 2（启用）且 SecurityServicesRunning 包含代码完整性，说明 VBS 与 Device Guard 已成功运行。随后再次检查事件查看器中的 2260 记录是否停止。如果仍偶尔出现，可以启用 Device Guard 操作日志的调试模式，或使用 WdacWizard 工具重新生成兼容的 WDAC 策略。
长期维护角度，建议在测试计算机上验证所有 Device Guard 策略变更，避免直接在生产环境应用未测试的策略。同时定期备份 C:WindowsSystem32CodeIntegrity 目录和注册表中 Device Guard 相关键值，并在更新硬件驱动、BIOS 固件或 Windows 功能版本后重新验证策略状态。这样可以减少因系统升级导致的策略处理失败。
事件ID 2260Device Guard组策略修改时间：2026-08-20 06:17:58