Windows 7 has an annoying bug that causes alt+tab to malfunction for many people. This bug, previously discussed on this blog in Alt+Tab Depth Inversion Bug, causes the grid of programs to be partially or completely hidden, making it much harder to switch between programs. IE 10 adds to the ways of triggering this bug, making it harder to avoid than ever before.

On the bright side, working around other people’s bugs is one of my hobbies, and IE 10’s triggering of this bug pushed me to create a fix.

So now this bug can be banished forever, without upgrading to Windows 8, and without waiting for a fix from Microsoft. See the end for a link to the fix.

Update, the update again, November 2013: I reported that IE 10 was triggering this bug to Microsoft but they decided not to fix IE 10. I thought they had fixed IE 11, so I upgraded. I didn’t see the bug for a couple of days, but it is still there. Sigh…

(see Other Causes of Alt+Tab Problems for more details)

New causes

The original bug was typically triggered by ipoint.exe or sidebar.exe. ipoint.exe is the Microsoft Intellipoint software, and sidebar.exe maintains the Windows gadgets, such as the clock. If either of these programs is running in Windows 7 then the bug may occur. The original ‘fix’ was to make sure that neither of these programs was running, and this worked quite well for me for four years.

And then, a few months ago, the bug came back – intermittently. It took a bit of observation and experimentation but eventually I found the cause. If you have IE 10 installed on Windows 7 and if you drag an Internet Explorer tab out of its window in order to create a new top-level IE window (tearing off a tab) then this bug may be triggered. I find this annoying because while it was no great sacrifice to never run ipoint.exe and sidebar.exe (I don’t know what ipoint.exe does and I have no interest in what sidebar.exe does), I do find tearing off tabs to be useful. So it was time to start investigating.

Research

There was a long-standing theory in the alt+tab conspiracy newsgroups that this bug was triggered by the presence of windows of a particular type. Therefore I started by writing some code that built a list of top-level windows using EnumWindows, then waited a few seconds, and then did it again. On the second pass the code printed all of the newly created windows. By running this program and then triggering the bug before the second pass I could see what new windows were created. There were quite a few, and the problem then became to sort out the interesting from the banal.

I focused on the window styles, obtained with a couple of calls to GetWindowLong:

LONG style = GetWindowLong(hwnd, GWL_STYLE);

LONG exStyle = GetWindowLong(hwnd, GWL_EXSTYLE);

A bit of experimentation and staring at hexadecimal representations of window styles made me suspect that always-on-top windows (WS_EX_TOPMOST) were relevant. These are windows that have a flag that says that they should be on top of all ‘normal’ windows.

However my system contained quite a few always-on-top windows, so that clearly wasn’t enough. More playing around led me to notice a few common attributes. In all situations where the bug appeared there was a new window that was:

Always-on-top (WS_EX_TOPMOST) Visible (WS_VISIBLE) Owned by ipoint.exe, sidebar.exe, or iexplore.exe Zero size and located at 0,0

With these factors identified I modified my code so that when it detected a window that fit these four attributes it would clear the WS_VISIBLE flag:

SetWindowLong(hwnd, GWL_STYLE, style & ~WS_VISIBLE);

And the bug went away! This simple fix – clearing a flag from these particular windows – fixes all known instances of this bug.

Celebration!

Changing the window styles of a window owned by another program is rude. It’s bad behavior. But, the idea of an always-on-top, visible, zero-sized window is illogical and, apparently, problematic, so I assuaged my conscience with something about the needs of the many users outweighing the needs of a few windows, and called it good.

The only remaining thing to do was to wrap this into a useful general purpose tool. I made the executive decision to fix all windows that had attributes 1, 2, and 4, regardless of what process they were owned by. I also decided to create a variation of the fixer tool that hangs around and runs the fix-it process every time the user presses tab.

The net effect is that if you run Cygnus Software’s Super Alt+Tab Fix-it Magic Ronco Latenight Infomercial Madness AltTabFixContinuous.exe then the bug should go away. Every time you type Alt+Tab (or, you know, just ‘tab’) any malformed windows are fixed before they can cause pain and suffering. Put this (did I mention it’s free!) program in your startup folder and this bug should (no warranty implied) go away.

You can also test it out with less of a commitment by running AltTabFixOnce.exe. This runs the fix-it process just once, and prints out the results so that you can see what it found and what it did.

Bad advice

In the answers.microsoft.com discussion there are many suggestions about how to deal with this bug and I’d like to respond to some of them here:

Turn off Aero Peek – this works, I guess, but turning off a feature hardly counts as fixing it

Check which version of Windows 7 you are running – this doesn’t matter, all versions are vulnerable

Update your display drivers – if this helps at all it is pure luck because the bug is not related to display drivers

The bug is in Windows Explorer. The Windows 7 version of Windows Explorer apparently doesn’t handle always-on-top windows very well.

In closing

The programs that create zero-sized always-on-top windows should stop doing that. It’s just weird. But really, explorer should be able to handle it. In Windows 8 explorer appears to have been fixed in order to avoid this bug.

I’m not thrilled about having written this program. On the upside, I’m pleased to have the skills needed to identify the factors that cause this bug, and the time to create a tool that will automatically remove those factors. On the downside, what a waste of time. The bug has been known for years and it probably affects millions of people (a large and increasing percentage of Windows 7 users who use Alt+Tab). I really wish Microsoft would fix these fit-and-finish bugs, rather than hoping that customers upgrade to Windows 8. As a Microsoft stockholder I really wish that they would make make their products a delight to use. Maybe now that IE 10 is making the bug show up more frequently they will feel obliged to fix it – or at least fix IE 10 so that it doesn’t trigger the bug.

I have passed all of this information along to my informal contacts at Microsoft.

In short, if you are currently experiencing this bug and you want to test my fix, run AltTabFixOnce.exe, look at the output, and see if it works. If the fix appears to work and you want to be rid of this scourge forever then copy AltTabFixContinuous to your startup folder. Both programs, and their source code, are available here. That is all.

Resources