May 2nd, 2023

Why does Task Manager disappear briefly when you switch it into or out of Always on top?

If you go to Task Manager’s Options menu and toggle Always on top, the Task Manager window disappears briefly, and then returns. What’s the reason for this?

When Task Manager goes into Always on top mode, it’s doing more than just being an always-on-top window in the WS_EX_TOPMOST sense. Because WS_EX_TOPMOST isn’t good enough any more.

Windows 8 introduced the concept of windows existing beyond the normal plane of existence. Windows 8 apps, the Start screen, toast notifications, and the lock screen (among other things) all exist in their own world outside those of regular Win32 desktop apps.

An always on top Task Manager wants to get in on that action. Otherwise, your Task Manager that’s marked Always on top would nevertheless get covered by Windows 8 apps and the Start screen.

When you switch into or out of Always on top mode, Task Manager launches a new copy of itself into the alternate universe, and the exits the previous instance. That’s the reason for Task Manager disappearing briefly: The old copy is gone, but the new copy has yet to arrive.

You can observe the effects of this switcheroo by watching the process ID in (ironically) Task Manager. The process ID of taskman.exe will change when you switch into or out of Always on top mode.

Topics
Other

Author

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

21 comments

Discussion is closed. Login to edit/delete existing comments.

  • Graham McIntyre

    When I was going through the backlog for TaskMgr, there was one suggesting to give a confirmation dialog that TaskMgr would restart when toggling the Always-on-top option. That seemed unnecessary and annoying to me given there’s really no state to save that needs confirmation, just the momentary ‘flash’ of closing and re-launching (for the reason you call out) which is relatively seamless. It got cut.

  • Ahmed Walid

    Can’t it use SetWindowBand instead of CreateWindowInBand(Ex)? I mean why does it create a new window/copy when it can just change the current window band?

    • Start Is Back

      SetWindowBand works only for Immersive Applications Manager thread.

  • George Styles

    Windows 11 has done a number on task manager. Its now bloated to the extent that it sometimes struggles to start up under stress. Bad move microsoft, bad move, Daves Garage has had it right for most of my life, and now its crap.

    • Paulo Pinto

      Actually the performance drop is a side effect of it adopting WinUI, just check the pilling of issues on Github related to WinUI, in many cases it even performs worse than UWP.

      One would expect that WinDev adopting it across the board would help, but apparently all the action is definitly in supporting Azure workloads.

      • Jan Ringoš

        The main underlying issue is ironically the accelerated composition. While great on paper, maintaining and shuffling all those composition surfaces and bitmaps for every element (for fast composition on GPU) is way more expensive, and especially has much bigger perceived latency, than drawing directly, like GDI used to do.

    • Antonio Rodríguez · Edited

      If Dave's version suits your needs, you will be glad to know that Windows XP's version runs just fine in Windows 10 x64. I have not tried it in Windows 11, but I'd be surprised if there was any problem.

      For my part, I always have Task Manager running, minimized to the notification area, launched at session start. I have done that since the days of Windows NT 4. It allows me to keep an eye...

      Read more
      • Michael Taylor

        Personally I use Process Explorer over TM but agree that ensuring it starts early in Windows is what I do. Of course if something eats up enough GDI resources then there isn't any Windows UI that is going to work (Task Manager, Process Explorer, Dave's Garage, etc) because Windows cannot allocate UI resources to display/update a UI if there are no resources available. Short of running in a separate windows session, there is no workaround...

        Read more
      • Jan Ringoš

        Back in the day I wrote very simple App, a process list with capability to kill [called Supervisor], that runs on it's own Desktop for this very reason. Also because some games used to freeze on me in Direct3D overlay on XP. Anyway desktops have their own GDI and USER resource heaps to allocate from, so as long as you can switch, apps on other ones will work regardless of exhaustion on the main one.

        Read more
      • Antonio Rodríguez

        Luckily, I haven't seen Windows run out of GDI resources in the last 20 years. Last time it happened to me, I was still running NT 4. Around 2002, IIRC. XP already was there, but I haven't switched yet. Also, I'm not sure you could open a command line if GDI or User resources were depleted. It would need to create a window, with its system menu and icon, and load the font, create regions...

        Read more
  • Joshua Hudson

    I am now very grouchy because Microsoft chose to give Task Manager a feature in a way that ProcessExplorer can never have.

    • Dan Bugglin

      Microsoft probably locked it away so that ransomware can’t use it. So I don’t mind.

      • George Tokmaji

        According to a blogpost linked in the SO answer posted above, you can circumvent the locks by injecting DLLs into various signed processes, and while that isn’t a good idea for production applications, I doubt ransomware would care much.

      • Michael Taylor

        But injecting DLLs requires elevated privileges so malware would require elevated privileges to be able to do that and as Raymond points out constantly, once you're on the other side of the hatch then it doesn't really matter anymore - you're already in. If this were a regular Win32 API that anyone could call then malware wouldn't need elevated privileges and so it would be much easier to hijack the system. I'm thinking the old...

        Read more
      • Chris Iverson

        You've said many true things, but don't seem to connect the dots between them.

        " It would be quite easy to display a “Windows Update” or “SOS” screen on top of the desktop if all you needed to do was run a process that is already parented to the shell."

        The whole thing we're saying is that it IS essentially that easy.

        "As was stated earlier you have to inject a DLL into a signed process, which is...

        Read more
      • James · Edited

        As far as I’m aware, injecting a DLL into a process (signed or not) does not require elevated privileges, unless you are injecting into an elevated process.

      • Michael Taylor

        I fail to see what explorer.exe has to do with this conversation. As was stated earlier you have to inject a DLL into a signed process, which is a privileged operation, to get bands to work. Explorer.exe runs in the context of the logged in user. If you already have access to it then you don't need to inject anything, you're already there. Hence why the API doesn't just allow you to call it. It...

        Read more
      • Joshua Hudson

        explorer.exe is not an elevated process.

        Actually injecting into explorer.exe is a supported operation. It's what most people do next that's not supported.

        Sample completely supported procedure (pseudocode)

        // Injector
        address = VirtualAllocEx(hExplorer, ...);
        WriteProcessMemory(hExplorer, address, L"payload.dll", sizeof(K"payload.dll"))
        CreateRemoteThread(hExplorer, GetProcAddress(hKernel32, "LoadLibraryW"))

        // payload
        HINSTANCE hInst;
        BOOL DllMan()
        {
        if (DLL_PROCESS_ATTACH) { hInst = hInstance; CreateThread(..., Worker, ...); }
        return true;
        }

        DWORD Worker()
        {
        MessageBox(NULL, "use process explorer,...

        Read more
  • Michael Taylor

    >> You can observe the effects of this switcheroo by watching the process ID in (ironically) Task Manager. The process ID of taskman.exe will change when you switch into or out of Always on top mode.

    Taskman? Don’t you mean taskmgr.exe?

  • Piotr Siódmak

    Does Edge do the same? Sometimes Edge (or some other apps) appears over the taskbar and I have to click the taskbar to put it on top again and then it stays on top. Or is it that an autohide taskbar lowers itself back into the “normal plane of existence”?