Summary
PR #132 correctly changes the Microsoft-Windows-Kernel-File provider GUID, but the Windows ETW decoder still interprets this manifest provider using MOF FileIo opcode values. A live Windows 11 ETW capture shows that file events use event IDs with opcode 0.
Evidence
A live capture using the registered provider and keyword mask 0xE90 produced:
| Operation |
Event ID |
Opcode |
Keyword |
Path field |
| Create |
12 |
0 |
0xA0 |
FileName |
| Write |
16 |
0 |
0x220 |
none |
| Rename |
27 |
0 |
0x800 |
FilePath |
| Delete |
26 |
0 |
0x400 |
FilePath |
The provider manifest documents these event IDs, keywords, and templates:
https://github.com/repnz/etw-providers-docs/blob/master/Manifests-Win10-18990/Microsoft-Windows-Kernel-File.xml
Current behavior
In src/sensor/windows/etw.rs, file routing checks record.opcode() for 64, 65, 70, 71, and 72. For the manifest provider, the captured opcode is 0, so create, delete, and rename events fall through as SensorAction::Modify.
In src/sensor/windows/mapper.rs, the same opcode mismatch causes the fallback action code to become 65, which maps the events to Sysmon event ID 11.
Also, decode_file reads FileName, but the provider uses FilePath for DeletePath and RenamePath events. Those events therefore lose their target path.
The keyword constant names are misleading:
- 0x0200 is KERNEL_FILE_KEYWORD_WRITE, not DELETE
- 0x0400 is KERNEL_FILE_KEYWORD_DELETE_PATH, not RENAME
- 0x0800 is KERNEL_FILE_KEYWORD_RENAME_SETLINK_PATH, not SETINFO
The numeric mask 0xE90 may still be intentional for filename, create, write, delete-path, and rename-path events, but the names should match the provider.
Expected behavior
- Route Microsoft-Windows-Kernel-File events using manifest event IDs.
- Preserve create, write, delete, and rename semantics.
- Read
FilePath for DeletePath and RenamePath events.
- Keep the provider keyword constants aligned with the manifest names.
- Add unit tests covering event IDs 12, 16, 26, and 27, plus the relevant field mappings.
Summary
PR #132 correctly changes the Microsoft-Windows-Kernel-File provider GUID, but the Windows ETW decoder still interprets this manifest provider using MOF FileIo opcode values. A live Windows 11 ETW capture shows that file events use event IDs with opcode 0.
Evidence
A live capture using the registered provider and keyword mask 0xE90 produced:
The provider manifest documents these event IDs, keywords, and templates:
https://github.com/repnz/etw-providers-docs/blob/master/Manifests-Win10-18990/Microsoft-Windows-Kernel-File.xml
Current behavior
In
src/sensor/windows/etw.rs, file routing checksrecord.opcode()for 64, 65, 70, 71, and 72. For the manifest provider, the captured opcode is 0, so create, delete, and rename events fall through asSensorAction::Modify.In
src/sensor/windows/mapper.rs, the same opcode mismatch causes the fallback action code to become 65, which maps the events to Sysmon event ID 11.Also,
decode_filereadsFileName, but the provider usesFilePathfor DeletePath and RenamePath events. Those events therefore lose their target path.The keyword constant names are misleading:
The numeric mask 0xE90 may still be intentional for filename, create, write, delete-path, and rename-path events, but the names should match the provider.
Expected behavior
FilePathfor DeletePath and RenamePath events.