# microsoft/ebpf-for-windows

eBPF implementation that runs on top of Windows

Repository: https://github.com/microsoft/ebpf-for-windows
Canonical: https://ross.abutalabs.com/products/ebpf-for-windows
Language: C
License: MIT
License Family: permissive
Last push: 2026-08-26T22:48:49+00:00

## Health v2 (maintenance only)
Score: 86/100 (v2, computed 2026-09-03T02:20:16.233290+00:00)
- activity 99, release rhythm 60, longevity 100
- inputs: {"age_days": 1974, "days_push": 7, "days_rel": 14, "gap_med": 35.0, "n_releases_24m": 11}
- flags: prerelease_only
- formula: round(0.45*activity + 0.35*rhythm + 0.20*longevity); archived -> min(score, 10)

## Adoption (not part of the score)
Stars 3553, forks 304 (observed 2026-08-28T04:08:09.586943+00:00)

## What it is
eBPF for Windows is an MIT-licensed implementation of the eBPF runtime that runs on top of the Windows kernel, letting developers reuse familiar Linux eBPF toolchains (clang, ELF bytecode, verifier APIs). It verifies and loads eBPF programs either as natively generated Windows driver modules or via a uBPF JIT service, enabling kernel programmability for networking, DoS protection, and observability.

## Use cases
- run eBPF programs on Windows
- port Linux eBPF tools and programs to Windows
- packet filtering and network processing on Windows servers
- mitigate DDoS attacks at the kernel level on Windows
- observe and trace kernel and network events on Windows
- verify eBPF bytecode before loading it into the Windows kernel
- compile eBPF programs into signed Windows drivers

## When to choose
- You need eBPF-based observability, tracing, or packet processing on Windows rather than Linux
- You want to reuse existing eBPF toolchains, bytecode, and APIs from the Linux ecosystem on Windows
- You need verified, safe kernel extensibility on Windows, especially with HVCI enforced (prefer the native driver mode)
- You are building Windows networking or security tooling that benefits from programmable kernel hooks

## When to avoid
- You are targeting Linux or macOS, where the kernel's native eBPF stack is the right choice
- You require full feature parity with Linux eBPF, since this project is a work-in-progress with evolving hook and API coverage
- You need a guaranteed production-hardened eBPF stack today rather than an actively maturing one
- You only need user-space sandboxing or tracing without kernel integration

## Facets
- artifact type: framework
- maturity: active
- function: security, networking, tracing, monitoring, developer-tools
- domain: operating-systems, security, networking, developer-tools
- platform: windows
- tags: ebpf, bpf, kernel-programmability, jit-compiler, verifier, windows-kernel, observability, packet-filtering, ddos-protection, xdp, driver-development, native-code-generation

## Member repositories
- microsoft/ebpf-for-windows (main) score 86

## Provenance
- Observed fields: from GitHub, fetched 2026-08-28T04:08:09.586943+00:00.
- Health v2: computed from the inputs above; adoption is never an input.
- Inferred fields (summary, facets, guidance): AI-extracted, prompt v1, taxonomy v1, on 2026-08-29T18:34:18.734691+00:00, confidence not recorded.
  - readme: https://github.com/microsoft/ebpf-for-windows (fetched 2026-08-28T04:08:09.586943+00:00, sha bc4f31a32aaa)
- Data as of 2026-08-30T08:39:29.467469+00:00.