How to set process priority in Windows (and why the registry method you found is wrong)

---

Windows lets you tell the scheduler that one process matters more than another. It is a genuinely useful control, it is buried, and the most-copied instructions for making it stick are wrong in a way that quietly does nothing.

Here are the three methods, what each one actually does, and why the one everybody wants is usually the wrong thing to want.

What priority actually changes

A priority class does not allocate CPU. It does not reserve cores, and it does not make a process run faster when the machine is idle.

What it changes is who wins when two threads are ready to run and there is one core free. Raise a process and it gets picked sooner and preempted less. Lower a process and it yields to everything above it.

The consequence matters: if your CPU is not saturated, changing priority does nothing at all. There is no queue to reorder. Priority is a tool for contention, and only for contention.

The six classes, from the top:

• Realtime — outranks most of the operating system. See the warning below.
• High — above everything normal, including much of Windows.
• Above normal
• Normal — where essentially everything starts.
• Below normal
• Low / Idle — runs only when nothing else wants the CPU.

Method 1: Task Manager, for right now

The one that works and is honest about being temporary.

1. Ctrl+Shift+Esc, then the Details tab. Not Processes — the option is not there.
2. Right-click the process → Set priority.
3. Pick a class and confirm the warning.

This lasts until the process exits. Launch the app tomorrow and it is Normal again. That is not a bug or an oversight; it is what "set the priority of this running process" means.

Same thing from a terminal, if you prefer:

Start-Process app.exe -Priority High to launch one, or (Get-Process app).PriorityClass = 'High' to change one already running. In cmd, start /high app.exe.

Method 2: the registry, for permanently — done correctly

This is where the misinformation is, so read the values carefully.

The correct location is a PerfOptions subkey, and the value is named CpuPriorityClass:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\yourapp.exe\PerfOptions

Create a DWORD (32-bit) named CpuPriorityClass with one of these:

• 1 — Idle / Low
• 2 — Normal
• 3 — High
• 4 — Realtime
• 5 — Below normal
• 6 — Above normal

The version you will find everywhere else

A large number of articles tell you to create a DWORD called PriorityClass directly under the yourapp.exe key, with values like 128 for idle, 32 for normal, 32768 for high and 16384 for realtime.

That is wrong twice over, and it is worth knowing why, because the same numbers keep getting copied between sites.

Those values are the dwCreationFlags constants a programmer passes to CreateProcess — NORMAL_PRIORITY_CLASS is 32, HIGH_PRIORITY_CLASS is 128, ABOVE_NORMAL_PRIORITY_CLASS is 32768, BELOW_NORMAL_PRIORITY_CLASS is 16384. So even taken on their own terms, the mapping in those articles is scrambled: 128 is High, not Idle; 32768 is Above normal, not High; 16384 is Below normal, not Realtime.

And they are in the wrong place under the wrong value name, so Windows never reads them regardless. The result is an article full of confident steps, a registry edit that appears to succeed, and no change whatsoever. If you tried this and concluded it "needs a restart", it did not — it needed different instructions.

Two things to know before you use it

The key is matched on the executable's file name, not its path. A rule for chrome.exe applies to every chrome.exe on the machine, forever, whatever launched it.

Image File Execution Options is also the same mechanism used to attach a debugger to a process at launch, and it is a well-known persistence technique. Some security software watches it. On a managed work machine, expect that an edit here may be noticed.

Never set Realtime

Realtime is not "High, but more". It places your process above most kernel threads, including the ones servicing input and disk.

A busy process at Realtime can stop the mouse responding, prevent you from opening Task Manager to undo it, and leave a reboot as the only way out. Windows requires an elevated privilege to grant it, which is a reasonable hint.

If you genuinely need more than Normal, High is the ceiling worth using, and Above normal is usually enough.

Why permanent High is usually the wrong answer

Say you set your game or your renderer to High in the registry, permanently. Consider what that means for the rest of the day.

That process now outranks the audio stack, the compositor, and parts of Windows itself — while it is minimised, while it is idle in the tray, while you are doing something else entirely. Reports of stuttering audio, dropped frames and unresponsive input after "optimising" priorities are usually this: a permanent rule applied to a temporary situation.

And it does not do the thing people are actually after. Raising one process by three classes helps far less than lowering the thirty background processes competing with it, because the contention is spread across all of them. But nobody is going to maintain thirty registry keys by hand — and if they did, those rules would apply constantly, including when none of it matters.

The real requirement is almost always conditional: while I am rendering, this matters more than that. Neither Task Manager (manual, forgotten on exit) nor the registry (permanent, context-blind) can express a condition.

The shape of a better answer

What you want is for the rule to know when it applies.

That is what we are building AppFreeze to do. It watches for the application you said matters, applies the priority arrangement you configured once, and — the part that distinguishes it from a registry edit — takes a snapshot first and restores every process to exactly the class it had when you close the app. There is no permanent state left on the machine.

It is not a RAM cleaner and it does not have a "boost" button, because neither of those does what it claims. It reorders a queue while the queue matters, and then stops.

In development now. The newsletter below is how you will hear when it ships.

Quick reference

• Temporary, one process, right now — Task Manager → Details → Set priority.
• Scripted at launch — start /high app.exe, or PowerShell's Start-Process -Priority.
• Permanent and global — IFEO\yourapp.exe\PerfOptions → CpuPriorityClass DWORD, 1/2/3/5/6. Not PriorityClass, and not 32768.
• Never — Realtime.
• If the CPU is not saturated — none of this will change anything. Find out what is using it first.