I have a question regarding win-7 schedule and process priority.

The scenario is: I have a process running, initially in priority "Normal"

I find this process to be often reduced to Background (Low I/O). I end up with setting the priority back to "Normal" or "Above Normal", however in few minutes it will be reduced again.

I have tried setting the priority using standard windows task manager or procexp (I guess there should be no difference).

So, the question is: Is process priority recalculated to cover its I/O usage? The process in this situation is Visual Studio 2015, which uses quite a lot HDD, which can be a bottleneck here.

4 Answers 4


As far as I know, Windows operating systems will not change a process' priority unless told to do so. However, this does not mean a priority cannot be changed by the running program. There is a .NET property called Process.PriorityClass which can change the priority. Perhaps, VS is determining it can reduce its CPU usage to allow other threads more CPU time?

  • Thank you for this answer. Yep, is known that changing priority is programmatically possible, but this is does not solve initial problem. Also, yep, is could be related to VS, but, same configuration on another machine works well. So, I cant give you a bounty because you answer doesn't solve initial problem.
    – tym32167
    Oct 10, 2016 at 9:39

The scheduler of windows will most likely indirectly consider I/O usage (because it will schedule processes less often that return quickly like processes waiting for I/O). However, process priority should be a number set by the user [or other programs (including the process itself)] and influence the scheduler further. ... Enough of the wild guessing of mine.

These answers sugegst using Prio to save a process's priority (enforced by a background service) it might also help in your case.


To my knowledge, Windows does not automatically adjust process priority.

Changing a process's priority sets the "base priority" of all of the threads in the process, and of all threads subsequently created within the process. (See my answer here for a description of this relationship.)

Windows does adjust the priorities of threads based on their recent activity. For example, after a completion of an I/O, a thread's priority will be boosted above its base by an amount determined by the function device driver for the device. Upon every timeslice end, if a thread is running at a boosted priority, its priority will "decay" by 1 until it falls down to the base priority. It does not decay below the base.

This is documented in the chapter on thread scheduling in Windows Internals by Solomon, Russinovich, Ionescu, et al.

But this does not match your reported scenario, because 1) the result of all this boost and decay of thread priority simply does not show up in Task Manager (since Task Manager reports process priority class, not thread priorities); and 2: this mechanism never decays a thread's priority below its base priority. The base is what is set when you change the process priority.

This may be something that Visual Studio (deveng.exe) is doing to itself. Do you see this happening to any other process?

This could be investigated with Windows Performance Toolkit.


Having process priority adjusted in the situation you describe is not unusual.

To simplify things, let's think of the situation this way: higher priority generally means that the process "wakes up" more often than a lower priority process (to perform some work). Considering that your process is doing a lot of (random) disk IO, keeping it at high priority means that it would "wake up" often only to find itself waiting for the disk to return data. Since process switch can be an expensive/time consuming operation, lowering the priority of a disk-intensive process leads to better processor utilization. In other words, by adjusting process priority, the processor can spend more time doing work rather than spending that time switching between processes.

I think it's more likely that VS or the process itself is doing the re-prioritizing.

  • This answer does not solve initial problem, but at least explains, why it happens. Thank you.
    – tym32167
    Oct 11, 2016 at 14:26
  • Sorry, but this answer is contrary to fact in several ways. 1) Threads receive boosted, not lowered, priority after completing a disk IO, the rationale being that letting an I/O bound thread get into the CPU and start its next IO can avoid dead time on the device. 2) Higher priority doesn't mean you "wake up more often"! It means that when you "wake up" (that is, go from Wait to Ready state) you get to use the CPU before lower-priority Ready threads do. 3) While a thread is blocked on a disk IO (or any other IO) it doesn't "wake up" at all! That's what "blocked on disk IO" means. Dec 29, 2018 at 23:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.