New App or Taskbar Opens Behind Other Windows

Updated: 2022-12-08

Intended Audience: Technically Oriented Windows Users

A very long-standing set of erratic behaviors has plagued some Windows users from Windows XP onward.  The issues are that, at sporadic times, the window of a newly invoked application doesn't open in front of other existing windows - making it appear as if it didn't open at all. 

A similar but different issue is when a taskbar (set to Auto-Hide mode) displays under all existing app windows when invoked, making it seem like it did not open.

After much research, we found each of these problems may be caused by a separate set of circumstances.  One seems to be related to a windows registry setting holding an “foreground display lock timeout” timeout value while others seem due to other apps that force themselves to the top (Z stack value) that interfere with Windows features that also need to be on top - like the aforementioned taskbar.

1. Apps Opening Under Existing Apps!

A little background:
When Windows opens an app that a user just requested, it starts flashing the app's icon on the taskbar for a defined "lockout" period before moving the app's window to the top.  The problem is that the default timeout period is 200,000 milliseconds.  That's 3m 20s - a very long time.  Since we never have to wait that long to see most programs open on top, there obviously is another piece of logic related to the app that forces Windows to move it to the top. Perhaps it is the completion of some type of program load event.  Several fellow bit-diddlers (TK Anthony’s 1960’s coinage) also report that the problem “might” be solved by changing a Windows registry setting labelled "ForegroundLockTimeout" from its enormously long default of 200000 (decimal) to 0.  That should effectively disable icon flashing and forcing the app to open on top.

The registry path\value that contains the timeout value is:
   HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout

The default is 200000 decimal milliseconds. If the Microsoft specs are correct, that translates to a whopping 200 seconds or 3m 20s.  Hard to believe but that’s the value.

So, to make this change you need to use the system registry editor, RegEdit.  In case it's not apparent, modifying the registry is easy and dangerous - a very bad combination.   So be extremely careful if you venture down this rabbit hole.  There is a RegEdit option to back up the registry which is highly recommended in case the change doesn’t work or causes problems.

Run RegEdit by typing its name in the run command box you get when you click the Windows start button.  Once opened, navigate the registry's key tree in the left panel just like you navigate the folder structure in Windows Explorer to locate "HKEY_Current_User\Control Panel\Desktop".  Once found, look at its items in the right panel then locate the “ForegroundLockTimeout" value.  Right-click that item and click Modify.  Then change the value from its default of decimal 200000 to just 0.  Be sure to make note of the original value so you can reset it if this method doesn't work for you.  In fact, you should ALWAYS "bookmark" any registry entry you fondle.  That makes it easy to find it again.  Close RegEdit and reboot to be sure the new value is used by Windows.  Repeat after me: Like most, this tweak is not guaranteed to work.  In fact, it only worked (initially) on 2 of our research workstations, one of which has since gone back to its evil ways.

The annotated screen capture above shows all the parts of RegEdit noted above.  The lock time out field is shown having right-clicked it and selecting modify. Although 0 is the same in Hexadecimal and Decimal, if you were to reset to the default of 200000 (decimal), you must select Decimal.

This tweak may not work for everyone, but many have reported success with it.  If it doesn't work, you should reset the key back to its previous value using the RegEdit to be tidy – reload the backup you made at the start of the procedure.   It cannot be overstated that if you don't have the problem, you should NOT be doing this.  If it ain't broke ... don't break it!

Program Interference:
The other similar issue that sometimes arises is that the taskbar is displayed under other app windows.  This can be very confusing if you have your taskbar set to auto-hide because, when you hover at the screen edge and existing app windows cover the whole screen, it appears as though the taskbar did not open when, in fact, it opened under the other windows. 

In our case, we run a simple-but-great screen utility, "ARuler for Windows", which acts like a ruler except that it measures screen pixels.  This is great for web development when you need to figure out what size object will fill a particular area.  Being an on-screen utility that measures things in other windows, it is designed to stay on top of all windows.

The problem is that this can confuse Windows and disallow things like the taskbar applet from asserting its own top "Z-order" window status.  While ARuler was running, our large 4-line taskbar with auto-hide enabled didn't seem to be working.  We then thought about ARuler and closed it.  Voila! The taskbar popped over all windows. Solved!

So, if your taskbar is hiding under app windows, you should start closing other apps that are running. One by one, check if the task bar resumes normal behavior after each app closure.  The last closure that fixed the problem is likely your culprit.

Hope that helps some of you because it definitely will NOT help all of you!