Windows EDR sensor overview

What this page is

This page is the entry point for the Windows endpoint detection and response sensor. It maps the crate layout to the architecture document and the ADRs, describes the staged delivery from Phases 1-6, and points engineers at the per-component pages.

Why it exists this way

The sensor ships in four user-mode phases plus two platform phases (kernel driver and documentation) as specified in the architecture document Section 7. Each phase lands as one feature commit so reviewers can trace the incremental contract: wire types first, then ETW telemetry scaffolding, then gRPC transport, then response actions (isolation, triage, AMSI, WFP), then tamper resistance, then kernel-mode stub, and finally documentation.

The user-mode crate lives at crates/edr-windows/ and the kernel-mode driver stub lives at crates/edr-windows-km/. The kernel crate is excluded from the workspace because it requires the Windows Driver Kit (WDK) toolchain.

How it works

Seven modules implement the staged items:

Phase	Module	Role
1	enrollment, capabilities	Wire contracts, mTLS enrollment
2	etw, loader, ocsf, events	ETW telemetry, OCSF normalisation
3	transport, buffer	gRPC streaming, offline ring buffer
4	isolation, triage, amsi, wfp	Response actions, network isolation
5	guard, update	Tamper resistance, self-update
6	(kernel) edr-windows-km	Kernel minifilter, process callbacks

Each user-mode module is cfg-gated to target_os = "windows" so non-Windows developer hosts (macOS, Linux CI) still pass cargo check against the crate. The cross-crate APIs in capabilities, enrollment, ocsf, and proto are imported by the central Collector code path without platform coupling.

Platform requirements

• Windows 10 version 1809 (build 17763) or later
• Windows Server 2019 or later
• 64-bit only (x86_64-pc-windows-msvc target)
• EDR service runs as NT AUTHORITY\SYSTEM with SeDebugPrivilege and SeSystemEnvironmentPrivilege enabled
• ETW provider registration requires admin privileges
• WFP isolation requires the Base Filtering Engine service running

Cross-compilation from Linux or macOS is not supported for the kernel driver crate. The user-mode crate cross-checks clean from Linux CI via cargo check -p edr-windows.

Comparison with Linux EDR

Aspect	Linux EDR	Windows EDR
Telemetry source	eBPF (CO-RE)	ETW (SystemTraces)
Transport	gRPC/tonic	gRPC/tonic
Host isolation	nftables	WFP / Windows Firewall
Script introspection	None	AMSI provider
Kernel component	eBPF programs	Minifilter driver
Protocol buffers	Shared proto	Shared proto
Offline buffer	500 MB ring buffer	500 MB-5 GB ring buffer

What goes wrong

• loader::LoaderError::EtwSessionInit, ETW session creation fails. Usually the Performance Logs and Alerts service is stopped or the user lacks admin. The loader exits immediately; enrollment is not attempted until telemetry infrastructure is healthy.
• transport::TransportError::Connect, the Collector is unreachable or refusing mTLS. Sensor falls into the offline ring buffer (500 MB default). No telemetry is lost unless the offline window exceeds buffer capacity.
• guard::HardeningError::PplConfigFailed, PPL was removed by another privileged process. The tamper-resistance watchdog detects this within 60 seconds and logs a high-severity alert.
• amsi loading fails because amsi.dll is not present or has been patched. The guard module's verify_amsi_integrity detects this and the sensor refuses to start until the system is remediated.