Please answer the following questions for yourself before submitting an issue
AdGuard version
8.0.5468.0
Browser version
Edge 149.0.4022.33
OS version
Windows 11 Pro Insider Preview (Build 29599.1000 / rs_prerelease)
Traffic filtering
Ad Blocking
AdGuard Base filter
Privacy
AdGuard Tracking Protection filter, EasyPrivacy, AdGuard URL Tracking filter
Social
AdGuard Social Media filter
Annoyances
AdGuard Cookie Notices filter, AdGuard Popups filter, AdGuard Other Annoyances filter, Adblock Warning Removal List, EasyList Cookie List
Security
Scam Blocklist by DurableNapkin, Phishing URL Blocklist, Online Malicious URL Blocklist
Other
No response
Language-specific
EasyList Polish, Polish Anti Adblock Filters, Polish Annoyances Filters, Polish Social Filters
Which DNS server do you use?
AdGuard DNS
DNS protocol
None
Custom DNS
There are two major interoperability and performance defects discovered in AdGuard for Windows (v8.0.5468.0) running on Windows 11 Insider Preview (Build 29599.1000, rs_prerelease).
Infinite Loop / Memory Leak on Startup: The AdGuard engine (AdguardSvc.exe and Adguard.exe) enters an infinite loop while compiling/parsing the local filter database (agflm_dns in %programdata%\AdGuard\FLM). This results in 100% CPU utilization on high-end processors and memory consumption spiraling up to 3.5 - 4 GB RAM (symmetrically allocated between the Service and GUI via IPC queues). The only remedy is a hard delete of the FLM directory.
Kernel Panic (BSOD 0x139): AdGuard’s WFP driver (adgnetworkwfpdrv.sys) experiences a race condition / reference count invalidation when interacting with other kernel-mode packet inspection drivers (specifically NDivert.sys utilized by NordVPN's Threat Protection).
Crash Analysis (WinDbg Outputs)
Issue 1: GUI Context / Deadlock on GC Disable
When the memory ballooning occurs, forcing a memory dump on Adguard.exe shows the main thread freezing on a native call while trying to transition from managed to preemptive GC mode:
STATUS_BREAKPOINT (0x80000003) inside clr!CLREventWaitHelper2
STACK_TEXT:
ntdll!NtWaitForSingleObject+0x14
KERNELBASE!WaitForSingleObjectEx+0xad
clr!CLREventWaitHelper2+0x32
clr!Thread::RareDisablePreemptiveGC+0x15d
clr!JIT_RareDisableHelperWorker+0x39
WindowsBase!MS.Win32.UnsafeNativeMethods.GetMessageW+0x12
PresentationFramework!System.Windows.Application.RunDispatcher+0x71
Adguard!Adguard.App.Main+0x308
Diagnosis: The WPF GUI application is flooded with IPC messages from the spinning service, blocking the .NET Garbage Collector from compacting the heap, freezing the message loop.
Issue 2: Kernel Bugcheck 0x139 (BSOD)
The system crashes with a KERNEL_SECURITY_CHECK_FAILURE when both AdGuard and NordVPN inspect network traffic concurrently on the rs_prerelease branch:
BugCheck 139, {e, ffff9322d17d6260, ffff9322d17d61b8, 0}
EXCEPTION_CODE_STR: FAST_FAIL_INVALID_REFERENCE_COUNT (0xe)
FAULTING_IP: NETIO!FeNblTrackAcquireRef+0x52
STACK_TEXT:
nt!KeBugCheckEx
NETIO!FeNblTrackAcquireRef+0x52
fwpkclnt!FwpsAllocateCloneNetBufferList0+0x99
tcpip!TlShimInjectRedirectedPacket+0xed
fwpkclnt!FwpsInjectTransportSendAsync0+0x63
adgnetworkwfpdrv+0xa5fe
Diagnosis: adgnetworkwfpdrv.sys and NDivert.sys are modifying the same NetBufferList (NBL) structures simultaneously. Windows Filtering Platform (WFP) registers an invalid object reference count, triggering an immediate security panic to prevent memory corruption.
What Stealth Mode options do you have enabled?
No response
Support ticket ID
No response
Issue Details
Steps to reproduce:
Environment Setup: Ensure you are running Windows 11 Insider Preview (Build 29599.1000, rs_prerelease gałęzi).
Co-existing Software: Install NordVPN and enable its Threat Protection feature (which registers the NDivert.sys kernel driver to intercept network traffic).
AdGuard Configuration: Install AdGuard for Windows (v8.0.5468.0) with the default WFP network filtering driver enabled (adgnetworkwfpdrv.sys).
Trigger Crash: Generate heavy network traffic (e.g., browse media-heavy websites, stream video, or run Docker containers routing traffic through virtual switches).
Result: The system immediately triggers BSOD 0x139 (KERNEL_SECURITY_CHECK_FAILURE) pointing to NETIO!FeNblTrackAcquireRef.
Trigger Bootloop: Reboot the machine after the BSOD and attempt to start the AdGuard service.
Result: The corrupted database state causes AdguardSvc.exe to drop into an infinite parsing loop, hitting 100% CPU utilization and ballooning to ~4 GB RAM
Expected Behavior
No Kernel Panic (BSOD): AdGuard's WFP driver (adgnetworkwfpdrv.sys) should properly coordinate or fail-safe when another kernel driver (like NDivert.sys) modifies the NetBufferList reference counts, instead of causing a FAST_FAIL_INVALID_REFERENCE_COUNT kernel crash.
Graceful Error Handling in CoreLibs: If the local filter database (agflm_dns) becomes corrupted due to an abrupt system shutdown (BSOD), the parser engine should catch the exception, discard the corrupted cache file, and regenerate a healthy one automatically. It must never enter an infinite loop that isolates CPU cores and drains system memory to the point of a user-mode deadlock.
Actual Behavior
Screenshots
Screenshot 1
Initial State: Driver Conflict & Kernel Panic When adgnetworkwfpdrv.sys processed network packets concurrently with NDivert.sys on Windows 11 Insider Preview, it failed to handle or validate external changes made to the NetBufferList (NBL) structures. This triggered a KERNEL_SECURITY_CHECK_FAILURE (Bugcheck 0x139, Subcode 0xe / FAST_FAIL_INVALID_REFERENCE_COUNT) inside NETIO!FeNblTrackAcquireRef, resulting in an immediate system crash (BSOD).
The Loop: CoreLibs Parser Deadlock & Memory Ballooning
Following the abrupt system shutdown, the local filter database (agflm_dns) in %programdata%\AdGuard\FLM\ was left in a corrupted state. Upon subsequent system boots, AdGuard's parsing engine failed to recover or gracefully handle the corrupted binary structure. Instead of discarding the cache, it entered an infinite processing loop:
AdguardSvc.exe and Adguard.exe continuously generated high CPU utilization.
Memory allocation rapidly expanded, reaching a permanent plateau of ~3.5 to 4 GB RAM split symmetrically between the service and the WPF GUI over IPC queues.
The GUI became completely unresponsive, eventually causing a .NET runtime deadlock (STATUS_BREAKPOINT at clr!CLREventWaitHelper2) due to thread pool starvation from the non-stop IPC message flood.
Post-Fix State (Verification after 1 hour of runtime):
After forcefully terminating all processes and manually deleting the corrupted %programdata%\AdGuard\FLM\ directory, the application was restarted.
The parsing engine successfully recompiled a healthy database structure from scratch.
After over an hour of continuous operation and heavy browsing, the issue has completely stabilized.
Current baseline resource usage has dropped drastically to standard values: AdguardSvc.exe sits at ~460 MB RAM and Adguard.exe sits at ~409 MB RAM, with CPU utilization returning to 0%.
Additional Information
UPDATE: Root Cause Analysis (WireGuard / NordLynx Interoperability)
After completely uninstalling AdGuard, the system experienced a subsequent bugcheck pointing directly to the conflict catalyst: wireguard.sys (the underlying engine for NordVPN's NordLynx protocol).
Subsequent Crash Analysis (WinDbg Output)
Plaintext
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
Arguments: 0000000000000169, 0000000000000002, 0000000000000000, fffff8001046def0
FAILURE_BUCKET_ID: AV_wireguard!unknown_function
FAULTING_THREAD: ffff92502bcf2440
STACK_TEXT:
nt!KiPageFaultDispatchTrap+0x178
ndis!ndisNblTrackerTransferOwnershipInternal+0xd0
ndis!NdisNblTrackerTransferOwnership+0x39
tcpip!UdpDeleteMessageIndication+0x45
tcpip!UdpTlProviderReleaseIndicationList+0x69
wireguard+0x1a1ca
Refined Conclusion for Devs
The crash loop is an architecture-level race condition inside the Windows Filtering Platform (WFP) on Windows 11 Insider Preview (rs_prerelease).
wireguard.sys attempts to release/transfer ownership of UDP tracking buffers (ndis!NdisNblTrackerTransferOwnership) at a high IRQL level while AdGuard's adgnetworkwfpdrv.sys is concurrently processing or cloning the same network buffer lists (NBL).
When AdGuard is pulled out of the stack or crashes, the remaining wireguard.sys hits a null-pointer reference (0x169) because the network stack is already corrupted.
Temporary Fix: Switching the VPN protocol from NordLynx (WireGuard) to OpenVPN completely mitigates the kernel panic, allowing the network stack to stabilize.
Please answer the following questions for yourself before submitting an issue
AdGuard version
8.0.5468.0
Browser version
Edge 149.0.4022.33
OS version
Windows 11 Pro Insider Preview (Build 29599.1000 / rs_prerelease)
Traffic filtering
Ad Blocking
AdGuard Base filter
Privacy
AdGuard Tracking Protection filter, EasyPrivacy, AdGuard URL Tracking filter
Social
AdGuard Social Media filter
Annoyances
AdGuard Cookie Notices filter, AdGuard Popups filter, AdGuard Other Annoyances filter, Adblock Warning Removal List, EasyList Cookie List
Security
Scam Blocklist by DurableNapkin, Phishing URL Blocklist, Online Malicious URL Blocklist
Other
No response
Language-specific
EasyList Polish, Polish Anti Adblock Filters, Polish Annoyances Filters, Polish Social Filters
Which DNS server do you use?
AdGuard DNS
DNS protocol
None
Custom DNS
There are two major interoperability and performance defects discovered in AdGuard for Windows (v8.0.5468.0) running on Windows 11 Insider Preview (Build 29599.1000, rs_prerelease).
Infinite Loop / Memory Leak on Startup: The AdGuard engine (AdguardSvc.exe and Adguard.exe) enters an infinite loop while compiling/parsing the local filter database (agflm_dns in %programdata%\AdGuard\FLM). This results in 100% CPU utilization on high-end processors and memory consumption spiraling up to 3.5 - 4 GB RAM (symmetrically allocated between the Service and GUI via IPC queues). The only remedy is a hard delete of the FLM directory.
Kernel Panic (BSOD 0x139): AdGuard’s WFP driver (adgnetworkwfpdrv.sys) experiences a race condition / reference count invalidation when interacting with other kernel-mode packet inspection drivers (specifically NDivert.sys utilized by NordVPN's Threat Protection).
Crash Analysis (WinDbg Outputs)
Issue 1: GUI Context / Deadlock on GC Disable
When the memory ballooning occurs, forcing a memory dump on Adguard.exe shows the main thread freezing on a native call while trying to transition from managed to preemptive GC mode:
STATUS_BREAKPOINT (0x80000003) inside clr!CLREventWaitHelper2
STACK_TEXT:
ntdll!NtWaitForSingleObject+0x14
KERNELBASE!WaitForSingleObjectEx+0xad
clr!CLREventWaitHelper2+0x32
clr!Thread::RareDisablePreemptiveGC+0x15d
clr!JIT_RareDisableHelperWorker+0x39
WindowsBase!MS.Win32.UnsafeNativeMethods.GetMessageW+0x12
PresentationFramework!System.Windows.Application.RunDispatcher+0x71
Adguard!Adguard.App.Main+0x308
Diagnosis: The WPF GUI application is flooded with IPC messages from the spinning service, blocking the .NET Garbage Collector from compacting the heap, freezing the message loop.
Issue 2: Kernel Bugcheck 0x139 (BSOD)
The system crashes with a KERNEL_SECURITY_CHECK_FAILURE when both AdGuard and NordVPN inspect network traffic concurrently on the rs_prerelease branch:
BugCheck 139, {e, ffff9322d17d6260, ffff9322d17d61b8, 0}
EXCEPTION_CODE_STR: FAST_FAIL_INVALID_REFERENCE_COUNT (0xe)
FAULTING_IP: NETIO!FeNblTrackAcquireRef+0x52
STACK_TEXT:
nt!KeBugCheckEx
NETIO!FeNblTrackAcquireRef+0x52
fwpkclnt!FwpsAllocateCloneNetBufferList0+0x99
tcpip!TlShimInjectRedirectedPacket+0xed
fwpkclnt!FwpsInjectTransportSendAsync0+0x63
adgnetworkwfpdrv+0xa5fe
Diagnosis: adgnetworkwfpdrv.sys and NDivert.sys are modifying the same NetBufferList (NBL) structures simultaneously. Windows Filtering Platform (WFP) registers an invalid object reference count, triggering an immediate security panic to prevent memory corruption.
What Stealth Mode options do you have enabled?
No response
Support ticket ID
No response
Issue Details
Steps to reproduce:
Environment Setup: Ensure you are running Windows 11 Insider Preview (Build 29599.1000, rs_prerelease gałęzi).
Co-existing Software: Install NordVPN and enable its Threat Protection feature (which registers the NDivert.sys kernel driver to intercept network traffic).
AdGuard Configuration: Install AdGuard for Windows (v8.0.5468.0) with the default WFP network filtering driver enabled (adgnetworkwfpdrv.sys).
Trigger Crash: Generate heavy network traffic (e.g., browse media-heavy websites, stream video, or run Docker containers routing traffic through virtual switches).
Result: The system immediately triggers BSOD 0x139 (KERNEL_SECURITY_CHECK_FAILURE) pointing to NETIO!FeNblTrackAcquireRef.
Trigger Bootloop: Reboot the machine after the BSOD and attempt to start the AdGuard service.
Result: The corrupted database state causes AdguardSvc.exe to drop into an infinite parsing loop, hitting 100% CPU utilization and ballooning to ~4 GB RAM
Expected Behavior
No Kernel Panic (BSOD): AdGuard's WFP driver (adgnetworkwfpdrv.sys) should properly coordinate or fail-safe when another kernel driver (like NDivert.sys) modifies the NetBufferList reference counts, instead of causing a FAST_FAIL_INVALID_REFERENCE_COUNT kernel crash.
Graceful Error Handling in CoreLibs: If the local filter database (agflm_dns) becomes corrupted due to an abrupt system shutdown (BSOD), the parser engine should catch the exception, discard the corrupted cache file, and regenerate a healthy one automatically. It must never enter an infinite loop that isolates CPU cores and drains system memory to the point of a user-mode deadlock.
Actual Behavior
Screenshots
Screenshot 1
The Loop: CoreLibs Parser Deadlock & Memory Ballooning
Following the abrupt system shutdown, the local filter database (agflm_dns) in %programdata%\AdGuard\FLM\ was left in a corrupted state. Upon subsequent system boots, AdGuard's parsing engine failed to recover or gracefully handle the corrupted binary structure. Instead of discarding the cache, it entered an infinite processing loop:
AdguardSvc.exe and Adguard.exe continuously generated high CPU utilization.
Memory allocation rapidly expanded, reaching a permanent plateau of ~3.5 to 4 GB RAM split symmetrically between the service and the WPF GUI over IPC queues.
The GUI became completely unresponsive, eventually causing a .NET runtime deadlock (STATUS_BREAKPOINT at clr!CLREventWaitHelper2) due to thread pool starvation from the non-stop IPC message flood.
Post-Fix State (Verification after 1 hour of runtime):
After forcefully terminating all processes and manually deleting the corrupted %programdata%\AdGuard\FLM\ directory, the application was restarted.
The parsing engine successfully recompiled a healthy database structure from scratch.
After over an hour of continuous operation and heavy browsing, the issue has completely stabilized.
Current baseline resource usage has dropped drastically to standard values: AdguardSvc.exe sits at ~460 MB RAM and Adguard.exe sits at ~409 MB RAM, with CPU utilization returning to 0%.
Additional Information
UPDATE: Root Cause Analysis (WireGuard / NordLynx Interoperability)
After completely uninstalling AdGuard, the system experienced a subsequent bugcheck pointing directly to the conflict catalyst: wireguard.sys (the underlying engine for NordVPN's NordLynx protocol).Subsequent Crash Analysis (WinDbg Output)
Plaintext
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
Arguments: 0000000000000169, 0000000000000002, 0000000000000000, fffff8001046def0
FAILURE_BUCKET_ID: AV_wireguard!unknown_function
FAULTING_THREAD: ffff92502bcf2440
STACK_TEXT:
nt!KiPageFaultDispatchTrap+0x178
ndis!ndisNblTrackerTransferOwnershipInternal+0xd0
ndis!NdisNblTrackerTransferOwnership+0x39
tcpip!UdpDeleteMessageIndication+0x45
tcpip!UdpTlProviderReleaseIndicationList+0x69
wireguard+0x1a1ca
Refined Conclusion for Devs
The crash loop is an architecture-level race condition inside the Windows Filtering Platform (WFP) on Windows 11 Insider Preview (rs_prerelease).
wireguard.sys attempts to release/transfer ownership of UDP tracking buffers (ndis!NdisNblTrackerTransferOwnership) at a high IRQL level while AdGuard's adgnetworkwfpdrv.sys is concurrently processing or cloning the same network buffer lists (NBL).
When AdGuard is pulled out of the stack or crashes, the remaining wireguard.sys hits a null-pointer reference (0x169) because the network stack is already corrupted.
Temporary Fix: Switching the VPN protocol from NordLynx (WireGuard) to OpenVPN completely mitigates the kernel panic, allowing the network stack to stabilize.