I’m following up to check whether the issue has been resolved. Feel free to reply if you need further information. If the information provided was helpful, please click "Accept Answer" to help others in the community. Thank you!
WSRM memory leak and CPU quota transition
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(246.4, 43%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMR%3C/text%3E%3C/svg%3E)
Manish Rahul
60
Reputation points
On dense terminal servers, the WSRM service (wsrm.exe) suffers from nonpaged pool memory leaks. This often results in STOP 0x0000009F host crashes, severely impacting server stability when many RDS sessions are active. Since WSRM is outdated and no longer optimized, the practical solution is to decommission WSRM and move resource management to Group Policy CPU Quotas.
How can we safely decommission WSRM and transition to Group Policy CPU Quotas for effective resource management ?
Windows for business | Windows 365 Business
2 answers
Sort by: Most helpful
-
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(172.8, 86%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJN%3C/text%3E%3C/svg%3E)
Jason Nguyen Tran 27,210 Reputation points Independent Advisor2026-09-29T05:33:25.4266667+00:00 -
Jason Nguyen Tran 27,210 Reputation points Independent Advisor
2026-09-08T02:31:08.51+00:00 Hello Manish Rahul,
You’re absolutely right that WSRM has known stability issues, including nonpaged pool leaks, and it’s no longer recommended for modern RDS environments. The safe path forward is to decommission WSRM and transition to Group Policy CPU Quotas, which are actively supported and far more reliable.
The recommended sequence is:
First, disable WSRM policies and stop the WSRM service across your terminal servers.
Remove WSRM from startup to ensure it doesn’t re-engage after reboot.
- Next, configure CPU Quotas via Group Policy under Computer Configuration > Administrative Templates > System > Processor Scheduling. This allows you to define per-user or per-group CPU limits without relying on WSRM.
Apply the policy gradually across your farm, testing with a subset of servers before rolling out broadly.
Monitor performance counters to confirm that quotas are being enforced as expected.
This approach ensures a clean transition without risking STOP errors or resource contention. If this answer helps you move forward, please don’t forget to hit “accept answer”
Jason.