I've noticed that when Excel 2007 (and probably earlier versions) has the window focus, Excel runs at full speed which means that files open fast and long-running VBA macros execute quickly.

If the Excel window loses the focus, the thread priority of Excel seems to drop dramatically and large files that were opening when you moved the focus open sluggishly, and complex VBA macros take a long time to complete.

Is there any way to keep the Excel priority high regardless of whether it is focused or not?

I know I could boost the thread priority artificially through Task Manager but I'm not sure what knock-on effects this might have for my spreadsheets, or OS.

My system is a fast Dual Core with 4Gb RAM and is running Vista 64.


My problem is not simply about raising the priority of the Excel process through Task Manager because this only affects Excel when it has the window focus.

The point is what happens when Excel loses the window focus.

From using Excel extensively, it appears that, by design, it deliberately lowers its own process priority when the Excel window does not have focus.

Setting a higher priority for the Excel process does not stop this from happening - it only gives Excel a higher process priority when it has the focus but it still dips dramatically when it loses focus.

In normal Excel usage (probably 99% of everyone using it), you wouldn't notice this effect but with a massive spreadsheet (around 2000 worksheets, I think) and complex VBA Macros that take a few minutes to execute, the effect is very noticeable.

Ideally, I need it to keep the same thread priority regardless of whether the Excel window is focused.

Up to now, I have just been sitting back from the computer for a few minutes during processing so that I don't accidentally click off the Excel window when it is crunching away but I was just hoping there was a better solution...perhaps a registry hack of some kind?


I have only ever found one other mention of this issue on the net at this link

This is the relevant quote...

However, if I make the Excel 2000 window visible to the user and also keep the window in focus, the macros execute with their expected speed. Again, the window must have focus or the macro slows to a crawl again.

  • Good question. This has also proven to be an irritating 'feature' for me, and still no real solution...
    – Noldorin
    Aug 16, 2010 at 9:44
  • Thread priority by itself has no effect on performance unless there are several threads competing for a resource - in which case, the higher priority gets first slice of the pie. I haven't used Excel for a long time, but it may be throttling itself when in the background, or you may be falling victim to Windows' somewhat retarded swapping mechanics. Aug 11, 2014 at 11:35
  • This happens with all Office 2007 programs when running long VBA scripts. I once wrote a script that took excel data and placed them into Word forms. If I hid the Word program, the excution dropped to a crawl. If I allowed the program to be shown, the script was ~10x faster.
    – wbeard52
    Oct 2, 2015 at 3:26

7 Answers 7


Windows non-server editions, by default, provide a priority boost to the foreground process. When you push Excel to the background, it loses out on the boost it previously had being in the foreground; some other program instead gains the priority boost.

You can change a setting so that programs no longer get this boost. Note: This won't affect just Excel, but any program that would have otherwise qualified for a boost.

Here's how to tweak the setting in Windows XP:

  1. Right-click My Computer.
  2. Choose Properties.
  3. Click the Advanced tab.
  4. In the Performance panel, click the Settings button.
  5. Click the Advanced tab. The first panel is Processor Scheduling:

    Processor Scheduling panel

  6. Change it from the default of "Programs" to "Background services" and it should cause Excel to behave closer to the way you want when it's in the background.

  • Note that doing this will make foreground programs often seem sluggish when background applications and services suddenly decide they want to do something. Aug 11, 2014 at 11:36
  • "Windows non-server editions, by default, provide a priority boost to the foreground process." No, they don't. (They did prior to Windows NT 4, but that is a very long time ago.) What they do is make the timeslice for the foreground process 3x as long as the timeslice for other processes (90 ms vs 30). There is also a +2 priority boost that is applied to any thread in a foreground process when it resolves a wait. The problem with the solution offered here is that it causes the timeslice to be even longer, 180 ms. This can dramatically hurt the responsiveness of UI-intensive apps. Jan 8, 2018 at 22:44

I don't think there is a problem with changing Excel process priority to Above Normal in your case. It should not be a problem.

Don't make it highest, where it will compete with system processes.
Don't suspend it, or you can have other things suspended on it!

If you use Mark Russinovich's Process Explorer
to look at the priorities of processes running on your system.
It shows the following priority values and their association.

24 Realtime
13 High         : procexp.exe itself is here, with winlogon, csrss
11              : smss is actually at 11
10 Above Normal :
 9              : lsass, services.exe are here
 8 Normal       : Most things are here
 6 Below Normal
 4 Idle

