Windows kext 2.1.1.0: DPC_WATCHDOG_VIOLATION (0x133) with the stack in portmaster_kext

[Doombringerz]

Pre-Submit Checklist:

Checked the Windows known issues and the existing bug issues. #2035 is the 0xD1 below, fixed in v2.1.18. It's only here for context. #385, #1723 and #1788 are DPC watchdog reports on older kext versions, all closed. #2271 is a different bugcheck (0x50) on the same 2.1.1 kext.

What happened:

Two bugchecks on the same machine, both pointing at portmaster_kext in !analyze -v on the minidumps.

1. 2026-09-16, Portmaster 2.2.1, kext 2.1.1.0

DPC_WATCHDOG_VIOLATION (133), args (1, 1e00, fffff80177dc53c8, 0). Arg1 is 1, so cumulative time at DISPATCH_LEVEL, not one single DPC.

Bucket: 0x133_ISR_portmaster_kext!unknown_function, DPC_QUEUE_EXECUTION_TIMEOUT_EXCEEDED

portmaster_kext+0x4620
portmaster_kext+0x26795

Kext SHA-256: e07d172667bddc606c6a76079ed3e79281fa23ebbe68a9740ee71ea681b55d4d (the signed 2.1.1.0 build, same hash as in #2271). Offsets are against that build.

2. 2026-09-08, Portmaster 2.0.25, kext 2.0.7.0 (before the v2.1.18 fix, probably #2035)

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1), args (ffff940dff79bf20, 2, 0, fffff806516a30c0), process portmaster-cor.

Bucket: AV_fwpkclnt!FwppInjectionStackCallout

fwpkclnt!FwppInjectionStackCallout+0xe8
fwpkclnt!FwppInjectTransportSendAsync
fwpkclnt!FwpsInjectTransportSendAsync1
portmaster_kext+0xcc82

Now on Portmaster 2.2.3. The loaded kext is still 2.1.1.0, the same build as crash 1.

What did you expect to happen?:

No bugcheck.

How did you reproduce it?:

Can't reproduce it on demand. Context around crash 1, in case it matters:

• The NVMe was logging a high rate of media errors that day, so storage I/O was retrying a lot.
• The EasyAntiCheat EOS filesystem filter loaded 8 seconds before the crash. It has loaded several times since without a crash, so on its own it doesn't trigger it.

Debug Information:

• Windows 11 Home, build 26200
• MSI GE76 Raider laptop
• Killer network driver also loaded (KfeCo11X64.sys 10.3.10.25), which has its own filter in the network stack

Happy to run more debugger commands against the dumps if that helps.

[github-actions]

Greetings and welcome to our community! As this is the first issue you opened here, we wanted to share some useful infos with you:

• 🗣️ Our community on Discord is super helpful and active. We also have an AI-enabled support bot that knows Portmaster well and can give you immediate help.
• 📖 The Wiki answers all common questions and has many important details. If you can't find an answer there, let us know, so we can add anything that's missing.

[stenya]

Thanks, this is a useful report, and it led to a change in kext 2.1.2 (Portmaster v2.2.4-Staging, PR #2285).

Crash 2 (0xD1 in FwppInjectionStackCallout, kext 2.0.7) is #2035, as you suspected. It is fixed since kext 2.1.0 and needs no further action.

Crash 1 (0x133, kext 2.1.1)

I cannot name the root cause from the two offsets alone, but the shape of the crash matches a weakness in the driver's panic handler that is now fixed. Until 2.1.1 the handler logged the panic and entered an endless loop. A panic inside a callout therefore pinned that CPU at DISPATCH_LEVEL until the system died minutes later with a generic DPC_WATCHDOG_VIOLATION, pointing at a timeout rather than at the actual failure. The log call also allocated, so an out-of-memory panic could panic again inside the handler. Your context, an NVMe retrying heavily and a filter driver loading shortly before, fits a slow or failing allocation path, but that is a guess, not a finding.

In 2.1.2 (commit c0a6ba6) the handler calls KeBugCheckEx immediately with code 0x504D7273 ("PMrs"). Nothing on that path allocates.
So the next crash, if there is one, names the file, line and message directly and will be attributed to the driver instead of to the watchdog.