NPF_TapEx takes too long to process each NBL

[dmiller-nmap]

The NPF_TapEx function is registered as the FilterReceiveNetBufferLists callback. It is responsible for processing each packet that passes through the stack so that Npcap applications can receive them. It runs at DISPATCH_LEVEL, so it's important that it doesn't take too long.

We have seen crash reports via Microsoft Hardware crash telemetry that show that in some cases, NPF_TapEx is taking too long at DISPATCH_LEVEL and Windows chooses to BSoD, assuming that the driver is behaving badly. Additionally, enabling some extra checks (not sure which ones) in Driver Verifier will cause BSoD with BUGCHECK 0xc4 0x92012, "Timeout on receiving a NET_BUFFER_LIST by FilterReceiveNetBufferLists (in the upper driver)"

The proposed solution is to copy the NBL and delegate an IO_WORKITEM for processing, allowing the Npcap driver to pass the NBL up the stack quickly with minimal impact to system performance.

[dmiller-nmap]

In addition to (or as a result of) taking too long, Npcap may not be giving resources back to underlying drivers quickly enough. Our first step should be to make sure NPF_TapEx checks whether the lower driver needs the storage for the NBL returned immediately. If so, it should make a copy of the NBLs and return the original before moving on to process the copy. Once this is done and works well, we can investigate IoWorkItems, etc.

[dmiller-nmap]

Npcap 0.9991 features a version of this idea. Packet data is copied and queued to write to buffer, eliminating contention over the buffer. Additionally, several spinlocks were changed to ReadWriteLocks, which should prevent excessive time being taken in this function.

I am closing this issue, with the understanding that future testing or telemetry may turn up similar problems in the future, at which point we would open a new issue.