What does a Windows service type of 0x30 mean?

Question

A Windows service of type WIN32_SHARE_PROCESS (0x20) runs as a thread in a process which it shares with other services. (Although, in recent Windows 10 builds, it may get its own process anyway.) A Windows service of type WIN32_OWN_PROCESS (0x10) runs in its own isolated process. But, some Windows services have type wIN32_OWN_PROCESS | WIN32_SHARE_PROCESS (0x30). What does that combination mean?

sc query calls that combination WIN32. For example, sc query AppInfo reports:

SERVICE_NAME: AppInfo
        TYPE               : 30  WIN32
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

The Windows API docs don't mention this possibility. They talk about what each flag means independently, but not in combination. They do reference 0x30 in the documentation of EnumServicesStatusA, but in the context of that function it is documented as returning services with either types set, it doesn't talk about what it means for a service to have both types set.

(The service type field can take several other values: driver services like SERVIC_KERNEL_DRIVER, the SERVICE_INTERACTIVE_PROCESS flag, user services, etc. I am not asking about any of those other values/flags in this question, only about the 0x30 combination.)

question from:https://stackoverflow.com/questions/65918161/what-does-a-windows-service-type-of-0x30-mean

Answer 1

As you point out, changes to service host grouping in Windows 10 may result in services of type SERVICE_WIN32_SHARE_PROCESS running in their own, isolated process. Whenever that happens to a service, SC will show it as SERVICE_WIN32 -- the confusing union of SERVICE_WIN32_OWN_PROCESS and SERVICE_WIN32_SHARE_PROCESS.

We've confirmed this situation by playing with the registry.

On our Windows 10 VM (which has ample RAM to trigger the process isolation enhancements), SC says AppInfo is of type WIN32 (30):

Task Manager reported that AppInfo was running in its own process.

As per the documentation, we disabled process isolation for the AppInfo service by adding the SvcHostSplitDisable value:

And after a reboot, SC reported AppInfo of type WIN32_SHARE_PROCESS (20):

The Task Manager confirmed that the process was indeed shared.

So its all down to those changes to service process isolation in Windows 10 Creators Update (version 1703).