How to Use Windows Resource Manager Policies to Throttle CPU Allocation for Legacy IIS Application Pools

When hosting legacy ASP.NET or Classic ASP applications on Microsoft Internet Information Services (IIS), administrators frequently encounter runaway processes. Unlike modern microservices, monolithic legacy applications often suffer from infinite loops, inefficient database queries, or memory leaks that can cause the w3wp.exe (IIS Worker Process) to monopolize 100% of the server’s CPU. This instantly starves all other application pools hosted on the same Windows Server, causing a catastrophic, server-wide outage. To isolate these legacy applications and ensure fair resource distribution, administrators must implement CPU throttling using Windows System Resource Manager (WSRM) policies.

The Limitations of Native IIS Throttling

IIS does possess built-in CPU throttling capabilities within the Advanced Settings of an Application Pool. However, the native IIS implementation is blunt. If a worker process exceeds the CPU limit, IIS typically handles it by either killing the worker process entirely (terminating all active user sessions) or restricting the process to a specific CPU affinity (locking it to Core 0, for example). Neither solution is ideal for high-availability enterprise environments.

WSRM offers a far superior, dynamic approach. Instead of terminating the process, WSRM actively monitors the CPU scheduling at the kernel level. If a process exceeds its allocated quota, WSRM dynamically lowers the thread priority of that specific process, ensuring other applications receive CPU cycles while allowing the legacy application to continue functioning, albeit slower.

Installing the WSRM Feature

WSRM is not installed by default on Windows Server. To enable it, open an elevated PowerShell prompt and execute the following command to install the feature and its associated management tools:

Install-WindowsFeature -Name WSRM -IncludeManagementTools

Once installed, launch the Windows System Resource Manager console from the Administrative Tools menu.

Creating a Process Matching Criteria

Before you can throttle an application pool, WSRM needs to know exactly which process to target. Because all IIS application pools execute under the generic w3wp.exe executable, you cannot simply throttle the w3wp.exe name, as that would throttle every website on the server.

You must differentiate them using command-line arguments. When IIS launches a worker process, it appends the application pool name to the command line using the -ap flag (e.g., w3wp.exe -ap "LegacyAppPool").

1. In the WSRM console, expand the Process Matching Criteria node.
2. Right-click and select New Process Matching Criteria.
3. Name the criteria (e.g., LegacyAppPool_Match).
4. Click Add. In the application field, type w3wp.exe.
5. Crucially, in the Command line field, type exactly: *LegacyAppPool* (using asterisks as wildcards).
6. Click OK to save the criteria.

Configuring the Resource Allocation Policy

Now that WSRM can positively identify the rogue application pool, you must define the restriction limits.

1. Right-click on the Resource Allocation Policies node and select New Resource Allocation Policy.
2. Name the policy (e.g., IIS_Throttling_Policy).
3. Click Add to create a new resource allocation.
4. In the Process Matching Criteria dropdown, select your newly created LegacyAppPool_Match.
5. Under the CPU Allocation (%) field, set your maximum limit (e.g., 30). This dictates that this specific application pool may not consume more than 30% of the total aggregate CPU resources on the server.
6. Ensure the “Standard” policy is applied to the remaining 70% to allow normal system operations.
7. Click OK to save the policy.

Enforcing the Policy

To activate the throttling, right-click your newly created IIS_Throttling_Policy and select Set as Managing Policy.

WSRM will immediately begin intercepting CPU scheduling for the server. If the legacy application enters an infinite loop and attempts to consume the entire processor, WSRM will forcefully cap its utilisation at 30%. The rogue application will run slowly, but the remaining 70% of the CPU remains entirely free for other application pools, the operating system, and critical management daemons, effectively neutralizing the blast radius of unstable legacy code.