Why are taskbar live previews lost when you use Fast User Switching?

Anonymous asks a metric buttload of questions, which means that I feel compelled to answer all or none. And given the choice, I decided to answer none.

Okay, I will answer one and ignore the rest.

Why are taskbar live previews lost when you use Fast User Switching?

When you switch away from a user via Fast User Switching, the Desktop Window Manager for that session is turned off. After all, since that session no longer has access to the screen, there's no point running all this code and consuming all this memory for something nobody can see.

When the Desktop Window Manager restarts upon reactivation of a session, it can recovery nearly all of the information it needs: It can enumerate all the windows and obtain their positions and styles. For each visible window, it can send a WM_PAINT message to ask it to paint its contents afresh. But if the window is minimized, the Desktop Window Manager has no way to get at the application's non-minimized pixels, because the application will respond to the WM_PAINT message by saying, "My client area is 0×0. I will therefore paint nothing!"

This is one of those tradeoffs that you have to make when engineering software. The benefit of shutting down the Desktop Window Manager when it is not being used exceeds the cost of losing thumbnails for minimized applications. Until the application is restored (and can therefore be sent a WM_PAINT message to get it to paint its client area at its restored size), the Desktop Window Manager merely shows a placeholder bitmap.

Comments (25)
  1. NB says:


    I've never even noticed that they disappeared. Have to test sometime.

  2. the Desktop Window Manager merely shows a placeholder bitmap

    Does not explorer itself paint placeholder? I don't see placeholder in the API.

  3. Dan Bugglin says:

    I noticed that they disappeared but never realized why.  Cool.

  4. Probably explorer always paints placeholder, then usually DWM paints thumbnail over it if it can.

  5. David Walker says:

    From what I can tell, a lot of technical Windows users do not share their computers with anyone else.  I always turned off Fast User Switching in Windows XP, so I never saw this issue anyway.  In Windows 7, I never "Switch user", so I still never see the issue.  :-)

  6. @Macrosofter

    I would imagine the DW manages both the live previews and the screenshots, and Explorer manages the window menu and text.

  7. *dwm

    Thanks for letting us edit our comments, MS.

  8. Clipboarder Gadget says:

    In the temp dictionary? I really wish they would have implemented that. The thumbnails get lost here all the time. Not only while user switching, also after starting fullscreen games.

    They also could have introduced a new window flag which makes minimized windows only move offscreen. This wouldnt break anything in most applications, so everybody could just enable this flag.

    [What is "the temp dictionary"? Remember, these thumbnails reside in video memory, not system memory. -Raymond]
  9. alegr1 says:

    The preview is also discarded if the desktop is locked (if for a while?), even for non-FUS box, like my Win7 laptop.

  10. Lefty says:

    Posting a metric  buttload of questions! Who does that Anonymous think he is anyway?

  11. There is another related "problem" caused by the behavior Raymond is describing:  minimized windows don't get a thumbnail updated.  This is easy to reproduce:

    1.  Run media player with visualizations.
    2.  Hover mouse over taskbar; notice the slick thumbnail with a smooth view of the animated visualization.

    3.  Minimize the media player.

    4.  The thumbnail is now stale and isn't updated with the latest visualization.

    Some ideas for solutions for both this problem and the original one Raymond describes:

    1.  Restore the window, send it a WM_PAINT, then minimize it.  Implement some hacks in DWM/explorer to prevent the restored windows from showing up.  But this will probably be slow and cause app compatibility problems, and would make the Windows architecture smell a little worse.  Probably a terrible solution.  Probably wouldn't work for my scenario either, because you'd have to poll the minimized windows for updates so would be very slow.

    2.  Save thumbnails like hacksoncode describes; actually DWM obviously is already doing this, as evidenced by my steps above; it's just not retaining them across session switches.  But this will surely introduce performance penalty when switching sessions if DWM is being shut down.

    3.  Perhaps the architecturally cleanest solution is to rectify the original problem, which is that there's no way for a window to be minimized and have a client area needing painting at the same time – a limitation that at first glance seems to date back to Win16 and the transition to Win95 taskbar.  In Win16, window area was the minimized icon; in Win95 this was eliminated entirely when minimized.  There was never a concept of separating the rendering of the minimized icon from the rendering of the restored window itself.  Perhaps the appropriate window functions and messages could be modified, with new messages added, to rectify this.  For example, a new message for painting that supersedes WM_PAINT and might be called if window is minimized.  Downside would be apps would need to support it.  But there would be no big performance penalty like with the other two options and you could still shut down DWM.  This option seems like it would fit in relatively cleanly with the rest of DWM.

  12. Joshua says:

    Ref #3, why new messages? Resurrect WM_PAINTICON. That would be really funny if my one old Win 3.1 program that uses it starts working again.

  13. hacksoncode says:

    Would it *really* have cost that much to save the bitmaps as the session was exiting? Of course, they might change while the session is inactive, but at least you'd have the last view.

    [Save them where? And remember, you start at −100 points. -Raymond]
  14. Neil says:

    @Joshua My Windows 3.x iconic clock app simply paints in response to WM_PAINT as per usual, although obviously with a (typically) 36×36 client rectangle.

  15. xpclient says:

    Hehe I was the Anonymous. (proof is in the Auto-refresh question). :P Anyways, thanks for the explanation. I thought first that the setting "Save taskbar thumbnail previews" would save them, but that is completely unrelated.

  16. Rassmuss says:

    Microsoft should have allowed the user to choose. Have an option to save the last known thumbnail or restore the minimized window temporarily in a hidden (not visible to the user) screen space to be able to get a fresh thumbnail on request.

    Microsoft could have had the option turned off by default and allow advanced users to turn if on.

    I hate when a company thinks it knows best. Reminds me of hitler and also apple.

    [Ah, the mating call of the loser. Where do you want to save this last-known thumbnail? The Desktop Window Manager is gone! Also: "If you check this box, applications might behave erratically or crash (because they check the WS_MINIMIZED style, or because they crash if they get a WM_PAINT when minimized)." Who would seriously check that box? -Raymond]
  17. henke37 says:

    Doesn't applications get the option to chose what thumbnail to display?

  18. "Microsoft should have allowed the user to choose."

    And that's how you end up with questions you cannot answer, and how you end up with Options dialog boxes that present seemingly hundreds of confusing options.  No thanks.

  19. Joshua says:

    [Who would seriously check that box? -Raymond]

    Me. I'd also uncheck it if it did screw up one of my programs. But yeah, I saw immediately what a bad idea that was. Which is why some of us were discussing an opt-in method for programs that understand.

  20. Nick says:

    "Which is why some of us were discussing an opt-in method for programs that understand."

    Congratulations – behavior is now inconsistent!

  21. Alex Cohn says:

    Windows may forget many important thingch to that login screen.

    For example, when a user changes password, the keyboard shortcuts are lost. The ones that trigger specific input languages (I use Alt-Shift-1 for US English, Alt-Shift-0 for Hebrew). Alt-Shift to cycle around the input languages is remembered, though.

  22. JoeWoodbury says:

    James, what would be the rules for a minimized app to update it's window(s)? And where would it be drawing? Its proverbial slate has been taken away.

  23. JoeWoodbury says:

    Rassmuss, why would anyone ever enable such a feature? Who gives their icons more than a glancing view when working and switching apps? The point of these icons is do give a visual hint of what document the application has open, not to provide an alternate way to work in miniature. You are asking to create enormous complexity to solve a problem nobody else perceives as such. (There's already too much of this in about every product.)

  24. @JoeWoodbury: Basically it would continue to render itself normally when minimized.  The fact that it is minimized wouldn't affect things any more.  It would be drawing to some buffer on the video card managed by DWM, which I assume is already the case when rendering today.  Where and how DWM decides to display that buffer is up to DWM – not the app.

    The notion of the window's slate being directly placed on the video buffer driving the screen – like in Win16 – went away a long time ago.

    [The point is that there is no existing message that says, "Hey, I know you're minimized, but please paint as if you weren't." To do that, you'd have to invent a new message, which means that only new-style applications could take advantage of it, and hey look, that message already exists. So the answer is "We are so smart, we did what you are requesting 3 years ago." -Raymond]
  25. 640k says:

    Seldom programs keep state of if they are minimized. A faked WM_PAINT could have been used in 99% of the cases to get the window bitmap. WM_DWMSENDICONICLIVEPREVIEWBITMAP is unnecessary cruft, as most thing in post-Vista.

    [But GetClientRect returns 0 when minimized, so if you asked them to paint, they would paint nothing. And "seldom" is nowhere near good enough for compatibility. If only 0.1% of Windows programs crashed when minimized, that's still 4,000 programs. -Raymond]

Comments are closed.

Skip to main content