How do I force the Task Manager window closed whenever it opens?

A customer wanted to close (or at least hide) the Task Manager window whenever it opens. They did so by setting a timer and periodically running this code:

void FindAndCloseTaskManager()
  HWND taskManagerWindow = FindWindow(nullptr, "Windows Task Manager");
  if (taskManagerWindow) {
    PostMessage(taskManagerWindow, WM_CLOSE, 0, 0);

This code worked on Windows 7, but stopped working on Windows 8.

Well, yeah, because you're searching for a window by name. The name of the Task Manager window in Windows 7 was Windows Task Manager:

On the other hand, in Windows 8, the window was named simply Task Manager.

And of course, those names apply only to English. If the user's UI language is German, the name will be Task-Manager with a hyphen.

Whether a user can or cannot run Task Manager is an administrative decision, not an application decision. Use the "Remove Task Manager" group policy.

Bonus chatter: Note that if this customer had their way, the name of Task Manager would be a compatibility constraint.

Bonus bonus chatter: Don't think you can rely on the window class name either. That is also subject to change.

Comments (30)
  1. Antonio Rodríguez says:

    This is more than a technical question. I can think of many reasons why the customer would like to block the Task Manager from another program – and none of them is legit.

    1. The MAZZTer says:

      I am sure plenty are legit (customer wants a program running on their own PCs and don’t want employees to be able to task kill it) but they are doing the “easy/impossible parts” thing Raymond mentions occasionally: they have decided the way to fix the problem is to stop the user from invoking the TerminateProcess API on their task (even if that’s not the way they’re thinking about it), and now they implemented the impossible part… badly and incorrectly.

      1. cheong00 says:

        I have seen people doing crazier thing, like adding imagefileexecutionoption for task manager EXE file path, and point it towards their EXE that resembles /bin/true .

    2. The MAZZTer says:

      tasklist.exe, taskkill.exe, Process Hacker, Process Explorer, pskill.exe, pslist.exe, other third-party tools, or simply just racing to change the Task Manager window title before this other tool finds it… whoever wrote this didn’t quite get the scope of the problem he was asked to address (if he did, he would have realized he had the “impossible” part of that easy/impossible problem split).

  2. DWalker07 says:

    It sounds like something a virus would do, to prevent the user from easily ending a process.

    1. The MAZZTer says:

      One important thing to keep in mind is that it’s ultimately the owner of a machine who should have final say over how it functions (well, that’s what I believe… “walled garden” approaches represent a different philosophy which also has merits for users who don’t fully understand how to secure their own systems).

      So this customer’s control over a PC makes sense if they are the owners of the PCs, and their employees are users. Since they own the PCs and network it makes sense they have the right to dictate what their employees can do on the machines. Of course this specific example shows a rather poor understanding of how to control user access to processes.

  3. Gee Law says:

    If the user is also a local administrator, wouldn’t the check program have to run with administrative privileges or with UI access? If the user is using an LUA, I’d say that program is just another piece of malware.

  4. This “malware” will never be able to kill my “Aktivitetshanteraren” window!

  5. Harold H20 says:

    As usual, the customer is trying to do weird, crazy things that they shouldn’t be doing, but it also exposes a much bigger problem: Microsoft constantly changing small details.

    Win 7 [Windows Task Manager] –> Win 8 [Task Manager]
    Win 7 [Wireless Network Connection] –> Win 8 [Wi-Fi]
    And so on . . . .
    Why? What possible benefit are you achieving?

    Microsoft is infamous for constantly changing URLs on its websites and breaking bookmarks that people have saved. Someone at Microsoft has some very serious ADD issues and apparently feels the need to constantly tinker and change things, for no good reason.

    1. I suspect some of the changes are to match user expectations. “I can’t find Task Manager.” or “I can’t find the thing for controlling WiFi.” Oh, it’s because Microsoft gave it some name that nobody is looking for. Like, c’mon, Microsoft. Stop making up nonstandard names for everything!

      1. Joshua says:

        It seems these days no matter how absurd a position you can find somebody to argue for it.

      2. Keith Patrick says:

        I’d consider this more of an issue with the Start menu’s search (in)ability. If it was looser with its search results (and returned more *local* hits), the user wouldn’t have to try to guess the app name.

        1. Yuri Khan says:

          The user should not *have* to use the search facility to find programs. Instead, they should be there in the expected part of the alphabetical list, under T in the appropriate group.

          1. Keith Patrick says:

            Maybe the user doesn’t even know what a “Task Manager” is (maybe the person looks for “app” or “process” or “stop”)…the shell should (as of 2018) allow for users to say “stop app” and get a task manager and/or a help topic about it. The alpha list would be the browsing (sequentially indexed) path to the app, but there should still be a searching path (randomly indexed).

    2. morlamweb says:

      Honestly, I never noticed that the name of the Task Manager window changed in Windows 8, and I use Windows 7 and 10 daily (and Win 8.x when it was around). What exactly is the problem with changing the title of a window?

      1. Paul says:

        It’s indicative of the fact that Microsoft randomly changes things for apparent reason (or, a reason that makes sense to the person who now can’t find the thing they wanted because it’s now different).

        1. Randomly changing names isn’t Microsoft’s only problem. There is also:
          1. Changing the names without accounting for consequences (e.g. “Action Center”)
          2. Giving things names when they must not have any (e.g. “SAC-T” and “SAC”)
          3. Failing to assign names when they desperately need one (e.g. whatever “Metro” was the codename for)
          4. Technically flawed names (e.g. “printer”, “x86” and “boot partition”)
          5. Atrocious name choice (e.g. “SAC-T” and “SAC”, “CB” and “CBB”, “2007 Office Systems”, names of Windows 8 editions)
          6. Naming inconsistency (e.g. “XP”, “Vista”, “7”)
          7. Failing to stop using a bad term when it is high time it is done (e.g. “directory” instead of “folder”)
          8. Pretending that a certain name has a meaningful philosophy when it actually does not (e.g. “Program Files”, whose translations didn’t follow the philosophy)
          9. Atrocious language use (e.g. “devices or printers”, “Active Directory directory service”)

          1. cheong00 says:

            Humm… I thought “boot partition” is borrowed from Unix world where they do have a “/boot” partition?

            And “x86” is a term defined by Intel that denotes things that are “8086 compatible”.

          2. And yet, when Microsoft says boot partition, it is talking about a partition that by default, has nothing to do whatsoever with booting; a boot partition host’s the system root. Boot is the job of system partition, which, by default, has nothing to do with system root!

            As for “x86”, Microsoft uses this term inconsistently, sometimes to refer to the whole x86 architecture (which includes IA-32, MMX, x86-64 and everything else) and sometimes as a metonym for IA-32. It is okay so far. But they sometimes write atrocious phrases like “x86 vs. x64” in a way that makes people think they are competing architectures.

            By the way, there is no such thing as 16-bit x86. Even the real mode of Intel 8086 is 20-bit.

          3. cheong00 says:

            But which kind of term do you find more confussing? “x86” for 32-bit while it should point to 16-bit, or the Linux arch name such as i386/i586/i686?

          4. Jan Ringoš says:

            > By the way, there is no such thing as 16-bit x86. Even the real mode of Intel 8086 is 20-bit.

            In that case the x86-64 isn’t really 64-bit, but 48-bit.

          5. Darran Rowe says:

            @Fleet Command
            “By the way, there is no such thing as 16-bit x86. Even the real mode of Intel 8086 is 20-bit.”
            This had nothing to do with the address space, it was pointer size. AX, BX, CX and DX are 16 bit with 8 bit portions (AH and AL for AX as an example). SI, DI, BP and SP were 16 bit only. This means a single pointer without using the segment selectors was 16 bit.
            If you look at 32 bit x86, EAX, EBX, ECX, EDX, ESI, EDI, EBP and ESP are all 32 bit. If you look at 64 bit AMD64/EMT64 (x86-64 or just x64), RAX, RBX, RCX, RDX, RSI, RDI, RBP, RSP, R8-R15 are all 64 bit. So you can think of the platform bitness as the size of the general purpose registers.

          6. @Darran Rowe: Huh! Figures. So, it is not a matter of address space; it is a matter of address space register sizes.

            Thanks a lot.

            So, 8 years of reading this blog, I finally learned something and not from the blogger. You know, I literally knew every single thing you said; the conclusion, however, never occurred to me. I guess it is because my expectation of the outcome (supported amount of memory) far overshadows such trivial matters.

          7. Darran Rowe says:

            @Fleet Command
            I forgot to mention, the 20 bit addresses was only for the 8086, the 80286, which was still considered 16 bit, was able to address 16MiB, so it had a total physical address space of 24 bits.
            The general purpose registers were still 16 bit though, so the near pointers were all 16 bit, and the far pointers were 32 bit (segment offset pair).

          8. Keith Patrick says:

            “WinCE” has to be in the hall-of-shame for bad MS names. How on earth did they let their main product out the door with a shortened name of “wince”?

          9. Falcon says:

            Also, remember that 8-bit processors, such as the 8080, Z80 and 6502, had 16-bit address spaces!

          10. Dirk Gently says:

            “By the way, there is no such thing as 16-bit x86. Even the real mode of Intel 8086 is 20-bit.”

            Using the same logic (i.e. using the address space rather than register size to determine the “bitness”) 6502 is a 16-bit processor.

    3. Bob says:

      Except most other places in (English) Windows 7 (e.g. control panel, ctl-alt-del screen, task manager help menu etc) it is simply referred to as “Task Manager.”
      Therefore changing the window title from “Windows Task Manager” to “Task Manager” to be consistent is surely an improvement ?

    4. Antonio Rodríguez says:

      Microsoft knows, as any developer worth their salary, that any change in a released program has to overcome users’ resistance to change. So I always give them the benefit of doubt and suppose that they have done their homework and determined that the change either isn’t disruptive, or it’s worth the trouble that will -invariably- cause. The evolution of Office user interface is a classical example: how fear of change resulted in the wreck that Office 2003 was, how that forced Microsoft to rethink it in Office 2007, and how it was met with loads of criticism, even if it was the best design innovation to come out of Redmond since Windows 95.

      Anyway, at the end of the day, Windows is Microsoft’s property, and we all can have our opinions, of course – but we only have voice when Microsoft explicitly asks us. It’s hard to be on the narrow end of the funnel, I know; but it’s also impossible to please everyone when your installed base nears a thousand millions.

      1. Joshua says:

        On the other hand I remember Office 2007 being the wreck. The worst of it got fixed in 2010 then 2013 has bad COM registration bugs. 2016 (current) is finally up to 2003 quality.

Comments are closed.

Skip to main content