Thoughts from the EPS Windows Server Performance Team
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:
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:
SC.exe can be used to query the current trigger-start configuration of a service:
C:\Windows\system32>sc qtriggerinfo w32time[SC] QueryServiceConfig2 SUCCESSSERVICE_NAME: w32timeSTART SERVICE DOMAIN JOINED STATUS: 1ce20aba-9851-4421-9430-1ddeb766e809 [DOMAIN JOINED]STOP SERVICE 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