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.
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.
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.
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.
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.
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...
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.
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.
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...
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.
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...
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.
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...
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);
}
Yes, by using an undocumented API that only signed Microsoft processes can use.
https://stackoverflow.com/a/39253048/2604492
>> 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?
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”?