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_ sense. Because WS_ 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.
Light
Dark
21 comments
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”?
>> 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?
Yes, by using an undocumented API that only signed Microsoft processes can use.
https://stackoverflow.com/a/39253048/2604492
I am now very grouchy because Microsoft chose to give Task Manager a feature in a way that ProcessExplorer can never have.
Microsoft probably locked it away so that ransomware can’t use it. So I don’t mind.
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.
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 SOS UI hijacking that used to be popular or the ever famous Windows Updates UIs that websites liked to use in the past.
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, check which process this is”, “Hi there”, 0);
FreeLibraryAndExitThread(hInst, 0);
}
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 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.
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.
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 a privileged operation, to get bands to work.”
This is true(with a caveat)
“Explorer.exe runs in the context of the logged in user.”
This is also true.
The caveat mentioned above is that, while process injection is a privileged operation, it only requires you to have the same privilege as the process you’re injecting in to.
What you fail to connect is that explorer.exe IS one of those “signed processes”, and that, since it runs as the user, it can be injected in to easily.
You can have code run as the user, inject into the explorer.exe process that’s also running as the same user(since you are allowed to inject into your own processes), and make the restricted API call just fine, since the call is coming from a signed process(explorer.exe).
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.
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 on CPU usage (less critical today as it was back in the day) and, more importantly, open it immediately whenever I need it. The ability to look at the historic graphs of resource usage is a nice plus. In Windows 10, I always launch the native version, of course. I have the XP version lying around just in case I need one of the removed features. I rarely need them, but it’s nice having it at hand.
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 to running out of GDI resources.
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 and brushes, etc., which would consume handles.
And yes, I also use Process Explorer sometimes. The libraries and open handles panels are priceless sometimes, as is the threads listing with a static capture of their traces. But as I don’t need it often, it’s Task Manager who gets launched at startup.
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.
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.
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.
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?
SetWindowBand works only for Immersive Applications Manager thread.
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.