Welcome back AskPerf! It’s Day Four of our pre-launch series. Even though it’s Sunday here, we’re not letting up at all – we’re feverishly working to get the rest of our series completed! Today’s topic is the new Unified Background Process Manager (UBPM). Historically, Windows has included various process managers that manage background processes as part of their functionality. Examples of current background process managers in Windows include:
- Service Control Manager – manages Windows Services
- Task Scheduler – manages Windows Tasks
- Windows Management Instrumentation – manages WMI providers
- DCOM Server Process Launcher – manages out-of-process COM applications.
These process managers perform similar duties, such as activating or deactivating processes based on particular scenarios, yet they are mostly isolated from one another, with few shared components and differing servicing requirements. Windows 7 and Windows Server 2008 R2 introduce the Unified Background Process Manager (UBPM) scheduling engine. The goal of UBPM is to move the common process lifecycle management portion of the existing process managers to a unified process lifecycle manager.
UBPM provides a trigger-based activation platform to manage the lifecycle of background processes for UBPM-registered clients. Currently, for Windows 7 and Windows Server 2008 R2, the only process managers that are registered as UBPM clients are the Service Control Manager and the Task Scheduler service. UBPM has trigger providers as well. UBPM starts an Event Tracing for Windows (ETW) session and enables each registered provider GUID in the session. It also implements an ETW real-time consumer that listens for the pre-registered trigger provider events and notifies the trigger consumers when they occur. The UBPM ETW session Properties are shown below:
UBPM is hosted in-process by the clients that utilize its services as UBPM.DLL as shown below:
As a UBPM client, SCM can take advantage of triggers from the various UBPM providers so that it can start services only when they are required, and similarly stop them when they are no longer required. Services that need to take advantage of trigger-starting must be configured for a manual start. Triggers for services are typically one of the following:
- Obtaining an IP address – Certain network-dependent services only need to start when a machine has an IP address. This is most applicable to mobile PCs that don’t always have a network connection.
- Domain join / disjoin – At startup, if the computer is a member of a domain then services that depend on this trigger will start. The Windows Time service is a classic example of such a service. The Time service is used in a domain environment to synchronize a computer’s time with the domain hierarchy to keep Kerberos happy.
- Hardware device arrival – The best example of this is the Bluetooth Support Service which only needs to run when a Bluetooth device is connected.
- Group Policy change – Some services only need to run when a Group Policy change is detected.
- Custom – Service developers can design their own custom trigger events that can be raised from either user mode or kernel mode. A service can then be started or stopped based on the custom trigger events, such as an ETW event
SC.exe can be used to query the current trigger-start configuration of a service:
C:\Windows\system32>sc qtriggerinfo w32time
[SC] QueryServiceConfig2 SUCCESS
DOMAIN JOINED STATUS: 1ce20aba-9851-4421-9430-1ddeb766e809 [DOMAIN JOINED]
DOMAIN JOINED STATUS: ddaf516e-58c2-4866-9574-c3b615d42ea1 [NOT DOMAIN JOINED]
Task Scheduler is also a UBPM client and can trigger scheduled tasks based on events from UBPM providers. The UBPM infrastructure for Task Scheduler includes UBPD.dll, hosted in the Svchost.exe instance that hosts the Task Scheduler service, and Taskhost.exe, which hosts UBPM-registered tasks.
When an in-box task starts, it will be hosted in taskhost.exe. Separate taskhost.exe processes are used to host UBPM-managed tasks that execute under different user accounts or that require significantly different privileges.
Taskeng.exe is still responsible for activating legacy tasks. Additionally, if you manually create and execute a task, it will be hosted in TaskEng. Process Explorer can be used to identify which task engine is hosting specific running tasks. Just locate a taskhost.exe or taskeng.exe instance and hover the mouse pointer over the process to see a balloon message that lists the tasks hosted in that instance. (Be sure to obtain the latest version of Process Explorer for this to work.)
That’s it for today – tomorrow’s topic is ConHost. Your host for tomorrow is … well, it’s me again. See you then – enjoy the rest of your Sunday!
– Jim Martin
|Share this post :|