Server 2019 crashing

[gocart879]

Hello, I recently applied the Windows server 2019 feature update for September 2025 on a Dell Server that has hosted the Softether platform since 2021.

It has been rock solid, never down, always functioning as intended. Now since the update, the Windows OS blue screens and crashes regularly if someone is connected to the VPN.

I am getting this type of error occasionally in the BSOD minidump file: seLow_x64.sys which pointed me to the VPN. I was on 4.34, now updated to 4.44 or the latest. Nothing else on the server has changed. Does anyone have any suggestions?

I am at a loss, other than removing this from the server and putting it on some different hardware, which I really would prefer not to do. This server has 128gb of RAM and an Intel Gold processor, so it is pretty high end and I really dont see it using all of the available memory.

Without using the VPN ( or connected to it ) the server will be stable and wont crash. I went over seven days without an issue.

[solo]

viewtopic.php?f=7&t=69631#p103374

[gocart879]

I do not see a defrag service on this box. I did locate a scheduled task, disabled it and still see a crash during vpn use.

I updated to the October update for Windows, peeled Softether off, reinstalled and will check again to see if crashing occurs again.

Is the Github edition any better ? I tried to download but google identified it as a virus. So i was a little stuck.

[solo]

I noticed that one of the services was occasionally using ALL RAM, it was windows defragmentation.
I believe with no RAM left, calling function in SeLow_x64.sys ends up with DRIVER_IRQL_NOT_LESS_OR_EQUAL and system crashes, all this when Local Bridge is set up and SoftEther VPN server is online.
I stopped defragmentation service and have not had any restarts or RAM Issues anymore.

SE's SeLow driver indeed requests to "Allocate the non-paged memory" (source code) so the above observation seems valid. Perhaps a different process occasionally occupies the entire RAM in your case.

Also please check if TCP Receive Window Auto-Tuning Level fixes the problem.
- current status: netsh int tcp show global
- if "Receive Window Auto-Tuning Level = normal", set: netsh int tcp set global autotuninglevel=disabled
- reboot
- test SE
If ineffective, set it back to presumably "normal": netsh int tcp set global autotuninglevel=normal

The Github's edition is safe.