When you set a 100% CPU program to real-time priority, you get what you asked for

Real-time priority is really dangerous. It's higher priority than nearly everything else. It's higher priority than mouse input, keyboard input, and the disk cache. If you foolishly set the priority class of a CPU-intensive program to real-time, it will suck up your entire processor, leaving no cycles for anything else.

In particular, since not even input runs at real-time priority, you can't stop it via any interactive means, because the thread that manages input can't even run to process your input.

Mind you, even if the input thread did run at real-time priority, that wouldn't really help you any. Sure, it could receive your input and distribute it to the appropriate application queues, but those applications are themselves not running with real-time priority, so all that happens is that your input gets quickly transferred to the input queues, where it then sits waiting for the applications to process them (which will never happen since the applications are not running with high enough priority).

One might argue that Task Manager should run with real-time priority, so it can extricate you from this situation, but that won't help, and it would be wrong. It won't help because you first need to be able to launch Task Manager (or switch to it, if you were prescient enough to have it already running), and none of the ways of launching Task Manager run with real-time priority. (Because nothing in the user interface runs with real-time priority.)

Second, even if there were a special code path that enabled you to launch Task Manager at real-time priority, it would be wrong, because the fact that Task Manager is running with real-time priority means that it is now stealing CPU cycles from that other process which set itself to real-time priority, which defeats the purpose of that process setting itself to real-time priority in the first place: It set itself to real-time priority because it didn't want anybody stealing CPU time from it!

What could be done is to have Task Manager display an extra warning dialog when somebody uses it to change a process's priority. The warning dialog would say something like "Fiddling with priority can result in you being totally screwed. Are you sure you want to take this risk?" (Oh wait, that dialog box already exists.) Our friend Igor probably clicked right on past that warning dialog, because he's thinking, "Of course I want to set it to real-time priority, you stupid program, that's why I clicked Real-Time Priority! This is another in a long string of examples of how Windows is one of those coddling operating systems that gets in the way of advanced users like me, throwing up frustrating obstacles which prevent me from getting things done."

And then he shoots himself in the foot and asks to be coddled a little bit.