You could use process explorer and try some re-prioritization for Excel.
Move it above 8, but do not go beyond 12
Above Normal at 10 should do, I expect.

Along the same lines, if you think some process is taking up too much processor time while not in focus, you could lower its priority right up to Idle.
I usually use this technique for that.

  • But the priority will still drop when Excel doesn't have the focus, won't it?...just to a slightly higher priority level than before, I guess. Do you know how to keep the thread priority consistent regardless of the window focus?
    – Joe Schmoe
    Jul 17, 2009 at 7:54
  • I am looking for this detail, but my understanding is that the window in focus will usually be at Normal priority (by default) and once you move Excel to Above Normal priority, it should be running at a higher priority than the focused window. But, at lower priority then the system processes -- which is where you want it to be.
    – nik
    Jul 17, 2009 at 8:35
  • Unless I am misunderstanding what you are saying, your implication is that you can raise the priority of the Excel process and it will stay at that priority all the time. But from using Excel extensively, I can say with some confidence that it doesn't do that. It appears, BY DESIGN, that it lowers its own priority when the Excel window does not have focus. Setting a higher priority for the Excel process does not stop this from happening - it only gives Excel a higher process priority when it has the focus but it still dips dramatically when it loses focus. Have just run a test to confirm this.
    – Joe Schmoe
    Jul 17, 2009 at 10:14
  • I am surprised. Though, I have not used this technique to raise process priorities (only to lower them).
    – nik
    Jul 17, 2009 at 10:37
  • I have added some more information to the question to highlight this deliberate process-lowering that seems to be going on. Ideally, there would be some kind of registry hack that would stop this happening.
    – Joe Schmoe
    Jul 17, 2009 at 10:40

There's a couple of different things to consider here: When you change the priority of a process, that base priority is inherited by all it's threads, and other processes it starts. The current priority is made up from the base priority and a number of factors which determine whether it should be boosted or not - being in the foreground does not itself necessarily boost priority, but things like coming out of a wait state or doing some IO can give a short temporary boost.

I would suggest that running your Excel process with a high priority when working on these very intensive workbooks might make sense, and I would say a second shortcut called "High priority Excel" might be a good way to do this. First make a one line batch file which runs the start command with appropriate switches, eg:

start "high priority excel" /max /high "C:\Program Files\Microsoft Office\Office12\EXCEL.EXE"

(on a 64 bit version of Windows this would be start "high priority excel" /max /high "C:\Program Files (x86)\Microsoft Office\Office12\EXCEL.EXE" unless you are also running a 64 bit version of Office, which is only available for 2010 onwards start "high priority excel" /max /high "C:\Program Files\Microsoft Office\Office14\EXCEL.EXE") Note that the title for the window can be anything you like, but is not optional.

Now save this as eg HiperExcel.cmd somewhere handy - maybe the office folder, or a c:\scripts folder or somesuch, or your home folder so this can roam form machine to machine. Create a new shortcut which points to this file, make the start folder the folder where the file is kept. Choose an icon for the file - browse to the Excel.exe executable then choose something other than the usual Excel icon for clarity.

Click your new shortcut and it will invoke Excel running as a high priority process, with a base priority of 13 and when running it will probably get the maximum priority for non-real-time processes of 15. Even if something else gets a boost, it should not get higher priority. Note that the foreground process does NOT get a boost of priority just for being in the foreground (not since NT4.0). So what is going on?

Re-cap what we know so far: Processes get to take turns according to priority, but not to the absolute exclusion of lower-priority processes (well, threads really, but lets keep things to processes for ease of discussion). What happens when a process gets its "turn"? It gets to run for a unit of time called a quantum. How long is a quantum? It depends...

This is where the foreground process gets to use more of the resources - when it does get a turn, that turn can last three times longer than the turns of the background processes. So it might not get a go very often (depending on priority) but when it does, it hogs it for longer.

You can choose to use short or long quantums (default is short on workstation OS, long on servers), and to have the foreground process boosted or not (variable for w/s, fixed for servers by default), and if boosted, by how much (effectively up to 3 times). Now, the tricksy part of this is that if you choose to change the multiplier, you end up with everything having very short values for quantum, whereas if you disable foreground boosting everything gets a longer but equal amount. If you disable it of course, background windows services get the same quantum as your user applications, which might not be ideal. You need to set the value in the registry at: HKLM\System\CurrentControlSet\Control\PriorityControl\Win32PrioritySeparation, using a bit mask. To make things easier, the most likely values you would want are:

