Repository files navigation

Brought to you byEtienne Dechamps -GitHub

WindowInvestigator is a small set of highly specialized tools that can be usedto investigate Windows window manager issues. It was developed with the goal ofinvestigating the behaviour of a piece of internal Windows code called the RudeWindow Manager; seeRudeWindowFixer for more background. However it mightalso be useful in other scenarios.

For example, WindowInvestigator is what made it possible to come up withanalyses like the following:

Some of the internal Windows shell window management code, including Rude WindowManager code, uses an internal class calledWindowManagementLogging to logvarious events and the results of computations. I found these logs to beextremely relevant to my investigation.

WindowManagementLogging acts as anEvent Tracing for Windows (ETW)provider. Through binary reverse engineering, it has been determined that theprovider GUID isF84AA759-31D3-59BF-2C89-3748CF17FD7E.

You can use this GUID in event consumers to receive the log. For example youcan enter the GUID directly inTraceView for real time logging, or you canload the includedWindowManagementLogging.wprprecording profile intotheWindows Performance Recorder (WPR) for a more thorough analysis. TheProvider Name will appear asMicrosoft-Windows-Desktop-Shell-Windowing.

Some of the internal Windows taskbar state management code uses theShell Corelogging provider to log various events which can be useful for correlation.

This is anEvent Tracing for Windows (ETW) provider whose GUID is30336ED4-E327-447C-9DE0-51B652C86108 (credit goes to Geoff Chappell).

You can use this GUID in event consumers to receive the log. For example youcan enter the GUID directly inTraceView for real time logging, or you canload the includedShellCore.wprprecording profile into theWindows Performance Recorder (WPR) for a more thorough analysis. TheProvider Name will appear asMicrosoft-Windows-Shell-Core.

WindowMonitor is a command line tool that is aimed at investigating windowstates and how they change over time. If called without any command linearguments, it will:

• Dump an initial list of allvisible windows to the standard output, alongwith the values of various window properties.
  • This is to provide the initial reference starting point.
  • That list is also logged through the tracing provider (see below). Every5 seconds, it is logged through the tracing provider again to provideregular reference points.
• Create amessage-only window that:
  • Registers and listens toshell hook messages.
    • The message identifier for shell hook messages is typically0xC029, butthat is not necessarily always the case. Look for theStarted traceevent to determine the actual message identifier.
  • Registers and listens toappbar messages.
    • WindowMonitor usesWM_USER (0x400) as the identifier for appbarmessages.
    • An appbar message to watch out for isABN_FULLSCREENAPP whichis sent as a consequence of the monitor rudeness state changing.
  • Sends aWM_TIMER (0x113) message to itself every 16 milliseconds.
• Every time any message is received on the aforementioned window, WindowMonitorlogs it through anEvent Tracing for Windows (ETW) provider.
  • The provider GUID is500D9509-6850-440C-AD11-6EA625EC91BC. You can enterthat GUID directly inTraceView for real time logging, or you can loadthe includedWindowInvestigator.wprprecording profile into theWindows Performance Recorder (WPR) for a more thorough analysis. TheProvider Name will appear asWindowInvestigator.
• In addition to logging the message itself, every time a message is received,WindowMonitor will go through every visible window and log any changes thatmay have occurred to any of the watched window properties (e.g. styles,position) since the last message.
  • This also includes changes to the Z-order, which are determined by watchingfor changes in the order in which windows are returned fromEnumWindows().

WindowMonitor can also be called with a specific window handle as a command lineargument (e.g.WindowMonitor.exe 0x4242). In that case, WindowMonitor will notlisten for messages; instead, it will check the state of that window every 2milliseconds and will log any changes. Note that Z-order changes are notreported in this mode. This single-window mode is useful when you need moreprecise timing information.

Note: it is recommended to run WindowMonitor as Administrator; this will allowit to set the Real-Timeprocess priority class to achieve the most precisetiming.

Note: WindowMonitor might not run on some Windows versions because it retrievesa couple of undocumented window properties through reverse-engineereduser32.dll Windows API entry points that might not exist in all versions. Youmight need to adjust the code to remove calls to these APIs.

This extremely simple tool simply displays a standard window that has theparticularity of injecting a customizable delay in the processing ofWM_WINDOWPOSCHANGING messages. This is useful to simulate applicationsthat are slow to process these messages (e.g. Firefox), and to force latent raceconditions to the surface.

The delay is specified in milliseconds as a command line argument. For example,DelayedPosWindow.exe 100 will make everyWM_WINDOWPOSCHANGING messagetake ~100 ms to process.

Similar to WindowMonitor, DelayedWindowPos will trace every window messagereceived, as well as details ofWM_WINDOWPOSCHANGING messages. The traceprovider details are the same as WindowMonitor.

This trivial command line tool simply displays a window that has theWS_EX_LAYERED andWS_EX_TRANSPARENTextended window styles. It alsomakes the window full screen by setting its dimensions to be the same as thescreen. This emulates a "sneaky" full screen window such as the GeForceExperience overlay window.

If you pass the"topmost" command line parameter, the full screen window willalso have theWS_EX_TOPMOST style, i.e. it will be "always on top".

Note that this tool has only been tested in a single-monitor setup. Thedimensions of the window might be incorrect on a multi-monitor setup.

This command line toolbroadcasts arbitraryshell hook messages. Themain purpose is to deliver a message to the Rude Window Manager. The window thatthe Rude Window Manager listens on is a bit hard to find - it's one of severalWorkerW windows under the desktop window ofexplorer.exe. Broadcasting is aquick and dirty way of getting the message across without having to find thewindow.

The program takes two hexadecimal arguments which are the values to send aswParam andlParam, in this order.

Here's a few examples of command line parameters:

• 0x16 0x0 sendsHSHELL_MONITORCHANGED with a null window, which simplycompels the Rude Window Manager to recalculate its state.
• 0x35 0x4242 will compel the Rude Window Manager to add window handle0x4242 to its set of full screen windows.
• 0x36 0x4242 will compel the Rude Window Manager to remove window handle0x4242 to its set of full screen windows.

• GuiPropView is a nice tool for looking at window properties in general.
• Spy++ is useful to monitor the messages that a given window is receiving.
  • Make sure to use the 64-bit version when monitoring a 64-bit process,otherwise no messages will be shown.
• For reverse engineering Windows binaries, I usedGhidra.
  • I found it to be quite effective, although the relevant code is litteredwith C++ virtual function calls which are sadlyverypainful to analyse in Ghidra.
  • Whatever software you use, do make sure to use thepublic Microsoftsymbols as these will make your life much easier!

WindowInvestigator is designed to be built using CMake within the MicrosoftVisual C++ 2019 toolchain native CMake support.

There are no dependencies besides the Windows SDK.