Comments (68)
  1. Wladimir Palant says:

    I must agree with Robert – having that option in the UI is asking for trouble. While there might be some reason to let users modify process priority (occasionally I might want to have some process run faster even though other processes want CPU time as well) I cannot see a single reason to set real-time priority on a process that didn't do it itself.

  2. Tor says:

    So the conclusion is to not set real-time priority unless you have a very good reason. Above normal and high should be enough.

    A question: I remember there is some command line tool (probably from Sysinternals) that allows setting zero priority, effectively pausing a process by never giving it any CPU cycles. Why is this not available from the Task Manager? It is quite useful when I want a program to stop wasting CPU, but don't want to turn it off either.

  3. Dan Bugglin says:

    There was a "game" I had (or possibly, a program designed to translate machine instructions from one chipset into x86 as well as emulate various hardware interfaces, where the chipset and hardware belonged to a specific mass-produced computer system made specifically for playing games…) which supported real time priority as a menu option.  This made it run great until I accidentally unfocused the window.  Then I had to reboot after trying in vain to close the program or refocus the window.

    Any app that allows for this sort of thing should at least have the courtesy of lowering its priority if it is unfocused, since obviously the user wants their CPU power to go elsewhere at that point in time.  DOSBox has this option which works very well (I don't need it anymore but being able to lower the priority to Below Normal or Idle automatically from Normal or Above Normal when switching away is great on an old computer).

    Of course I wouldn't set any priority above Above Normal anyway; if a process runs away with the CPU on a single core system even with just Above Normal, the whole system is sluggish and it will take a while to open Task Manager and kill the process.  The only process that even uses High (or above) is winlogon, since it never runs away with the CPU and is vital to be responsive (it controls the login screen which is sort of important.  Probably other important things too).

  4. Apz says:

    Re: Tor

    The which you are referring to (suspend program) is a great cause of desktop crashes – any application that does an EnumWindows, or a SendMessage on any windows belonging to the suspended program is now blocked. Even a simple step such as Show Desktop (Winkey+D) causes Explorer to go crazy, as it delivers window messages to a window that cannot accept them.

    I can appreciate it is a useful feature to have; but on the other hand; it certainly should be used with caution!

  5. CatCube says:

    @Tor: "I remember there is some command line tool (probably from Sysinternals) that allows setting zero priority, effectively pausing a process by never giving it any CPU cycles. Why is this not available from the Task Manager?"

    I can't check, since I'm on a Vista machine at work, but I think the Win7 Task Manager has this feature.  And under XP, there was a Sysinternals GUI program (I think it was progman) that did this.

  6. Tor says:

    Apz: I suspected something like that. I only used it for command line programs.

  7. Boris says:


    Nope. I'm running Windows 7 x64 and the lowest priority is "low"

  8. Tom says:

    Sysinternals Process Explorer (procexp) allows you to suspend a process.  It's come in handy for me on a number of occasions.  Yes, it should be used with caution.  But I've never had Explorer crash or hang as a result of suspending an application.  I would say maybe I was just lucky, except I'm not that lucky.  Perhaps Explorer is not that dumb.  (Also hard to believe though, I know.)

  9. GregM says:

    Raymond, FYI, it looks like the blog platform update has removed all of the anchors from the individual comments, so the links to the comments now just take you to the article.

    [Yup, I called that out in the relaunch email. I'm told they're working on it. -Raymond]
  10. Scott says:

    Process Explorer's suspend is nice, and fairly safe.  It's not, however, a state for a process actually exposed by the operating system.  IIRC, it's enumerating the threads of a process and explicitly suspending each thread in the process.  It's no wonder the shell team decided such a hack isn't something they want to expose.

    And yeah, if someone tries to do a SendMessage(HWND_BROADCAST, …) or otherwise talk to your app while a GUI app is in this state, they'll happily be blocked too.

  11. Jared says:

    Dear Raymond,

    In your rant you missed the word "personal" in personal computer.  You want me to surrender control of my personal computer to some application which bumped itself to real time priority.

    It's MY computer, and I insist on a way to kill any application I feel is out of control.

    So DO put in that special path to get Task Manager active and able to reset priorities!

  12. No One says:

    I made that mistake once or twice.  Since then I've learned that if I think a program will eat the whole computer but I want to give it a high priority I can just set its affinity before setting priority.

  13. violet says:

    There's a vaguely-compelling argument for some sort of kernel-level interrupt system to either let you kill or change the scheduling priority of runaway RT processes (ala Magic+n, in Linux). Minus a hundred points and all that, though.

  14. rw says:

    What happens if I have a computer with two cores and let's assume the application is onls single-threaded? Will Windows move all other threads to the idle core?

  15. moonshadow says:

    I really want a way of telling the system to suspend all processes, present me with a list of them and let me select one to kill – not nicely ask to quit through the message queues, but forcibly destroy there and then. I understand all the reasons why ctrl+alt+delete, run Task Manager, use the standard UI widgets to display the list etc. cannot be that way, but I'd still really like such a feature to exist.

  16. blah says:

    TRWTF is the existence of the realtime priority class. I have yet to see/hear a legitimate use for such a thing in a preemptive multitasking environment.

  17. Koro says:

    Now there's one thing I do miss from Windows 9x (!!), the fact that the "kill process" Ctrl-Alt-Del dialog box ran in a "special mode" where it would pop up and be responsive no matter how borked the rest of the desktop was. Sure beats the Task Manager, which is "yet another application" and as such, as vulnerable to "desktop freezes" due to stuff such as runaway window hooks, like Spy++ seems to do once in a while (by then I have to use pskill from another machine, much annoying).

  18. Brad Bellomo says:

    If you are running 2 or more cores (and who isn't, today?) wouldn't the extra CPU be available to other threads?

  19. Henke37 says:

    I have to agree, what IS the point of the realtime priority?

    Anyway, why doesn't the taskmanager list the idle priority if it lists the realtime one?

  20. Michael Kohne says:

    Ahh, memories. I remember having written a program that ran at realtime priority (I was grabbing data from a camera), and getting myself into an infinite loop. It never once occurred to me that it was anyone's fault but mine – after all, I set the priority, and I got what I asked for!

  21. Chris Charabaruk says:

    @Brad: Only if you set affinity on the real-time process so that it only used one (or total_cores – 1) core. Try it out.

  22. Leonid says:

    Point of the realtime priority is writing real-time applications, you know.


  23. Pierre B. says:

    The use case for real-time priority is, as implied by Raymond, for non-CPU bound processes. For example, industrial control. (No need to comment on the sanity of using Windows as a an industrial process processing unit instead of a real-time OS. I'm just pointing out a category of work that justifies the existence ofthe feature. Just replace industrial control with MIDI keyboard if you wish.)

  24. Gabe says:

    I think the real question is not "what's the use case for realtime priority?", but "why does Task Manager need a realtime priority option?" — afterall, if you know you need realtime priority, why would you use Task Manager to set it?

  25. abadidea says:

    The community of Dwarf Fortress, a free game that can bring any CPU to its knees, has this problem a LOT. "it was running slow so I changed it to the highest priority, then my whole computer screwed up. I'll go file a bug against Dwarf Fortress!"

  26. Alexandre Grigoriev says:

    Now that multicore system are in the mainstream, a runaway process won't do too much damage; even single-core hyperthreading processor relieves this problem somehow. But still, Windows priority scheme is a bit too rigid. It has a dynamic priority boost concept, to make I/O and GUI bound processes more responsive. But it lacks a dynamic priority demotion, which would detect runaway threads (those that continuously consume their time slices) and dynamically de-prioritise them. This can be made a global-policy configurable parameter, somewhere in ControlSession Manager key, so those rare deployments that actually need rigid priorities would be able to run with the legacy scheme.

    Also, Task Manager runs by default with High base priority. You can start it from Ctrl-Alt-Del screen, which I believe also belongs to High priority process. Unfortunately, this doesn't help against a runaway realtime process. If such a process could be dynamically demoted to High class, then the Task manager would have a chance.

  27. Fry says:

    @Henke37 && @blah: Real-time is indeed useful… for real-time software. Take for example the flight simulator I work on. It needs to run at exactly 60Hz or pilots throw up. However, we are not CPU bound and the displays running at real-time do not have input interfaces.

  28. rezkiy says:


    You can hook in a kernel debugger, switch to offending program's process and do something to kill it.

  29. GregM says:

    Re: broken comments links

    Oops.  I was travelling that day and either didn't read in depth, or just forgot about it.

  30. Mr. T says:

    I pity the fool who sets real-time priority on a CPU-intensive application

  31. RobertWrayUK says:

    I wonder if perhaps Task Manager should simply remove the option to set something to real-time priority? That way it could be even more coddling. Try as I might, I can think of few reasons to expose this in the OS UI, IMO, any process that wants real-time priority should either be spawned that way, or set that itself for the duration of execution for which it requires real-time priority. Just my opinion though :)

  32. Steve says:

    I found a use for realtime which I use frequently. When I watch video playing from the computer on my TV I never want it to get starved for timeslices so I boost the process to realtime using Process Explorer. The only reason it's practical is because I'm on a multi-core machine so everything else gets the remaining cores and stays responsive.

    Maybe it's just a placebo effect, but I think it helps. Video plays nearly perfectly normally but I do this anyway to squeeze out a bit more consistency. I feel that if today's modern machines only use a fraction of their power even to play HD video, that video should never, ever skip a frame or otherwise be less-than-perfect.

  33. Kyle says:


    There *is* a way to kill such a program…reboot your computer and then uninstall the program.  If a program is knowingly changing its own priority to real-time, it should probably be avoided at all costs, because that's most likely indicative of other programming indiscretions.

  34. Anonymous Coward says:

    I've suspended programs quite often with Process Explorer, and at least on XP that doesn't lead to hangs or crashes. I assume Explorer & co send their messages asynchronously and with time-outs.

    Setting Explorer to a higher priority is useful. Very much so. But even Explorer can hang in a 100% cpu consumption state, and I don't know if setting it to real-time is wise. On the other hand, we're now living 2010 and I can't remember the last time this happened to me. But be aware that Explorer can load third-party components you've installed.

  35. Lars Kemmann says:

    On the other hand, setting the *explorer* process to real-time and your CPU-intensive process to high priority is a nice way to keep a responsive machine and still suppress those pesky background processes.

    As for industrial process control, what's to say using Windows for that is any less sane than using it for high-volume transaction processing systems and high-performance websites?  If your application does not *require* certain code segments to be processed in a fixed time box (safety-critical code), I don't see the problem.  Windows can preempt threads and even processes at a fair clip, certainly when compared to my 38k baud ModBus line.  Most safety systems in industrial applications are required to be hardware-supported anyways (at least in the US) to meet OSHA regulations.

  36. steveg says:

    Hah! Realtime operating systems… anyone ever use NonStopUX? It stopped all the bloody time.

  37. Dagger says:

    The problem with that alert in Task Manager is that it shows up on *every* priority change. If you change priorities on any regular basis, you will just learn to hit Yes automatically, at which point the warning just serves to annoy you. It would be far more effective if it was only displayed when switching to Realtime.

    I got sufficiently annoyed at having to hit Yes on that dialog each time that I NOPed out the function call to MsgBox in taskmgr.exe.

  38. James says:

    Indeed, over-alerting just manages to desensitize everyone to the alerts :/

    It's like those speed limit signs at roadworks that are up *even though there's no-one working at the time and the road is perfectly fine*. All they do is condition you to ignore them.

    Perhaps only showing the box when boosting the priority of a process would be a step forwards?

  39. Owen says:

    There is one process that always runs in realtime.  It is the System Idle Process.

    There is nothing wrong with having a process running in Realtime provided it is carefully written to be CPU friendly.  Lots of calls to Sleep at the appropriate time etc.

  40. Marquess says:

    “The problem with that alert in Task Manager is that it shows up on *every* priority change.”

    I get the feeling that you're doing it wrong. Priority changes are not an everyday operation, and even where they are, wouldn't a script be better? It's more resistant to accidentally choosing the wrong priority, for one thing.

  41. Miral says:

    I work on a program that's legitimately realtime (it's industrial control).  Processing isn't CPU-bound, so it's normally pretty safe.  On the rare occasions when there's a bug and it gets into a tight loop (usually only on dev PCs, since we stamp these out pretty hard before shipping) it's actually fairly amusing — the mouse pointer typically starts skipping or just totally locks up… but only for a few seconds, before our watchdog kicks in and automatically downgrades the process priority and shuts everything down.

    Even so, it'd be nice if Windows had some kind of "panic" button which *was* being monitored at realtime priority, to clean up after things like fullscreen DX games that lock up without releasing the screen (where sometimes you can't get out of them at all, and other times you can Alt-Tab out but you can't see what you're doing, because it's still in front of the desktop).

  42. ender says:

    This reminds me of the old MP3encoder (a simple GUI program that included the pirated version of Fraunhofer MP3 codec), which let you set it's encoding priority to real-time – when you did that, it popped up a large dialog box with 24pt text that said "This is not a bug. Just be patient." (or something very similar).

  43. Neil says:

    I wanted to adjust the priority of csrss.exe once. I was working in a terminal session, and the console copy of csrss got stuck in an infinite DPC loop (buggy disk driver, I think). The best I could do was to use Task Manager to set everything else in my session to High priority, but I soon gave in and rebooted the PC.

  44. Dana says:

    What would happen if one set an app to real-time priority but only assigned it three cpus on a quad core system.  Would the fourth core be able to process input so one could override if necessary?

  45. JamesNT says:

    It's going to take me the rest of the weekend to get over the fact that Mr. Chen had to actually explain this.  I am probably 0.000997% as smart as Mr. Chen and even I knew this.


  46. JasonB says:

    @JamesNT – I've come to realize that there is an unlimited amount of stupid that humans can attain.  Actions like this used to surprise me, but I kinda expect it now lol.

  47. Matteo Italia says:

    [ There is one process that always runs in realtime.  It is the System Idle Process. ]

    Nope, it has idle priority (or maybe even lower), otherwise the processor would just do HLT all the time (IIRC in more recent versions of Windows it doesn't just do HLT, you got the idea).

  48. JonK says:

    "anyone ever use NonStopUX? It stopped all the bloody time"

    Running Unix on NonStop hardware, you deserved what you got: it was a classic example of "just because you can, doesn't mean you should". Pretty much all the Tandem installations I ever had anything to do with were running Guardian because It Just Worked (and because it kept the contractors' rates nice and high ;-)).

  49. patbob says:

    Having realtime priority as an option for normal users is indeed a mistake.  For developers, however, it is occasionally useful.  The developer who sets a compute-bound task to realtime gets what they deserve — a reeducation via the school of hard knocks.

  50. Alexandre Grigoriev says:


    The reality is that 99% of users ARE 3-year-olds to be coddled. If you give them just a little bit of rope, they will hang themselves. Or will engage in auto-asphyxiation (like encrypting their files or overclocking beyond hardware specs), which one day kills all their data. Then they get pissed off and go buy a mac.

  51. David Walker says:

    @rezkiy: And just how, exactly, are you supposed to hook in a debugger if noting else, not even the keyboard interrupts, are getting any CPU time?  Anything you type or click will get deferred until the real-time program decides to give up.  

  52. Eric Cox says:

    Why not set have Task Manager set itself to real-time automatically if a user sets a process to real-time priority?   Then if it sees that process at 100% CPU for 10-15 seconds, it could display a warning.

    Surely, a real-time priority process that effectively disables the input system is an error in all cases, right?

  53. Joe Miramonti says:

    Take a look at "Process Lasso" at http://www.bitsum.com.

    This is a background app that continuosly monitors CPU usage and UI response time. It the system gets too unresponsive, it will automatically reduce the priority of the offending process(es), generally preventing the kind of Lock-ups you describe. It makes it 'safe' to use 'Real-time' and generally not worry about losing control.

  54. Matteo Italia says:

    Errata: you got the idea => *but* you got the idea

  55. mozzy says:

    What about the kill in power shell? Any advantages over Task manager?

  56. Mordachai says:

    God I hate programmers that want to dumb down the UI for everything and put blinders on their users & padding on all the walls & remove every sharp edge & generally think they're goddamn smarter than their end-users.  The hipocracy, the ego, the smugness of it all makes me sick!  You don't know how any particuolar user is going to use the software, and the !@#$!@#$ TaskManager is not for the Momma Joneses of the world in general anyway.  Your crappy software that locked up her machine would be the only reason she has for using the TaskManager, and if she stupidly overrides the priority of a process, she gets what she deserves.

    Next we should remove all the controls from ovens to avoid users who might accidentally choose the wrong temp and burn themselves or their roast – and remove wall outlets because *someone* is going to stuff a knife or fork in it, and then we should remove knives & forkes because *someone* is going to hurt themselves with them….

    Life has some !@#$!@ risks, and your users aren't 3-yr-olds to be coddled.  Let me shoot myself already, or your users may go postal on you and shoot the lot of you.

  57. Falcon says:

    (Sorry if this is a duplicate post – I don't think it worked the first time.)

    @mozzy: How would you launch Powershell (if not already running) and get it to execute the kill command in the first place if a real-time process is hogging the CPU(s)?

    Lovely car analogy time: How helpful do you think safety systems like ABS would be on a low-friction surface, like ice?

  58. Ben says:

    It seems pertinent to add that the Increase scheduling priority permission (SeIncreaseBasePriorityPrivilege) is granted only to Administrators by default. So, to all those users who complain about being unable to terminate applications that misuse the Realtime priority class: before complaining about the fact that the Windows scheduler does exactly what it's told to do by the system administrator or delegates thereof, it might be a good idea to ask yourselves why you thought it would be a good idea to run such programs under an administrative account or grant SeIncreaseBasePriorityPrivilege to non-administrative users in the first place.

  59. Ben says:

    @Henke37: it does. In the Task Manager menu, IDLE_PRIORITY_CLASS is referred to as "Low". This naming actually seems to make more sense than "Idle" from a user's perspective because, while IDLE_PRIORITY_CLASS provides a lower base priority than any other priority class, a thread will still only run at priority 1 if its thread priority class is set to THREAD_PRIORITY_IDLE, regardless of the priority class its parent process has. Only the system idle thread runs at "true" idle priority of 0.

  60. Owen says:

    @James: OK, so you think those speed limits are pointless when nobody is there?

    Someone else thought the same in the UK a few years back. The speed limit was set at 50mph; the normal for the road was 70mph. He proceeded at that speed, and for one reason or another crashed into the safety barrier.

    The speed limit was in place because the safety barrier hadn't yet been locked down onto its supports and tensioned. It jumped right off of its supports and into the roadway.

    He killed three motorcyclists. Three.

    You would think that the presence of roadworks would be an indicator that "gee, perhaps the road is not in its usual state". Evidently some people think otherwise.

  61. Lava Kafle says:

    In linux too we can set nice % values to our processes but people fear doing so.

  62. Joe says:

    Why is it that some processes' priorities cannot be changed?


  63. Thread shredder says:

    Why cant taskmanager set individual thread priorities?

  64. RobertWrayUK says:

    @Thread shredder – because Task Manager manages Tasks (processed) not threads, perhaps? :)

  65. RobertWrayUK says:

    @Thread shredder – because Task Manager manages Tasks (processes) not threads, perhaps? :)

  66. R. Bemrose says:

    @Thread shredder:

    I was under the impression that priorities were set per process, not per thread.

    Besides, Task Manager has no thread viewer.

  67. Thread shredder says:

    Sigh. Then, why isn't there a Thread Manager in windows. Which has a thread viewer.

  68. Charles says:

    @Owen: That seems to buttress James' argument.  If construction speed limit signs were not typically used when work was not being done, but signs *were* up in your situation, that would have encouraged the driver to slow down.  If construction speed limit signs *were* typically used even when no work was being done, clearly the driver wouldn't have… since he didn't.

Comments are closed.

Skip to main content