RudeWindowFixer: fix Windows taskbar always-on-top issues

Brought to you by [Etienne Dechamps][] - [GitHub][]

If you are looking for executables, see the [GitHub releases page][].

Description

Ever felt frustrated by this?

RudeWindowFixer is a small program that gets rid of known "Windows taskbar not always on top" bugs.

Specifically, it works around proven bugs in the internal Windows taskbar code where, under very specific circumstances, Windows mistakenly believes that you are using a full screen application and hides the taskbar.

Usage

1. Download RudeWindowFixer.exe from the [GitHub releases page][].
2. Run RudeWindowFixer.exe.
   • Nothing will happen at first; this is normal. RudeWindowFixer is quietly running in the background. You can check in the Task Manager if you want to make sure.
3. That's it!
   • You will likely want to make RudeWindowFixer.exe [run on startup][] so that it persists across reboots.
4. Upvote this [Microsoft bug report][] to hopefully get Microsoft to prioritize fixing the underlying Windows bug, which is described in detail below.

Limitations

RudeWindowFixer does not claim to fix all possible taskbar always-on-top bugs. Sadly, reverse engineering efforts (see below) revealed that the relevant Windows code paths are somewhat brittle and might be prone to variations on these problems (e.g. different triggers or problematic window state) that RudeWindowFixer might not be able to detect and fix.

Also note that all investigation and testing was done on Windows 11 21H2 22000.434; other Windows versions might behave differently.

If you notice that RudeWindowFixer does not fix the problem for you, or at least not consistently, do feel free to [file an issue][] - it might be possible to instrument your system to gather detailed data about your problem, especially if you can reliably trigger it.

It's also theoretically possible that RudeWindowFixer could go overboard and make the taskbar show up in cases where it shouldn't - namely, on top of full screen applications (video players, games). This is unlikely to happen in practice. If you've seen it happen, do [file an issue][] and make sure to mention the name of the full screen application the taskbar is being shown on top of.

Specific known issues that RudeWindowFixer does NOT fix

