Debugging why a user’s taskbar disappeared

A customer reported that they had gone to the Screen Saver control panel, selected a screen saver that they had recently downloaded, then hit the Test button to see what it looked like. He was pleased with what he saw, and he went home, leaving the screen saver running.

When he returned the following morning, he found that the screen saver had crashed. (There was an error message on the screen.) After dismissing the crash dialog, he found that his taskbar was missing. What happened?

We were unable to determine for sure, but debugging the customer's machine revealed that the taskbar no longer had the WS_VISIBLE style, most likely because the screen saver had done a Show­Window(hwnd, SW_HIDE) on the taskbar window in a misguided attempt to ensure that the taskbar was not visible while the screen saver was running.

The authors of the screen saver intended to re-show the taskbar when the screen saver was dismissed, but since it crashed, it never got its chance.

This is another case of using a global setting to solve a local problem. The local problem is "I don't want the taskbar to be visible while my program is running," and this can be accomplished with a local solution. Instead, they used a global setting (even worse, an undocumented global setting) and since the program crashed, it never got its chance to restore that global setting to its previous value, leaving the setting borked.

Comments (20)
  1. Raphael says:

    It's times like this that I think that the shell (not explorer.exe, but whatever is set in the registry) should be somewhat more protected from user interference.

  2. Joshua says:

    What's funny is this is plenty well documented, just not suitable for the task at hand.

    (I'm assuming they did an EnumWindows over the desktop and did a SW_HIDE on all top-level topmost windows.)

  3. phi says:

    A bit off-topic, but sometimes, we need to be able to change "something" to the system, but only temporarily (the screen resolution comes to mind). It could help if we could do those changes with a sort of system handle that we could close to revert to the previous setting. As a system handle, if the process were to crash, the previous setting would be restored automatically.

  4. anon says:

    phi:   What if more than one program did this at the same time?  Now you have another problem, you'd need to have some sort of fifo stack of changes to these settings..

  5. phi says:

    anon : exactly. a sort of stack. of course it depends on the setting being changed, but in my example (screen resolution) that could even be a way to prevent two programs from changing the resolution at the same time, because a handle's owner can be tracked.

  6. Anonymous Coward says:

    @Phi: Use CDS_FULLSCREEN. Games have crashed on me in the past, and Windows seemed to correctly reset the resolution back to what it was. In any case, the display settings in the registry are untouched.

    @Raphael: In my opinion access should be based much more on a per-process model than on a per-user model. Currently, even if you run as a restricted non-admin account, a piece of malware can still wipe your documents, send them over the net, change them subtly, and so on.

    Unless you are the developer, you in principle don't know what a piece of software does. Access control based on the user account thus makes no sense. A much better model would be to restrict what applications can do to the bare minimum that they need. A text editor for example doesn't really need more than a window and access to the document. If it needs more access (after a common dialogue or d&d operation) grant it on a need-to-access basis. And even then it would be a good idea to have some extra safeguards in place, like for example a source control system on your documents & settings.

  7. configurator says:

    @Anonymous Coward: That seems very much like the Android security framework, except that one doesn't give you the option to grant a permission on a need-to-access basis, except for some specific permissions.

  8. "A customer reported that they had gone to the Screen Saver control panel, selected a screen saver that they had recently downloaded, then hit the Test button"

    When he got back, all his documents were wiped out, all his email deleted, and tons of span has been sent from his email program. Also, because by default he was a local administrator, his machine was now running various spyware.

  9. John says:

    @Anonymous:  Computers are hard enough for most people as is.  Besides, it's not going to help anyway.  Like UAC, people will just train themselves to click-through the annoying dialog box and punch the monkey.

  10. Someone says:

    @John: It is still very useful to know what permissions a program requests, and to be able to deny this permissions. For the Android example, thanks to this system, I can avoid games that request "full internet access". The only disadvantage is that the current system is not fine-grained enough. For example, I would allow some apps to perform HTTP requests but no other kind of internet traffic, especially not "full internet access".

    The same problem arises when an Adroid app requires "full access to the storage card" (can't remember the exact wording). What does this mean? Access to any file on that card (very bad) or only to a app-specific directory (much better)?

  11. Adam Rosenfield says:

    @Someone: If you allow HTTP requests, then that's hardly any better than allowing full internet access.  All you need is a web proxy that tunnels TCP traffic on port 80 into whatever protocol and whatever port you need.

  12. Someone says:

    @Adam Rosenfield: Maybe, but then there would be some responsibility of the provider of such a public web proxy. There are many millions of mobile phones, but only a limited number of such public hosts. If used to generate e-mail spam (for example), such host would be blacklisted very fast.

  13. J. Peterson says:

    My question:  How do you get Mr. Chen and his team of experts racing to your desktop whenever Windows misbehaves?  That must be some support contract…

  14. Jonathan says:

    @Adam Rosenfield: And to expand on your point, HTTP requests can also be a data leak.  Any data a potentially malicious app might want to upload could be embedded directly into the HTTP requests.  (OK, if they wanted to steal a video that'd be a heck of a lot of HTTP requests, but other data is much smaller and potentially more valuable.)

    Just another way that only HTTP requests are hardly any better than full internet access.

  15. AP² says:

    @configurator: and before Android there was Nokia's Symbian, which already had not only per-app permissions, has you could grant them on demand (for example, Opera Mini asks for Network Access at startup, but only asks for Filesystem Access when you download some file).

  16. hankdane says:

    On the "do things the hard way" note, I once had a co-worker ask me about doing some odd thing in a batch-file.  I forget the details of the question, but I figured out what he wanted to do: he needed to fire a command on a given time every day.  So he had set up a cron command on a Linux box which then was going to activate a bash shell in Cygwin which then would fire the batch file, or something along those lines.  When I asked "any reason you cannot use Scheduled Tasks?" the question came back "What's that?"  After pointing him to the appropriate Control Panel app, we had completed his objective in 5 minutes.

  17. Worf says:

    "Full internet access" for Android apps is because the app has ads. It's the only way Android devs can make money. Enough so that RIM claims to have paid out developers more money than the Android Marketplace for Blackberry App World.

    Well that and Google dropped the ball because free apps were the only ones available until Google Checkout was supported in the country. It led to my company not being able to buy our app. Of course, others found out you don't really need to pay for apps when you can trivially grab it off your phone. It was so bad that Google had to reduce the return period from 24 hours to 15 minutes. (And why Google withdrew from Taiwan – they were not willing to obey Taiwan's 7 day return rule.)

    Oh, and yes, HTTP requests are the same. If an app wanted to spy on you, HTTP is a perfect mechanism. Just have it call some random webserver CGI script with the data, done. Also guaranteed to work over all data connections – many providers proxy/NAT/firewall/etc the smartphone plans, so HTTP is probablyy the only guaranteed method.

  18. Neil says:

    Netscape 7.0 (Gecko 1.4) used to do this back in 2002 for its (then new) full-screen mode, but I fixed it (i.e. removed the code) for 7.2 (Gecko 1.6) a couple of years later. (The problem is more obvious because the full screen mode only covers one monitor.)

  19. Neil says:

    Sorry, I meant Netscape 7.2 (Gecko 1.7) of course.

  20. 640k says:

    I notorious bug in windows/directx which plagued win9x was that the taskbar was stuck at a lower resolution in the middle of the screen when the fullscreen app was exited and the desktop was restored the original higher resolution.

Comments are closed.