eBPF for Windows: Network Filtering and Observability
eBPF for Windows is real and usable today for network filtering and observability, but treat it as a different runtime, not Linux eBPF recompiled. Your bytecode runs through a Windows execution context with its own verifier and its own hooks, so a program that loads on Linux can get rejected here for reasons that have nothing to do with your code. Read the eBPF-for-Windows source, trace what the runtime does, and check its logs when a load fails. Otherwise you will blame Linux eBPF for what is really a Windows verifier rejection, a hook mismatch, or a driver signing problem.
Last updated: 2026-07-21
Can you extend the kernel without writing a monolithic driver? That is the whole point of this project, and the answer is yes for a narrow, growing set of jobs. Here is what works now, what is still in progress, and how teams decide.
What Is eBPF for Windows and How Does It Run on the Windows Kernel?
It is a runtime, not a port. The project stitches together community pieces you know from Linux: the uBPF interpreter and the PREVAIL verifier. Microsoft wraps those with a Windows driver called netebpfext that exposes the network hooks, plus a service that loads and manages programs.
Your source compiles to Berkeley Packet Filter bytecode. That bytecode goes to PREVAIL for verification in a protected user-mode process. Only after it passes does it reach execution. So the trust boundary sits in user mode, before anything touches the kernel.
From there you have a few ways to run. The interpreter and a just-in-time (JIT) path are fine for testing. On machines with Hypervisor-enforced Code Integrity (HVCI) turned on, JIT injection is blocked, so you compile to native code and ship a signed driver instead. That native path is the one built for real deployment.
Here is the mental model that trips people up. This is not Linux's kernel with a Windows badge. The hooks come from a Windows driver, the context layouts are Windows layouts, and the event plumbing is Event Tracing for Windows (ETW), not tracepoints. Design for that and things go smoothly. Assume Linux internals and you will fight the verifier all day.
Your Linux Toolchain Carries Over, but Not Everything
Mostly yes for the front of the pipeline, no for anything tied to Linux kernel internals. You compile with the same Clang/LLVM you already use, and you load with libbpf-style APIs. Generic logic and data-path code port with little fuss.
What does not port is anything reaching into Linux-specific structs, calling conventions, or helper behavior. A helper that reads a Linux context layout has no equivalent here. Those spots need a rewrite or a small portability shim, not a recompile.
| Stage | Tool | What it does |
|---|---|---|
| Compile | Clang/LLVM | Emits stable bytecode from your source |
| Translate | bpf2c | Turns bytecode into C for driver builds |
| Ship | WDK and MSBuild | Builds and signs the PE driver for HVCI |
Keep dev and prod close. Match compiler versions, MSBuild settings, and signing practice so a program that verifies on your bench verifies on the box. If you are coming from the Linux side, my walkthrough of tracing system calls with eBPF shows the code that carries over cleanly and the code that does not.
The honest summary: the toolchain is familiar, the target is not. Write portable helpers, keep programs small, and expect to patch context and event names at the seams.
How Does the Windows eBPF Verifier Keep the Kernel From Crashing?
PREVAIL is the gate, and reading its rejection is the difference between a five-minute fix and a lost evening. It runs in a protected user-mode process and proves things about your program before the kernel ever sees it: bounded loops, memory access in range, guaranteed termination. Fail any of those and it refuses the load.
The value is that a rejection is a specific claim, not a mystery. When PREVAIL says a load is out of bounds, it means it could not prove that access stays inside the buffer. That is a real defect in most cases, even if Linux happened to accept it.
So do not treat a Windows verifier failure as a Linux eBPF bug. Different verifier, different proof. Read the exact message, find the instruction it names, and fix the access or the loop bound. The verifier is telling you the real problem if you slow down and check the output.
This is also why you keep programs small. A tight program is one PREVAIL can reason about quickly. A sprawling one gives it more paths to reject and gives you more to debug.
When to Reach for eBPF Instead of a Custom Kernel Driver
Reach for eBPF when you want kernel-level network visibility without owning a full driver's failure modes. A bad kernel driver crashes the box. A bad eBPF program gets rejected by PREVAIL and never loads. That safety gap is the main reason to start here.
You also move faster. Recompile bytecode and reload in seconds during testing instead of grinding through a Windows Filtering Platform (WFP) or NDIS driver build for every change. The verifier catches whole classes of memory bugs up front, so you spend less time in a kernel debugger.
But eBPF is not always the right call, and pretending otherwise wastes your week. Write a real driver when:
- You need a hook eBPF for Windows does not expose yet.
- You need deep protocol handling or state the current helpers cannot express.
- You are already shipping a WFP callout and eBPF would just add a layer.
For production on HVCI machines you still end up with a signed driver anyway, built through bpf2c. So the signing burden does not vanish. What you gain is the verifier and the faster inner loop, not freedom from Windows driver rules.
How Do You Install eBPF on Windows Step by Step?
Start by confirming your platform, because the rest is wasted if the OS is out of scope. The project supports Windows 10 and Windows Server 2016 and later. Older than that and you stop here.
- Check the version support above and confirm your build.
- Install the runtime from the project's MSI installer, or the developer packages if you plan to build programs.
- Install the Windows Driver Kit (WDK) and open the Developer Command Prompt for your driver builds.
- Decide your execution mode. For a lab, the interpreter or JIT is fine. For an HVCI machine, plan on native code and a signed driver from the start.
- Validate the install before you write anything.
That last step is the one people skip and regret. After the MSI runs, confirm the eBPF service is present and the netebpfext driver loaded. Check the ETW output for the runtime. If the service is not up, no correct bytecode will load, and you will chase a code bug that is really a broken install.
The project ships releases on a regular cadence, with tags through v1.3.0 of eBPF-for-Windows. Do not hardcode a version in your head. Check the GitHub releases page for what is current and match your MSI, developer packages, and docs to the same tag.
What You Can Build With It Today
Network hooks and observability, in that order of maturity. The two kernel hooks you can lean on today are XDP-style packet filtering and socket bind. With those you filter packets early and enforce socket-level policy before user mode sees the traffic. That is genuinely useful for a firewall path or an early-drop filter that cuts event volume at the source.
Observability rides on ETW. Your program's bpf_printk output becomes structured ETW events, so you capture runtime signals without a heavy agent in the path. That shortens triage because you are reading events, not diffing log files.
| Mode | Best for | Trade-off |
|---|---|---|
| Interpreter | Quick testing | Lower throughput, easiest to debug |
| JIT | Lab performance | Faster, blocked under HVCI |
| Native driver | Production | Highest speed, signing required |
Now the honest part. If you came expecting arbitrary tracepoints and kprobes the way Linux gives them, that broad tracing surface is not here. The model is built around network hooks and a defined set of program and attach types, not attach-anywhere kernel probing. For deep system tracing, the Linux side still wins, and my notes on runtime enforcement with eBPF assume that richer hook set. Plan around what Windows exposes today, not what you wish it did.
Where to Find the Source and API Docs
Go to the source before you go to a forum. The eBPF for Windows GitHub project is the whole thing: the runtime, the netebpfext driver, the docs, and the release tags. When behavior confuses you, the code and its issue tracker answer faster than any second-hand blog post.
The API splits two ways. There is a user-mode surface for loading, attaching, and managing programs, built to feel like libbpf. There is a kernel-mode surface that defines the hooks and helpers your program can call. Read both. Most "why won't this attach" questions are a mismatch between the program type you compiled and the hook you tried to attach it to, and the docs spell out that pairing.
Keep the repo tag, your installed MSI, and the docs you are reading on the same version. A helper signature or an attach type can change between releases, and mixing versions is how you get an error that makes no sense against the docs open in your browser.
Does Falco Support eBPF on Windows?
No, Falco does not run its eBPF-based detection on Windows today. Falco's eBPF and kernel-module drivers are built for the Linux syscall surface, hooking sys_enter and sys_exit to watch process behavior. eBPF for Windows does not expose that syscall-tracing surface, so there is nothing for Falco's Linux driver to attach to.
This confuses people because both say "eBPF," so they assume the tools transfer. They do not. Falco and friends like Tetragon and Tracee are built on Linux tracepoints and the stable syscall interface. Windows routes that visibility through ETW and Win32 APIs instead, which is a different pipeline with different events.
If you want Falco-style detection on Windows, watch the project's own platform support rather than assuming its Linux eBPF path will land here. For system-level visibility on Windows right now, you build against ETW providers, not a Falco eBPF driver.
Why eBPF Programs Fail to Load on Windows, and How to Debug It
Read the failure before you touch the code. A load failure on Windows falls into a few buckets, and the runtime usually tells you which one if you look.
First, confirm the runtime is even alive. If the eBPF service or the netebpfext driver is not loaded, every program fails and none of it is your bytecode's fault. Check the service state and the driver, then retry.
Second, capture the runtime's ETW output while you reproduce the failure. Use netsh tracing or an ETW capture to pull the events, then read them against the exact moment the load failed. A log with no time anchor is noise, so reproduce it live and tie the error line to the action.
The common root causes, in rough order:
- A PREVAIL verifier rejection: unbounded loop, out-of-range access, or unprovable termination. Read the message and fix the named instruction.
- A hook or program-type mismatch: you attached a program to a hook it was not built for.
- A driver signing or HVCI problem: JIT is blocked under HVCI, or your native driver is not properly signed for the machine.
Work them in that order and most failures resolve to one specific line. The mistake I see is copy-pasting a Linux fix onto a Windows verifier rejection. Different verifier, different runtime. Understand the real cause from the output, or it comes back on the next load.
FAQ
Do I need to disable HVCI to run eBPF for Windows?
No, and you should not. HVCI blocks the JIT path, not eBPF itself. Keep it on and compile your program to a signed native driver through bpf2c. Turning off a Windows security feature to make a JIT shortcut work is a bad trade.
Can one eBPF program run unchanged on both Linux and Windows?
Only if it sticks to portable helpers and generic data-path logic. Anything that reads a Linux-specific context layout or calls a Linux-only helper needs a shim or a rewrite. Compile for each target and test on each; a clean Linux load does not promise a clean Windows load.
Is eBPF for Windows production-ready or still a preview?
It is usable in production for network filtering and observability, with tagged releases you can pin. It is narrower than Linux eBPF, so scope your use to the hooks that exist. Pin a release, validate the install, and do not build a plan around a hook the runtime does not expose yet.
Why does my program verify on Linux but fail PREVAIL on Windows?
Because it is a different verifier making a different proof. PREVAIL may not be able to show a memory access stays in bounds where the Linux verifier accepted it. Treat the rejection as a real defect first, read the instruction it names, and tighten the bound or the loop.
Where do I start if I am new to eBPF entirely?
Learn the concepts on Linux first, where the tooling and examples are thickest, then map them onto the Windows runtime. My guide to getting started with bcc tools is a gentle on-ramp before you deal with Windows drivers and signing.
