WSRM memory leak and CPU quota transition

Question

WSRM memory leak and CPU quota transition

Manish Rahul 60

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 ?

0 comments

1 answer

Your answer

Answer 1

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.