Windows 安全日志里根本没开文件系统审计，EventLog
读出来全是空的
默认情况下，Windows 根本不记录文件访问事件——哪怕你用
EventLog类去查
Security日志，也只会看到登录、策略变更之类的内容。文件操作（如打开、删除、重命名）必须手动启用对象访问审计策略，且需为具体目录/文件设置 SACL。
实操建议：
先用组策略编辑器（gpedit.msc）打开「计算机配置 → Windows 设置 → 安全设置 → 高级审核策略配置 → 系统审核策略 → 对象访问」，启用「文件系统」审核（成功+失败） 对目标文件夹右键 → 属性 → 安全 → 高级 → 审核 → 添加主体（如
Everyone），勾选要审计的操作（如
ReadData、
Delete） 注意：启用后需重启或运行
gpupdate /force，且只有 NTFS 卷生效，FAT32 或网络共享路径无效
EventLog
读不到 4663 事件，或者只读到部分记录
文件访问审计对应的安全事件 ID 是
4663（句柄被请求），但它依赖两个前提：一是策略已启用（见上一条），二是事件日志未被轮转覆盖或权限拦截。.NET 的
EventLog类在 .NET Framework 下能读，但在 .NET Core/.NET 5+ 中默认不可用，且对远程日志支持极弱。
实操建议：
优先改用System.Diagnostics.Eventing.Reader（即
EventLogReader），它支持现代 Windows 事件日志查询，兼容 .NET Core 查询时指定
Path为
Security，过滤
4663事件，用
QueryEvents而非枚举全部日志（性能差、易超时） 检查当前账户是否有读取安全日志权限：需属
Administrators或
Event Log Readers组，否则会静默失败或抛
UnauthorizedAccessException
从 4663
事件里提取文件路径太难，Message
字段是格式化字符串，不是结构化数据
Windows 安全日志的
4663事件原始 XML 中，文件路径藏在
EventData的
SubjectUserName、
ObjectName和
ObjectTypeName字段里，但
EventLogEntry.Message是本地化后的纯文本，中文系统下字段名是“对象名称”，英文系统下是“Object Name”，无法直接正则匹配。
实操建议：
别解析Message，用
EventLogRecord.ToXml()或
EventLogRecord.Properties获取原始属性
Properties[1].Value通常是完整路径（
ObjectName），但要注意：若路径过长或含特殊字符，可能被截断或显示为
\??\C:\...形式，需用
Path.GetFullPath()归一化 关键字段索引不稳定，推荐按
Name查找：
record.Properties.FirstOrDefault(p => p.Name == "ObjectName")?.Value
实时监控 Security
日志性能差、漏事件、程序卡死
安全日志量大（尤其开了文件审计后），轮询
EventLog或频繁调用
QueryEvents极易拖慢系统；而用
Watcher类监听日志变化，又常因权限、缓冲区溢出或事件堆积导致丢失
4663。
实操建议：
放弃轮询，用EventLogWatcher+
Query（XPath 查询），例如：
*[System[(EventID=4663) and TimeCreated[timediff(@SystemTime) ，限制最近 5 分钟事件设置
MaximumBufferSize（如 64KB），避免内存暴涨；处理完事件立即调用
EventLogWatcher.Enabled = true恢复监听，防止积压 生产环境务必加异常捕获：
EventLogWatcher.EventRecordWritten里任何未处理异常都会让整个监听静默终止
真正麻烦的是路径权限和 SACL 继承——父目录开了审计，子目录没继承，或者 ACL 被重置，就会突然没日志。这点没法靠代码解决，得盯住组策略和文件系统权限本身。
