UPDATED: 23 August 2021 see here
As I mentioned a while ago, it seems there’s a strangely fatal bug in the Windows networking stack at present. This manifests as massive non-paged pool memory usage if a process creates a UDP socket, binds it to an address and fails to read from it faster than other people are writing to it. The issue appears to be present on all current Windows operating systems but is NOT present on Windows Server 2012 R2 if recent patches have NOT been applied but IS present as soon as the box is patched up to date… My test box was patched up until March 2020 and ran fine, as soon as it was patched to June 2020 it started to behave badly. Rolling back the updates fixed the problem.
The issue appears to affect inbound AND outbound UDP data flow (which makes it harder to run the DDOS clients from a fully patched Windows box as that can run out of non-paged pool when sending massive amounts of datagrams using overlapped I/O). It’s possibly a firewall issue, probably an NDIS intermediate driver that is buffering when it shouldn’t.
In summary, if you create a UDP socket and bind it to an address then someone can kill your box just by sending lots of datagrams at it… You might not notice this straight away as ’lots’ is related to how fast you process the datagrams. A simple program that creates a socket, binds it to an address and then never reads from it will demonstrate the problem. All you have to do is watch the “\Memory\Pool Nonpaged Bytes” performance counter until your box dies. You can see this in action if you write a program that sends datagrams to the listening program in a tight loop. A real network connection doesn’t appear to be required.
I’m more than happy for someone to prove me an idiot by showing me that this problem is my fault and not a networking stack or driver bug.