• In [issue #3][issue3], it was discovered that Microsoft introduced a regression in Windows 11 build 22000.556 ([KB5011493][]). The bug is not present in build 22000.493. It appears that Microsoft has fixed it with the 22H2 update, around build 22621.1105.
  • One known reproducer for this bug is:
    1. Open the Start Menu.
    2. Switch to any window using a taskbar window button.
    3. Click anywhere at the exact moment the taskbar finishes its hiding animation (assuming it's set to autohide).
       • The timing is somewhat tight so this might require a few attempts.
  • This is likely the issue that this Feedback hub entry is about.
  • This bug seems is completely unrelated to the other issues RudeWindowFixer is fixing (see below) - in fact it doesn't seem to involve the Rude Window Manager at all.
• RudeWindowFixer currently does not address the [problem][issue4] of an app being treated as full screen if its dimensions exceed those of the monitor, leading the taskbar to drop behind it.

The problems in detail

Disclaimer: The following information was gathered through careful instrumentation of various window management facilities as well as [reverse engineering][] (disassembly) of the relevant Windows code, helped by [public Microsoft symbols][]. Reverse engineering is a difficult task where quick progress requires a fair amount of guesswork, so I wouldn't assume all the details below are exactly correct. This information applies to Windows 11 21H2 22000.434. The behaviour of other Windows versions might differ.

TL;DR

There are two known scenarios in which the taskbar can accidentally lose its "always on top" status. The following background information is required to understand both:

• The taskbar "always on top" window property is controlled by a piece of internal Windows code called the Rude Window Manager.
• The Rude Window Manager will only make the taskbar "always on top" on a given monitor if, among the windows located on that monitor, the top (foreground) window is not a full screen window.
• Some applications create transparent full screen windows that are essentially invisible, but still count as full screen windows as far as the Rude Window Manager is concerned.

The first failure mode is fairly simple: it is triggered by the presence of an always on top transparent full screen window. This essentially confuses the Rude Window Manager, resulting in the taskbar "always on top" property being dropped.

The second failure mode is more subtle and harder to trigger, but does not require the transparent full screen window to be always on top:

• A minimized window is not "located on" any monitor and is therefore never seen as the "top" window by the Rude Window Manager.
• When a minimized window is activated, a race condition can occur wherein the Rude Window Manager still sees the window as minimized and therefore does not treat it as the new "top" window.
• If the next window located on that monitor happens to be a (possibly transparent) full screen window, the Rude Window Manager will wrongly conclude that a full screen window is on top, and wrongly drop the taskbar "always on top" property.

The rest of this section go into each of these points in more detail.

Taskbar "always on top" behavior

During normal usage, the Windows taskbar is "always on top" of other windows. More specifically, the taskbar window (Shell_TrayWnd window class, part of explorer.exe) has the WS_EX_TOPMOST [extended window style][].

However, there is a case where Windows will drop the "always on top" property and will put the taskbar behind all other windows. This happens when Windows believes the user is interacting with a full screen application. This prevents the taskbar from obscuring the full screen application.

The Rude Window Manager

In internal Windows code, this full screen detection logic is implemented in an internal class called the rude window manager (twinui!CGlobalRudeWindowManager, also running in explorer.exe). Internally, the code uses the term rude monitor to refer to a monitor on which the top window is a full screen window. RudeWindowFixer is named after this terminology.

(If you are lucky enough to have access to the Windows source, you will find this code in shell\twinui\rudewindowmanager\lib\globalrudewindowmanager.cpp.)

Roughly, the rude window manager is implemented as follows:

1. Listen for specific window management events. Most of these events come from [shell hook messages][], which are generated by the kernel (win32k). For the purpose of this discussion, we are mostly interested in:
   • Windows entering or exiting full screen status. These are codified using undocumented wParam values 0x35 and 0x36, respectively. These appear to be generated based on window dimension changes.
   • Window activation events (HSHELL_WINDOWACTIVATED and HSHELL_RUDEAPPACTIVATED messages - note the differences between the two aren't clear, and the rude window manager treats them the same).
2. If one of these events occur, twinui!CGlobalRudeWindowManager::RecalculateRudeWindowState() will look at each monitor and determine if it should be considered "rude".
3. In the event a monitor "rudeness" changes, notifications are delivered to other components through CRudeWindowManager.
   • This notably includes the code in charge of the taskbar, through Explorer!CTray::OnRudeWindowStateChange(), which calls Taskbar!TrayUI::RudenessChanged(), which calls Taskbar!TrayUI::_ResetZorder(), which finally sets or unsets the "always on top" property of the taskbar window based on the new state.

Let's focus on step (2).

What makes a monitor "rude"?

RecalculateRudeWindowState() looks at the properties of visible windows to make this determination. For the purpose of this discussion, the most relevant property is the window dimensions (i.e. its spatial coordinates and size). These are determined by RudeWindowWin32Functions::GetWindowRectForFullscreenCheck() which internally uses [GetWindowRect()][].

(If the window has any of the WS_THICKFRAME or WS_CAPTION [style bits][window style], i.e. it has a border, then [GetClientRect()][] is used instead and the result is converted to screen coordinates using [MapWindowPoints()]. This subtlety doesn't matter much for the purposes of this discussion.)

A window is deemed to be located on a monitor if its dimensions overlap with that monitor.

Within the set of windows that are on a given monitor, the window that comes at the top of the [Z-order][] is defined as the top (foreground) window for that monitor.

The Rude Window Manager internally keeps track of a set of full screen windows. A window is added to that set upon receipt of a "full screen enter" (0x35) shell hook message. It is removed from the set upon receipt of a "full screen exit" (0x36) shell hook message.

If the top window on a given monitor is found in the set of full screen windows, then the monitor is considered rude.

Transparent full screen windows

Now, at this point, if you are not using any full screen applications (games, video players), you might wonder how this pertains to your case in any way.

Here's how: you might actually be staring at a full screen window right now. You just can't see it!

Indeed, it is possible for applications to set up windows that are:

• Transparent, using the [la