A very long-standing set of erratic behaviors has plagued some Windows users from XP through Windows 10. 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. Secondly, a seemingly similar but different issue is that the task-bar displays under all existing app windows, making it seem like the task-bar is not present or did not open (when in auto-hide mode).
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 a display timeout value while the other seems due to other apps that force themselves to the top, interfering with Windows features that also need to be on top - like the task bar.
1. Apps Opening Under Existing Apps!
A little background: When Windows opens an app that a user just requested, Windows starts flashing the app's icon on the task bar for a defined number of times and waits 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 kind of program load event.
Several fellow bit diddlers report the problem of apps opening under other apps might be solved by changing a setting called the "lock timeout" from its default of 200000 (decimal) to 0. This overrides the timeout, disabling the icon flashing and forcing the app window to open on top.
The registry key path that contains the timeout value is:
The value is in a data item in lowest key (Desktop) named, ForegroundLockTimeout.
The default is 200000 (expressed as decimal milliseconds). If the Microsoft specs are correct, that translates to a whopping 200 seconds which is 3m 20s.
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 bad combination. So be extremely careful.
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. Find "ForegroundLockTimeout". 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 my workstations, one of which has gone back to its evil ways.
The annotated screen capture below 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. Needless to say, if you don't have the problem, you should NOT be doing this. If it ain't broke ... don't break it!
The other similar issue that sometimes arises is that the task-bar is displayed under other app windows. This can be very confusing if you have your task-bar 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 task-bar did not open when, in fact, it opened under the other windows.
In our case, we run a great screen utility called "ARuler for Windows" which acts like a normal ruler except that it measures pixels on the screen. 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 needs to stay on top of all windows.
The problem is that this can confuse Windows and disallow things like the task-bar applet from asserting its own top window status. While ARuler was running, our large, 4-line task-bar with auto-hide enabled didn't seem to be working. We eventually thought of ARuler and closed it. Voila! The task-bar popped up and over all other windows. Solved.
So, if your task-bar 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 one closed is your culprit.
Hope that helps some of you because it definitely will NOT help all of you!