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 http://blogs.msdn.com/b/oldnewthing/archive/2005/05/05/414910.aspx

and gave them some working sample code:

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

CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL,NULL , hInstance, NULL);

MONITORINFO mi = { sizeof(mi) };

GetMonitorInfo(MonitorFromWindow(hWnd,

MONITOR_DEFAULTTOPRIMARY), &mi);

SetWindowPos(hWnd, HWND_TOP,

mi.rcMonitor.left, mi.rcMonitor.top,

mi.rcMonitor.right – mi.rcMonitor.left,

mi.rcMonitor.bottom – mi.rcMonitor.top,

SWP_NOOWNERZORDER | SWP_FRAMECHANGED);

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 http://msdn.microsoft.com/en-us/library/windows/desktop/ms632679(v=vs.85).aspx we know able to find the reference for Window style values here at http://msdn.microsoft.com/en-us/library/windows/desktop/ms632600(v=vs.85).aspx

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:

0x00CF0000

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

USER32!CreateWindowExW:

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

Set_Style(WS_OVERLAPPEDWINDOW);

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

Some additional points…

Using Rohitab API Monitor (http://www.rohitab.com/apimonitor) 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…