So what is a Windows “critical process” anyway?

Date:February 16, 2018 / year-entry #40
Tags:other
Orig Link:https://blogs.msdn.microsoft.com/oldnewthing/20180216-00/?p=98035
Comments:    10
Summary:Is­Process­Critical tells you whether a process is critical, but what does that mean?

I noted some time ago that Task Manager applies three somewhat arbitrary criteria for dividing processes into three categories: App, Background Process, and Windows Process. In particular, a Windows Process is one for which Is­Process­Critical reports TRUE.

SimonRev quite rightly calls out the documentation for being useless due to the fact that it merely states a tautology.

IsProcessCritical

Determines whether the specified process is considered critical. 

BOOL WINAPI IsProcessCritical(
  _In_  HANDLE hProcess,
  _Out_ PBOOL  Critical
);

hProcess [in] A handle to the process to query. The process must have been opened with PROCESS_LIMITED_QUERYINFORMATION access.

Critical [out] A pointer to the BOOL value this function will use to indicate whether the process is considered critical.

Return value: This routine returns FALSE on failure. Any other value indicates success. Call GetLastError to query for the specific error reason on failure.

Great, so we learn that the Is­Process­Critical function tells you whether the process is critical. But nowhere does it say what it means for a process to be critical or how a process becomes critical in the first place.

A critical process is one that forces a system reboot if it terminates. (More precisely, it forces a bluescreen error, which captures a memory dump before rebooting, so that the cause for termination can be investigated.)

How does a process get itself marked critical?

A few system processes do this on their own. For example, processes related to enforcing system security do this so that if one of them crashes, it stops the system immediately before any more damage can occur.

But most of the time, the way this happens if you create a service and set its recovery option to Restart the Computer.

Bonus chatter: Wait a second, there are some processes in the Windows processes list that aren't critical system processes. Like Console Window Host. How did they get there?

In addition to putting all critical system processes in the list, Task Manager also keeps a hard-coded list of processes that it puts in the Windows processes list whenever it sees them. That's why you see things like Console Window Host and Desktop Window Manager. So a more accurate list of what goes into Windows processes is

  • A hard-coded list of specific processes, plus
  • Processes marked as critical.
Comments (10)
  1. Damien says:
    February 16, 2018 at 7:28 am

    I’m unclear – is your list of “how” exhaustive? I.e. is it “A few system processes do this on their own.” (using a technique unavailable to any other process) and “most of the time … create a service” (this is the only technique available to mere mortal processes) or are there other means?

    There doesn’t appear to be an obvious SetProcessCritical function.

    1. Antonio Rodríguez says:
      February 16, 2018 at 9:24 am

      It seems that the “how” list is exhaustive. One of the points is clear: system processes that mark themselves as critical, and services marked as reboot-on-failure. The other point is more vague: a white list of some processes. I’d consider this white list an “implementation detail”, and, anyway, as this affects only to how Task Manager sorts processes, it doesn’t have too much practical effect.

      With the specification in hand, there is no need for a SetProcessCritical function, at least not a public one. Any service can obtain the same effect by marking itself as critical (“reboot-on-failure”) on install.

    2. Ramón Sola says:
      February 16, 2018 at 10:42 am

      Here be dragons.

      Ntdll.dll exports the RtlSetProcessIsCritical function since Windows XP which wraps the almighty NtSetInformationProcess. RtlSetProcessIsCritical is not officially documented, but you may find many snippets of source code and third-party research articles on the subject. The ProcessBreakOnTermination class code is hinted in the MSDN page for ZwQueryInformationProcess. You must have SeDebugPrivilege available and enabled, so you are already on the other side of the airtight hatchway.

  2. Paul Topping says:
    February 16, 2018 at 8:11 am

    Is the child process of a critical process also marked critical by default? I suspect the answer is “no” but I’m asking anyway.

  3. Mason Wheeler says:
    February 16, 2018 at 8:15 am

    >A critical process is one that forces a system reboot if it terminates. (More precisely, it forces a bluescreen error, which captures a memory dump before rebooting, so that the cause for termination can be investigated.)
    > …
    > But most of the time, the way this happens if you create a service and set its recovery option to Restart the Computer.

    OK, this is a bit confusing. I seem to recall hearing (on here? Not sure) that it should not be possible for user-mode code to cause a BSOD. Doesn’t this contradict that?

    1. Raymond Chen - MSFT says:
      February 16, 2018 at 9:04 am

      It should not be possible for user-mode code to cause a unintentional BSOD. We’ve seen intentional shutdowns before.

    2. Antonio Rodríguez says:
      February 16, 2018 at 9:15 am

      @Mason Wheeler: Technically, it is not user mode code who is raising the blue screen. It is raised by the Service Control Manager when it sees the service has crashed. But anyway, yes, you can write a malicious service that installs itself with this option enabled and then crashes to trigger the BSOD. But to do that you need to be an administrator so have permissions to install a service. And if you are, you could, for example, install a driver that crashes the machine or corrupts kernel memory. You are already at the other side of the airtight hatch.

  4. henke37 says:
    February 16, 2018 at 9:04 am

    To mark a process as critical you need to call the undocumented RtlSetProcessIsCritical function. You need the debugging privilege for the call to succeed. Using NtSetInformationProcess directly is also an option (still need the debug priv).

    Obviously you are on the fun side of the airtight lock if you have the privilege, so it’s not a vulnerability.

  5. JAS says:
    February 17, 2018 at 3:30 pm

    “Call GetLastError to query for the specific error reason on failure.”

    Why? Why not just return the code instead of a BOOL, like ADVAPI32 or COM exports?

    1. Yuhong Bao says:
      February 18, 2018 at 7:38 pm

      That has been standard in Win32 for a long time.

Comments are closed.


*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

<-- Back to Old New Thing Archive Index