When a PC is under heavy load, you may want to kill the process responsible, only to find that Task Manager itself has stopped responding. Why doesn't Windows run the taskbar and Task Manager at high priority to prepare for exactly this situation? Raymond Chen, who has worked on Windows development at Microsoft for more than 30 years, answered this question in a post on his blog The Old New Thing, dated October 27, 2026.
According to Chen, when CPU time runs short, every process is affected, and Task Manager, the tool meant to fix the problem, is no exception. Simply raising its execution priority doesn't help if it has to wait for a resource that another thread is holding; until that resource is released, it cannot make progress. Windows already has mechanisms that favor the app the user is working with, but some waits remain that those mechanisms cannot eliminate. Note that this explanation concerns Windows' existing scheduling mechanisms; it is not an announcement of a new Windows 11 feature or a bug fix.
Why raising Task Manager's priority can't guarantee responsiveness
When the CPU has no headroom, not only the process that caused the load but also the taskbar and Task Manager slow down. Running these tools at high priority might seem to solve the problem, but Chen explains that the fundamental issue is that waiting on shared resources cannot be avoided.
Chen compares the mechanism to a priority checkout lane at a supermarket. A priority pass puts you at the front of the line, but the customer ahead of you at the register may be paying for a huge cart of groceries. No matter how much priority you have, your turn doesn't come until that customer's payment is finished. Raising CPU execution priority works the same way: it can move up the order in which processing starts, but it doesn't make resources held by other processes instantly available.
These waits fall into two broad categories. The first is having to wait for a thread that holds a shared resource to finish its work. If a high-priority thread tries to acquire a lock held by a low-priority thread, it cannot proceed until the low-priority thread finishes and releases the lock. Worse, if a medium-priority thread preempts the low-priority thread, the release of the resource is delayed, and the high-priority thread may be kept waiting.
This phenomenon is called priority inversion. Windows has a mechanism that mitigates delays from priority inversion by temporarily raising the priority of the thread holding the resource. However, as Chen points out, this has no effect when the thread holding the resource is itself performing a time-consuming operation, such as accessing a file over the network. Raising its priority doesn't change the fact that you have to wait for that operation to finish.
The second category is contention involved in user interface (UI) processing. UI applications, including the taskbar and Task Manager, ultimately have to call into the Windows UI system. In doing so, they may contend with other UI threads using the same system, so raising the application's priority alone cannot guarantee responsiveness. Chen explains that such problems are especially pronounced in UI processing, but he does not identify exactly which locks or components the contention occurs in.
Windows already prioritizes the app you're using
Windows uses 32 levels of scheduling priority, from 0 to 31, to allocate CPU time to threads. The lowest priority, 0, is reserved for the zero-page thread, a system thread that fills free memory pages with zeros. According to Microsoft Learn's documentation on scheduling priorities, the Windows scheduler assigns CPU time to the highest-priority runnable thread. Threads of the same priority are given execution time in turn using round-robin scheduling, and when a higher-priority thread becomes runnable, the current thread is switched out even before it has used up its time slice.
Windows also has mechanisms that favor the app the user is currently working with. One is the priority boost, which temporarily raises a thread's dynamic priority. Each thread has a base priority, and the scheduler raises the dynamic priority as needed to improve responsiveness. However, according to the official documentation on priority boosts, this mechanism applies only to threads with a base priority of 0 to 15, not to threads at 16 to 31.
There are three main conditions under which priority is raised. First, when a process running in the normal priority class (NORMAL_PRIORITY_CLASS) comes to the foreground, its priority class is adjusted to be at least that of background processes. Second, when a window receives input such as mouse, keyboard, or timer events, the dynamic priority of the thread that owns the window is raised. Third, when a waiting thread becomes runnable, for example because disk I/O has completed, its priority is also temporarily raised.
The boosted priority is not permanent, though. Each time a thread uses up its allotted execution time, its dynamic priority drops step by step, eventually returning to the base priority. This lets the system prioritize processing that responds to input while still giving other threads CPU time.
AutoBoost reduces waits caused by priority inversion
Windows also provides AutoBoost, which deals with priority inversion caused by waiting on shared resources. Microsoft Learn's documentation on priority inversion explains this mechanism using three threads.
First, thread T1, at priority 4, acquires a lock. Then T2, at priority 8, starts running, and T1's work is interrupted. Next, T3, at priority 12, becomes runnable and tries to acquire the lock held by T1, so T3 has to wait until T1 releases it. But even while T3 waits, T2 at priority 8 runs ahead of T1 at priority 4, so T1 cannot release the lock, and as a result T3, the highest-priority thread, cannot make progress.
To mitigate this problem, AutoBoost temporarily raises the priority of the thread holding the shared resource. In the example above, T1's priority is raised to 12, the same as the waiting T3, and kept there until it releases the lock. This reduces the time T1 is blocked by the medium-priority T2 and makes it easier for T3 to acquire the resource.
However, what AutoBoost can resolve is only the delay that occurs when the thread holding a resource is prevented from running by other threads. If T1 itself is performing a time-consuming operation such as network access, AutoBoost cannot shorten that operation. As Chen points out, even when the mechanism that prevents priority inversion works correctly, the time spent waiting for a shared resource to be released remains.
QoS adjusts CPU core selection and power management
Another mechanism is QoS (Quality of Service). It specifies the performance and power efficiency a thread requires, and it is particularly important on processors that combine CPU cores with different performance characteristics.
According to Microsoft Learn's documentation on QoS, the main criterion Windows uses to decide which thread to run next is still the scheduling priority. QoS, on the other hand, affects which CPU cores are used and how processor power is managed, in some cases restricting the cores a thread can run on or favoring a particular type of core.
For applications with windows, QoS varies mainly according to visibility and whether the app has focus.
| Application state | QoS | Main treatment |
|---|---|---|
| In the foreground and has focus | High | Prioritizes high performance |
| Visible but without focus | Medium | Balances performance and power efficiency |
| Minimized or fully hidden | Low | Prioritizes power efficiency, especially on battery power |
| Playing audio | High | Prioritizes high performance regardless of visibility |
Also, on battery power, if there has been no user input for a certain period, QoS may be lowered to Medium even for an app in the foreground. This is meant to keep apps that aren't being used from consuming more power than necessary. Chen also refers to this QoS documentation, explaining that Windows already favors the program that has focus.
The main mechanisms by which Windows prioritizes the app being used can be summarized as follows.
| Mechanism | What it adjusts | Main purpose / effect |
|---|---|---|
| Foreground process priority class adjustment | Gives the foreground process a priority class at least equal to background processes | Prioritizes the app being used |
| Priority boost for threads that receive input | Temporarily raises dynamic priority | Speeds up response to mouse, keyboard, and other input |
| AutoBoost | Temporarily raises the priority of the thread holding a resource | Reduces delays caused by priority inversion |
| QoS | Adjusts which CPU cores are used and power management | Balances performance and power efficiency |
Through these mechanisms, Windows adjusts CPU time allocation and the execution environment to improve the responsiveness of the app the user is working with. However, prioritizing CPU execution order doesn't make resources held by another thread immediately available. AutoBoost also only reduces delays from priority inversion; it cannot shorten the processing time of the thread holding the resource. And QoS concerns CPU core selection and power management, so it doesn't directly resolve contention for shared resources.
Therefore, even when these mechanisms work properly, the responses of the taskbar and Task Manager may still be delayed by contention with other threads in the UI system or by waiting for shared resources to be released. Note that the mechanisms listed here are representative ones; other mechanisms that adjust scheduling exist as well, such as the priority boost for threads returning from a wait state. The explanation of each mechanism is based on Microsoft's technical documentation, not on measurements comparing response times under high load.
Running Task Manager at real-time priority is dangerous
Interestingly, Microsoft's own technical documentation includes an example of a process that needs to respond quickly under heavy system load. The official documentation for the SetPriorityClass function cites the "Task List" as an example of using the high priority class (HIGH_PRIORITY_CLASS), describing it as something that must respond promptly when the user calls it up, regardless of the OS load. However, the documentation doesn't spell out how the Task List relates to today's Task Manager, or which priority class taskmgr.exe actually runs in.
The same document warns that setting this requires great care, because a process in the high priority class can consume nearly all CPU time. If a high-priority thread keeps running for a long time, lower-priority threads no longer get enough chances to run. Also, if multiple threads are set to high priority at the same time, the benefit of raising priority itself fades. Threads of the same priority are treated equally, so making everything high priority doesn't solve the execution-order problem.
Even more dangerous is the real-time priority class (REALTIME_PRIORITY_CLASS). This priority may be set higher than the system threads that manage mouse and keyboard input and background disk writes. As a result, running a process that occupies the CPU for a long time at real-time priority can leave the system unable to accept even input. In its official documentation, Microsoft says the real-time priority class should almost never be used for ordinary applications.
Chen had also addressed this issue in a blog post dated June 10, 2010. If a program that uses 100% of the CPU runs at real-time priority, the thread that processes input gets no CPU time either, and the user may be unable to operate the system to terminate the program. Chen is also negative about the idea of simply running Task Manager at real-time priority.
One reason is that the act of launching Task Manager or switching to an existing window is itself not executed at real-time priority. Even if Task Manager could be run at real-time priority, it would then be taking CPU time away from the program that continues running at the same priority. A program specified at real-time priority assumes it will not be interrupted by other work, so giving Task Manager special treatment alone also contradicts the design philosophy of priorities.
In the 2026 post, Chen points out a similar problem. It is difficult to repair a system that is already overloaded using a tool that runs inside that same system. The tool meant to solve the problem may itself be affected by the load, and it becomes harder still if it shares important resources with the process that caused the problem.
Windows already has mechanisms that prioritize the app with focus. So if you can move focus to the taskbar or Task Manager, it gets the benefit of those existing mechanisms. But if the prioritized thread is waiting on a resource held by another thread, that preferential treatment alone cannot restore responsiveness. Whereas the 2010 post dealt with the CPU being monopolized at real-time priority, this latest post explains that even a high priority cannot escape waits on shared resources and UI processing.
Another way to improve responsiveness under load: rein in heavy processes
Instead of raising Task Manager's own priority, you can also rein in the processing of applications that use large amounts of CPU. One such method is Efficiency Mode, built into the Windows 11 Task Manager.
Microsoft announced the introduction of Efficiency Mode in Task Manager in its announcement of Windows 11 Insider Preview Build 22557 on February 16, 2022. It is a renamed version of "Eco mode," which was introduced on a trial basis in April 2021, and it limits the resource usage of apps that consume a lot, making it easier to prioritize other apps. Microsoft explains that this can be expected to improve foreground app responsiveness and power efficiency.
Efficiency Mode can be applied from the Processes page of Task Manager, either by right-clicking the target process or using the command bar. However, it applies to individual processes; you cannot switch an entire process group at once. Also, if the option is grayed out, the process is generally a critical Windows process, and limiting its usage could hurt system performance.
Efficiency Mode does not eliminate every response delay, however. Even if it reduces CPU contention caused by heavy processing, waits may remain if the thread holding a shared resource is running long or if contention occurs in the UI system. Microsoft's explanation also doesn't quantify how much Efficiency Mode improves such problems.
One user limits the number of CPU cores in use to keep the system responsive
In the comments on Chen's post, users also reported trying methods to improve responsiveness under heavy load. Shawn Van Ness explained that when building a large codebase, all 24 cores hit 100% utilization for several minutes, leaving Explorer and the taskbar almost unusable.
Using Windows' Image File Execution Options, Van Ness lowered the priority of the compiler CL.exe and the build tool MSBuild.exe, while raising the priority of TaskMgr.exe. The improvement in responsiveness was slight, however. So he used processor affinity, which limits the CPU cores the build can use, to exclude 2 of the 24 cores. He reports that he began running builds on the remaining 22 cores to keep the PC responsive.
That said, this is one user's experience, and the same settings won't necessarily work in other environments. Results can vary with the CPU configuration, the workload, and the applications used. Also, restricting affinity reduces the choice of cores available to the Windows scheduler, so you have to weigh it against processing performance.
What Chen's explanation shows is that Windows responsiveness is not determined by simple CPU priority alone. Windows already has built-in measures such as favoring the foreground app and countering priority inversion, but waits for shared resources to be released and contention in UI processing cannot always be resolved by those mechanisms. That is why simply raising Task Manager's priority isn't enough.
Efficiency Mode and limiting CPU core usage, on the other hand, are methods that secure the execution resources the app in use needs by adjusting the processes causing the load. However, the effect of Efficiency Mode as described by Microsoft and the improvement from core restriction reported by a user are verified to different standards. To actually reduce operation lag under heavy load, you need to identify which processes are occupying the CPU in your own environment and what kinds of waits are occurring, and then confirm the effect of any settings changes.