Capturing Network Packets on Windows Without Writing Your Own Driver

Introduction

Real-time packet capture on Windows happens below user mode. No application process can intercept and act on network traffic in real time on its own; the operating system requires a kernel-level driver, and that driver has to be digitally signed before Windows will load it.

Most developers don't write this driver. They build on Npcap or its predecessor WinPcap, both of which are the usual backend for libpcap-based tools on Windows. WinPcap is discontinued and no longer receives security updates; Npcap replaced it and is actively maintained, but it comes with its own installation and licensing terms, covered below.

NetFilter, the core component of PCAP Filter, is a third option: a pre-built, signed driver included with the SDK. Your application installs it and calls its API. Nobody on your team writes, signs, or ships a driver.

Why This Normally Requires a Driver

Capturing packets before they reach user space means working with NDIS or the Windows Filtering Platform at the kernel level. A driver written from scratch needs the Windows Driver Kit toolchain, working NDIS or WFP code, and a digital signature, plus WHQL certification if it has to run reliably across a range of customer machines. That's before any of your application's own features get built. It also doesn't end at release: the driver needs updates and re-signing as Windows itself changes.

PCAP Filter vs. Npcap

Both ship a driver. The difference is who builds it, who maintains it, and what it costs to put it in a product you sell.

PCAP Filter's Royalty-Free license lets you redistribute the driver and libraries as a runtime component of your application at no additional fee, as long as you ship it unmodified and in compiled form. Npcap's free license caps you at five installations and doesn't include a silent installer; shipping it inside a commercial product at any real scale means buying Npcap OEM.

Getting Started (.NET)

Install the driver once, at install time, not from inside your running application. This is normally done by your installer, using the same Install method your code would call, or the standalone Installer DLL that ships with the product for use in install scripts. netfilter.cab, the driver package, is in the drivers folder of your PCAP Filter installation.

// Run once, from your installer: install the NetFilter driver. // productGuid is any GUID your application generates and reuses // consistently to identify its driver installation. filter.Install(@"C:\path\to\netfilter.cab", productGuid, 0, 0, null);

Install returns whether a reboot is needed before the driver can be used. If it returns true, don't expect packets to flow until after the restart.

From there, your application code initializes the component, lists adapters, adds a rule, and starts filtering:

filter.Initialize(productGuid); filter.ListAdapters();
// Capture all traffic on the first available adapter filter.AddFilterRule(1, filter.Adapters[0].Id, Constants.PACKET_DIRECTION_ANY, -1, -1, "", Constants.RULE_ACTION_CAPTURE);
filter.OnPacket += (o, e) => { Console.WriteLine($"Packet captured on adapter {e.AdapterId}, {e.PacketSize} bytes"); };
filter.StartFilter(0);

AddFilterRule's BPFRule parameter (left empty above) takes a BPF expression, the same format libpcap filters use. If you already write libpcap filter expressions, they work here unchanged.

For the full API, adapters, rules, and both packet-handling modes, see Getting Started with NetFilter.

When This Matters

If you're shipping a commercial application and don't want a separate driver dependency, its licensing terms, or the job of tracking Windows driver signing requirements, this removes all three. If you're building an internal tool and already have Npcap deployed and managed, staying on it may be the simpler path.