Case of the Full Screen App Hidden by The Taskbar

I’d been called in to assist support a 3rd party software vendor debug their own software, as several issues had been opened for weeks without hope of resolution.

One issue was that when program was running on Windows 7 the taskbar would keep taking over the application in full screen mode, causing a critical status bar in the application to become invisible.

They advised me their process to make their application full screen was to set the Windows taskbar to “Auto-Hide” and would “un-Auto-Hide” on application exit.

I pointed them the way of Raymond Chen’s blog on the issue

and gave them some working sample code:

 hWnd = CreateWindow(szWindowClass, szTitle, WS_CLIPCHILDREN | WS_CLIPSIBLINGS,

   MONITORINFO mi = { sizeof(mi) };

   SetWindowPos(hWnd, HWND_TOP,
       mi.rcMonitor.right – mi.rcMonitor.left,
       mi.rcMonitor.bottom –,

To create a full screen Window does not require any special tricks with the task bar.

You just need to create a Window that matches the screen resolution and not pass the style WS_OVERLAPPEDWINDOW.

The next day I was advised the change was made but it did not work, the taskbar was still visible. They requested we deploy a Group Policy setting to all users to force the taskbar to “Auto-Hide” that had their application…

I said before we do that…let’s run this EXE to confirm the fix has been applied correctly…

From reading we know able to find the reference for Window style values here at

WS_OVERLAPPEDWINDOW is actually several styles rolled into one:

WS_OVERLAPPED  (0x00000000)
WS_CAPTION     (0x00C00000)
WS_SYSMENU     (0x00080000)
WS_THICKFRAME  (0x00040000)
WS_MINIMIZEBOX (0x00020000)
WS_MAXIMIZEBOX (0x00010000)

Adding it all up we get:


Ok so this is value we are looking for. We start process from WinDbg and we set a breakpoint on CreateWindowExW

0:000> bp user32!CreateWindowExW
0:000> g
ModLoad: 75f30000 75f55000   C:\WINDOWS\SysWOW64\IMM32.DLL
ModLoad: 756e0000 757d7000   C:\WINDOWS\SysWOW64\MSCTF.dll
ModLoad: 75c60000 75d1e000   C:\WINDOWS\SysWOW64\msvcrt.dll
Breakpoint 0 hit
*** WARNING: Unable to verify checksum for FullScreen.exe
eax=00b50000 ebx=7eb49000 ecx=00000000 edx=0042f65c esi=0042f948 edi=0042fa60
eip=758b192b esp=0042f914 ebp=0042fa60 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
758b192b 8bff            mov     edi,edi

Now that we hit our breakpoint we want to get the Window Style parameter…because this is x86 process typically we’ll find parameters at an offset from esp…esp+4, esp+8, etc. In this case it is at esp+10h

0:000> dd esp+10h
0042f924  06cf0000 80000000 00000000 80000000
0042f934  00000000 00000000 00000000 00b50000
0042f944  00000000 0042fb70 0042fa70 7eb49000
0042f954  cccccccc cccccccc cccccccc cccccccc
0042f964  cccccccc cccccccc cccccccc cccccccc
0042f974  cccccccc cccccccc cccccccc cccccccc
0042f984  cccccccc cccccccc cccccccc cccccccc
0042f994  cccccccc cccccccc cccccccc cccccccc

OK so the Window style is 0x06cf0000. cf0000 looks familiar … that would be the WS_OVERLAPPEDWINDOW style that was not supposed to be there.

How about we change it…I opened the memory Window in WinDbg, set display format to Long Hex and just replaced the CF with 00


then hit ‘g’ to go in debugger.

Suddenly the program became full screen, with no need to hide the task bar…

So the suggested fix DID work. Just there was an issue in the implementation.

Working with developer he showed me the Visual Studio Project, I hit Ctrl+F and searched for WS_OVERLAPPEDWINDOW. About 20 lines before CreateWindow was called there was code like


Commented that line out, then Ctrl+F couldn’t find any other occurrences, problem solved.

Some additional points…

Using Rohitab API Monitor ( can you let you do the same without having to know the Window Styles, it offers very intuitive GUI to set breakpoint and modify input/return values of Windows function calls.

In this case I enable tracing of Windows Application UI Development


We can then run application from API monitor and search for CreateWindow, all the parameters are nicely decoded.



We can then set a breakpoint on create Window


Now when we hit the break point we can edit the DW_STYLE by just removing WS_OVERLAPPEDWINDOW then continuing


In addition it will provide Auto-Complete assistance if you are trying to add other values:


What if the developer couldn’t make the change?

You could open in a tool like IDA or OllyDbg and patch it…

In IDA I’d check import table then double click CreateWindowExW


Then jmp xref to operand


I then selected the CreateWindowExW call we needed. If there are many you will want to set a breakpoint to find the right one.


If we’re lucky the style will be right there (it may be harder to find in real life situations i.e. if it was set in a variable)


By clicking Patch program –> Change byte


Then changing CF to 00


And saving the patch program…


About chentiangemalc

specializes in end-user computing technologies. disclaimer 1) use at your own risk. test any solution in your environment. if you do not understand the impact/consequences of what you're doing please stop, and ask advice from somebody who does. 2) views are my own at the time of posting and do not necessarily represent my current view or the view of my employer and family members/relatives. 3) over the years Microsoft/Citrix/VMWare have given me a few free shirts, pens, paper notebooks/etc. despite these gifts i will try to remain unbiased.
This entry was posted in Debugging, Patching, WinDbg, Windows 7 and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s