2 = default value, means use defaults with maximum boost. defaults on workstation O/S are short and variable. 8 = fixed, short quantum (foreground and background are equal) 40 (decimal, x28 hex) = fixed and long (this is the same as server defaults) 36 (decimal, x24 hex) = short, variable but minimal boosting for foreground process. I think this is the one which will probably give you the most benefit to reduce the amount that other apps compete, but allow Excel to get more resource when in the foreground (as long as you also raise its priority).

Try it and see, I hope this helps - your mileage may vary of course.

Aside: Lots of other applications or processes do not have the CPU as their bottleneck - your examples of Outlook synching and IE browsing probably have the network, and possibly for Outlook some disk IO as more important factors in their speed, so whether they get a foreground boost or not, the impact in visible performance is probably below what you can see by simple observation.

  • 1
    BasicallyMoney.com shows how to alter the setting for the quantum rules through the XP gui, but the registry key fix is still the same for OS from NT4 through to Windows 7 so is more general. Setting "Background services" is the same as setting 'fixed'. And note, this is not a priority boost, it alters the length of the 'timeslice' each process gets. Priority is an independent property, and not boosted by being in the foreground.
    – AdamV
    Oct 30, 2009 at 14:43

There's no problem with increasing a process's priority to "above normal" or "high", just don't set it to "realtime". Can't help you with Excel specifically sorry.


It is possible that the priority manipulation is being done not by Excel, but by Windows itself. Windows has a mechanism where the priority of processes with windows in the foreground is boosted; so, when Excel loses focus, its priority goes back to normal (which is slightly lower).

The only page on MSDN I could find about this with a quick search is Priority Boosts:

When a process that uses NORMAL_PRIORITY_CLASS is brought to the foreground, the scheduler boosts the priority class of the process associated with the foreground window, so that it is greater than or equal to the priority class of any background processes. The priority class returns to its original setting when the process is no longer in the foreground.

From what I have heard, there are ways to disable that priority boost.

  • I'm not sure about this. If it was that then I would expect other applications to slow noticeably when they were not focused. But I don't notice any slowdown in, say, Outlook if it is syncing emails when the focus is on the web browser, or even a slowdown in my browser loading a page if I am focused on the Excel window.
    – Joe Schmoe
    Jul 17, 2009 at 16:00
  • 1
    And number crunchers like BOINC tasks run at a low priority in the background yet take full advantage of the available spare CPU capacity. Oct 30, 2009 at 13:34
  • That MSDN page is describing old, even ancient, behavior. Jan 8, 2018 at 22:47

Just try this, it worked for me.

Not very nice way, but it actually just doubled my calculation speed! Amazing! (but I will check the results, not sure about them...)

Your userform must be at center of the screen in 1024*768. It just send by software a right click on the userform.

Full calculation, but do not use your computer while it calculates (launch other programs, windows..).

Just try and tell me how it worked for you!

'In General
Private Declare Function SetCursorPos Lib "user32" (ByVal x As Long, ByVal Y As Long) As Long
Private Declare Sub mouse_event Lib "user32" (ByVal dwFlags As Long, ByVal dx As Long, ByVal dy As Long, ByVal cButtons As Long, ByVal dwExtraInfo As Long)
Private Const MOUSEEVENTF_RIGHTUP As Long = &H10

Private Sub Optimizer()
    'activate the window
    'AppActivate "Inbox - Microsoft Outlook"
    'move the cursor where you need it, I guessed at 200,200
    'Warning here : check the center coordinates of your userform!
    SetCursorPos 512, 374
    'send a down event
    mouse_event MOUSEEVENTF_RIGHTDOWN, 0&, 0&, 0&, 0&
    'and an up
    mouse_event MOUSEEVENTF_RIGHTUP, 0&, 0&, 0&, 0&
End Sub

'Inside your code
Call Optimiser`

After a long night of full speed calculation, and after check, the results this morning were... totally wrong.

So I think its just a bug, the calculations are not properly done.

Clicking on the userform in calculation just accelerate the process speed, but not fully recalculate the sheet beyond. I precise I was in Real Time with prio.

Another nice thing is to tweak the process task with prio_x64_199_2367.exe, http://softziz.com/2010/11/prio-64-bit-1-9-9/

This save your process priority defined with CTRL ALT DEL, inside task manager, for future uses.

Kind Regards,


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .