Skip to main content

Windows 7 auto-hide task bar is broken

Windows 7 auto-hide task bar is broken. In fact, the 'auto-hide' option for the task bar has been broken since some time prior to Windows XP SP3.

There is, as of this writing, no proper fix to this problem and as near as I can tell, Microsoft has not even acknowledged that it is an issue.

In recent years, software manufacturers have taken to ducking some of the most irritating bugs by saying that they are 'by design'. This is not an explanation and it does not in any way absolve them of correcting the issue. SideRant: I have more confidence in my opinion of this matter than I do of theirs. I have been writing software for decades and have worked with every version of Windows since version 2 (before 3, 3.1, 95, 98, ME, 2000, XP, 2003, and 7). I also work with Linux and have worked with various other Unices over the years. I have worked with a fair number of software vendors (including Microsoft) on their projects (that is, they hired me). I have also worked with just about every type of business in the fortune 100. I have written hundreds of thousands of lines of code personally in most major languages (notable exception LISP) and all major types of languages (including LISP-variants). My experience spans from hand-entering op-codes, through development of device drivers in assembly code, windowing subsystems, systems programming, low and high-level libraries of all types, utilities, parsers, generators, high-level application code, communications, etc. I have worked alone and in teams following a variety of development regimes.

By my way of thinking, the task-bar in Windows 7 is plainly broken and I have no hesitation about it. It is buggy. It does not work properly. This issue is at minimum a bug. It is more likely even worse. It appears to be a design flaw. In fact, it appears to be one of the class of very nasty design flaws that stem from a broken design philosophy. In this case, the philosophical point of view (with which I strongly disagree) is that any userland process can insist that a user interacts with it and can suspend normal operation of the system until they do so. Looking at it from another point of view, it gives user input too low a priority -- essentially below that of any other executing code on the system.

In the case of the taskbar bug, it means that when programs enter a certain state, they can force you to stop your work and start an investigation to determine which program has which need and then attend to it. In the event that you cannot determine this, your option is to permanently unhide the taskbar (uncheck auto-hide) or to reboot. In some instances, unhiding the taskbar means that you can no longer use the system because you lose vital screen real estate necessary to (say) click the 'Apply' button on the very dialog necessary to change the auto-hide option. That is, you can get the system into a state where the only option is to reboot, just because one of the weaker programmers to provide software to your system wrote a program that put up the wrong type of message.

There is no reasonable work-around for this problem. The only thing likely to help this problem if you have it bad is a program that periodically forces the taskbar to hide. Such programs apparently exist, but they are a poor workaround.

If you look far and wide you will see the usual variations of helpful stuff like:

"it rarely (or never) happens to me"
"I tried [insert kludgy partial workaround] and it worked for me]"
"Just reboot"

One of the more irritating idioms that appears in Microsoft forums goes like this:

You: "How do I fix the taskbar so it will always auto-hide"
Them: "I don't understand why you want that."


Them: "You shouldn't want that."


Them: "The reason why it is irretrievably and senselessly broken beyond all recovery and will always interfere with the proper operation of the system is [insert unconvincing reason here]"

Normally, I like to give a workaround, but in this case, there is none and it is uncertain how it can be fixed properly by anyone other than Microsoft. The problem is that there is a function in the Operating System (Windows) that might as well be labeled 'risk breaking the system on a whim' that gets called willy nilly by any program that pleases. In fact, it may be that the effect is buried in a different call that might as well be labeled 'do not ever allow the system to break'. A well-meaning but naive programmer with a less than effective testing regime might be attempting to make their program behave well by calling the 'do not ever allow the system to break' function and ironically breaking the system.

I will update this in the comments if/when I come up with a reasonably satisfying solution. However, since this problem has existed for many years, I am not holding my breath.


kotokel said…
Yes, it is quite irritating. I hope that Microsoft will deign to our plea.
JWuethrich said…
I know this is old but i wanted to thank you for voicing this opinion. The only thing that disturbs me as much as this bug and others like it is the abundance of people ready to declare it is not a bug.
DeepNorth said…
Wow. I wrote this more than eight years ago now and the problem persists. Actually, over these past eight years the usability of Windows has gone down with each release. Windows 10 on a couple of my machines has rendered them all but unusable.

Popular posts from this blog

The system cannot execute the specified program

It always annoys me no end when I get messages like the following: "The system cannot execute the specified program." I got the above error from Windows XP when I tried to execute a program I use all the time. The message is hugely aggravating because it says the obvious without giving any actionable information. If you have such a problem and you are executing from a deep directory structure that may be your problem. It was in my case. Looking on the web with that phrase brought up a bunch of arcane stuff that did not apply to me. It mostly brought up long threads (as these things tend to do) which follow this pattern: 'Q' is the guy with the problem asking for help 'A' can be any number of people who jump in to 'help'. Q: I got this error "The system cannot execute the specified program." when I tried to ... [long list of things tried] A: What program were you running, what operating system, where is the program? What type of

Coming Soon: General Artificial Intelligence

The closer you get to experts who understand the nuts and bolts and history of AI, the more you find them saying that what we have is not nearly General Artificial Intelligence (GAI), and that GAI seems far away. I think we already have the roots in place with Neural Networks (NN), Deep Learning (DL), Machine Learning (ML), and primitive domain limited Artificial Intelligence (AI). Things like computer vision, voice recognition, and language translation are already in production. These are tough problems, but in some ways, machines are already better than humans are. I expect GAI to be an emergent property as systems mature, join, and augment one another. I was around during the 70s AI winter, and was involved in the 80s AI winter as one of the naysayers. I built a demonstration system with a Sperry voice recognition card in 1984. I could demonstrate it in a quiet room, but as a practical matter, it was not production ready at all. Around 1988 we built demonstration expert systems usin

Your call is important to us, but not much.

Rogers entire network is down and Rogers either does not know why or sufficiently disrespects its customers that it won't say. I was on the advisory committee for the largest private network in Canada serving 150,000 employees countrywide. I was also an active participant building out that network. I installed the first Local Area Networks there. I wrote a code generator responsible for the most critical portion of Bell's mobile network. I also wrote a portion of code for a system in the United States that detected and pinpointed line breaks in their network before they happened. For a time, I held the title 'Networking Professor' at our local College. I registered my first domain name in the 1980s. I have administered Internet network servers for decades. In one capacity or another, I have worked with most of the telecommunications providers in Canada past and present. Nearly a billion devices use a small network codec written by me decades ago.  Except that Rogers was