AdguardTeam
Add support for SockFilter driver
Issue Details
A sock filter driver is a lightweight kernel-mode network driver that attaches directly to socket operations at the transport layer (TCP/UDP). Instead of inspecting or modifying packets as they travel through the full Windows networking stack, a sock filter intercepts socket calls (e.g., connect, send, receive, bind) at a higher, more stable abstraction level. This makes it ideal for applications that need to monitor or control network activity without deep packet processing.
Advantages Compared to a WFP Driver
Operates at a higher, socket-level layer: A sock filter works with socket operations rather than raw packets, making it less complex and more stable than WFP's low-level packet filtering.
No interference with other network drivers: Because it sits above VPN, firewall, and antivirus WFP filters, it avoids filter-ordering problems and compatibility conflicts common in the WFP stack.
Greatly reduced risk of NETIO-related BSODs: Sock filters don't run inside the NETIO packet pipeline, so they avoid the typical crash scenarios caused by WFP callouts mishandling buffers, classification results, or packet memory.
Disadvantages (and Why They're Acceptable for Our Use Case)
A sock filter driver sees only socket-level operations and does not capture traffic generated by other kernel drivers or components that bypass the standard Winsock API. From a low-level networking perspective, this can be viewed as a limitation — the driver cannot access raw packets or inspect non-socket traffic.
However, for an ad-blocking application, this behavior is not just acceptable but optimal. All relevant traffic from browsers and user-mode applications goes through standard sockets, and that's exactly what we need to control. At the same time, ignoring low-level driver traffic removes unnecessary complexity, avoids compatibility issues, and keeps the system stable.
The result is a driver that focuses on the traffic that matters, avoids the risks inherent to WFP packet filtering, and delivers cleaner integration with the rest of the network stack — making the sock filter a more fitting and reliable choice for this scenario.
@shamarin Hello!
That’s a great question. I’ve added a Disadvantages section to the issue description.
Please don’t hesitate to reach out if you have any questions.
@shamarin , yes indeed both drivers - socks and wfp. As described above TDI is obsolete, but we are in process of transferring to the new "drivers pairs"
@shamarin , yes indeed both drivers - socks and wfp. As described above TDI is obsolete, but we are in process of transferring to the new "drivers pairs"
So we will have an option to select WFP or SockFilter driver?
Is the Use WFP network driver going to be removed or replaced with something else? Like a dropdown menu? Also is the plan to completely remove the TDI driver? If so I would argue that having it remain as a "last resort" option might be worth the effort, as there's no telling it could become needed for something in the future. Turning that option into a dropdown menu (SockFilter > WFP > TDI) with SockFilter being the default might be better, no?
I know Microsoft has depreciated TDI and it's constantly in a state where support for it could be removed in a future Windows release, I'd also argue that Microsoft has depreciated multiple features for years now and still hasn't removed them (one that comes to mind is kernel streaming, which still works in Windows 11 25H2). I would assume there is some use case for TDI that prevents Microsoft from fully removing it.
@shamarin @BooBerry , of course we'll stop on dropdown menu (SockFilter > WFP > TDI) at least as "last resort". Nevertheless, this solution might be temporarily (but as they say, "there is nothing more permanent than temporary") and in the end we'll come to the WFP+SockFilter
As of now, it is assumed that the default will be the WFP - we need to conduct a full test cycle, including receiving feedback from users, in order to make a final decision.
@AlexandrPkhm @adbuker
С нетерпением жду внедрения нового типа драйвера в Adguard хотя использую не Хром а Firefox. Однако на последних версиях Adguard (7.22.1, 7.22.2 7.22.3, 8 Beta 2) у меня появились серьезные проблемы в работе Adguard (High CPU and memory usage with AdGuard for Windows 7.22.1 and 7.22.2 #5754 ) которые не исключено что возможно как минимум частично связанны с проблемой совместимости с антивирусом после последних недавних изменений в Adguard. Поэтому тоже очень надеюсь на новый тип драйвера в Adguard и что он как и заявлено выше в первом сообщении здесь в том числе решит все давние проблемы совместимости. Очень хочу узнать сразу как только новый тип драйвера станет доступен для пользователей публично хотя бы в рамках тестовой версии Adguard и готов тоже по возможности максимально оперативно поучаствовать в его тестировании пусть и не применительно к совместимости с браузером Хром и браузеров на его основе.
I am looking forward to the introduction of a new type of driver in Adguard, although I use Firefox instead of Chrome. However, on the latest versions of Adguard (7.22.1, 7.22.2, 8 Beta 2), I had serious problems with the operation of Adguard (High CPU and memory usage with AdGuard for Windows 7.22.1 and 7.22.2 #5754 ), which it is possible that they may be at least partially related to the problem of compatibility with antivirus after the last recent changes in Adguard. Therefore, I also really hope for a new type of driver in Adguard and that, as stated above in the first message here, it will also solve all long-standing compatibility problems. I really want to find out as soon as the new type of driver becomes publicly available to users, at least as part of the trial version of Adguard, and I'm also ready to participate in testing it as quickly as possible, even if not in relation to compatibility with the Chrome browser and browsers based on it. (Translated by an online translator because I do not speak English.)
I don't see the word "SockFilter" in the v8 beta revision history, and I see that this thread is tagged with v8.01 and is even a "feature request" despite coming from someone on the Adguard team (that's a little confusing).
Shouldn't this driver, of all things, be something included in the major version v8.00? I can't think of any feature more important given that TDI is DOA for most (the vast majority of people on earth use Chromium browsers), WFP is a notorious house of cards when it comes to Adguard, and SockFilter, based on the description above sounds pretty damn good if you're forced to use some driver, which Adguard is.
It's not there because it hasn't landed in nightly yet, it's likely several months from being ready. If I had to guess, it's probably up to 6 months away because if history has taught anything, it's that ETAs are never met. ;)
If you're having issues with the WFP driver, just apply the AppContainer workaround for Chrome/Edge/other Chromium-based browsers and you can keep using the TDI driver.
Honestly, it might be a good idea for the AG team to add a setting in advanced settings to automatically apply the registry workaround for those who don't want to mess around with the registry editor but also are having issues with WFP BSODs.
It's not there because it hasn't landed in nightly yet, it's likely several months from being ready. If I had to guess, it's probably up to 6 months away because if history has taught anything, it's that ETAs are never met. ;)
@BooBerry
Let's hope you're wrong. It's taking too long to solve such a serious problem. Although, of course, the introduction of a new type of driver is also likely difficult, so you don't need to rush too much, of course, you need to check and prepare everything carefully. (Translated by an online translator because I do not speak English.)
I've been having longstanding issues with compatibility between Adguard and Bitdefender (also tried ESET as an alternative with the same resulting issue) when using WFP in Adguard. Is this sock filter driver expected to solve such compatibility issues?
