Windows On/Off Transitions Solutions Guide-Boot Transition

Run command as below for boot data collect:

xbootmgr -trace boot -numRuns 3 -resultPath "C:\Xboot\logon automatically\with" -postBootDelay 180 -traceFlags latency+dispatcher -stackWalk Profile+CSwitch+ReadyThread

Then generate summary result from the result that get from previous command:

    xperf -i xx.etl -o summary.xml -a boot

Detailed introduction on Boot Transition show as below:

BootTransition

Operating system initialization anddevice and driver initialization involve a lot of code and complicatedinteraction. Because system resources are taxed during boot, reducing resourceusage as much as possible is critical to eliminate bottlenecks and improve performance.

The boot transition can be divided intofour high-level phases that are shown in Figure 2. A description of eachphase is given, followed by a walkthrough of boot analysis.

Figure 2. High-level phases of the boot transition

Boot Transition: BIOSInitialization Phase

What Happens in This Phase

Duringthe BIOSInitializationphase,the platform firmware identifies and initializes hardware devices, and thenruns a power-on self-test (POST). The POST process ends when the BIOS detects avalid system disk, reads the master boot record (MBR), and starts Bootmgr.exe.Bootmgr.exe finds and starts Winload.exe on the Windows boot partition, whichbegins the OSLoader phase.

Visual Cues

The BIOS splash screens and any POST-related messages appear duringBIOSinitialization.

BootTransition: The OSLoader Phase

What Happens in This Phase

During the OSLoaderphase, the Windows loader binary (Winload.exe) loadsessential system drivers that are required to read minimal data from the diskand initializes the system to the point where the Windows kernel can beginexecution. When the kernel starts to run, the loader loads into memory thesystem registry hive and additional drivers that are markedas BOOT_START.

Visual Cues

This phase begins approximately when theBIOS splash and diagnostic screens are cleared and ends approximately when the“Loading Windows” splash screen appears.

Boot Transition: The MainPathBoot Phase

What Happens in This Phase

During the MainPathBoot phase, most ofthe operating system work occurs. This phase involves kernel initialization,Plug and Play activity, service start, logon, and Explorer (desktop)initialization. To simplify analysis, we divide the MainPathBoot phase intofour subphases, as Figure 3 shows. Each subphase has unique characteristicsand performance vulnerabilities.

Visual Cues

Visually, the MainPathBoot phase beginswhen the “Starting Windows” splash screen appears and lasts until the desktopappears. If auto-logon is not enabled, the time that elapses while the logonscreen is displayed affects the measured boot time in a trace.

Figure 3. The MainPathBoot subphases

MainPathBoot Phase: PreSMSSSubphase

What Happens in This Subphase

The PreSMSS subphase begins when thekernel is invoked. During this subphase, the kernel initializes data structuresand components. It also starts the PnP manager, which initializes theBOOT_START drivers that were loaded during the OSLoader phase.

When the PnP manager detects a device,it loads and initializes the device’s drivers in the following sequence:

1.    Detectsa device.

2.    Loadsthe drivers into memory and validates the driver signature.

3.    Callsthe DriverEntry function of thedevice driver. The driver code executes.

4.    Sendsan IRP_MN_START_DEVICE I/O request packet (IRP) to the driver, which notifiesthe driver to start the device. The driver code executes.

5.    Sendsthe IRP_MN_QUERY_DEVICE_RELATIONS IRP to the driver to enumerate any childdevices. The driver code executes.

 

The PnP manager repeats these steps foreach enumerated child device. It continues to iterate through child devices untilit has enumerated and initialized the full device tree.

Visual Cues

PreSMSS begins approximately when the “Loading Windows” splashscreen appears. There are no explicit visual cues for the end of PreSMSS.

MainPathBoot Phase: SMSSInitSubphase

What Happens in This Subphase

The SMSSInit subphase begins when thekernel passes control to the session manager process (Smss.exe). During this subphase,the system initializes the registry, loads and starts the devices and drivers thatare not marked BOOT_START, and starts the subsystem processes. SMSSInit endswhen control is passed to Winlogon.exe.

Visual Cues

There are no explicit visual cues for thestart of SMSSInit, but the blank screen that appears between the splash screenand the logon screen is part of SMSSInit. It ends before the logon screen appears.

MainPathBoot Phase: WinLogonInitSubphase

What Happens in This Subphase

The WinLogonInit subphase begins whenSMSSInit completes and starts Winlogon.exe. During WinLogonInit, the user logonscreen appears, the service control manager starts services, and Group Policyscripts run. WinLogonInit ends when the Explorer process starts.

Visual Cues

WinLogonInit begins shortly before thelogon screen appears. It ends just before the desktop appears for the firsttime.

MainPathBoot Phase: ExplorerInitSubphase

What Happens in This Subphase

The ExplorerInit subphase begins when Explorer.exestarts. During ExplorerInit, the system creates the desktop window manager (DWM)process, which initializes the desktop and displays it for the first time.

This phase is CPU intensive. Theinitialization of DWM and desktop occurs in the foreground, while in thebackground the service control manager (SCM) starts services and the memorymanager prefetches code and data. On most systems ExplorerInit is CPU bound,and timing issues are likely the result of a simple resource bottleneck.

Visual Cues

ExplorerInit begins just before thedesktop appears for the first time. There is no clear visual cue to indicate theend of ExplorerInit.

Boot Transition: The PostBoot Phase

What Happens in This Phase

The PostBoot phase includes allbackground activity that occurs after the desktop is ready. The user caninteract with the desktop, but the system might still be starting services,tray icons, and application code in the background. This phase is consideredcomplete when Xperf data indicates that background activity has dropped to a reasonablyidle level.

Specifically, Xperf samples the systemevery 100 ms during the PostBoot phase. If the system is 80-percent ormore idle (excluding low-priority CPU and disk activity) at the time of thesample, Xperf considers the system to be “idle” for that 100‑ms interval. Thephase persists until the system accumulates 10 seconds of idle time.

Note: When youreview traces and report timing results, you should subtract the 10‑second idletime that accumulated during PostBoot to determine total boot time. Busy timein PostBoot counts toward the total, but the mandatory 10 seconds of idle time doesnot. In this paper, the idle time is subtracted from the timing data.

The PostBoot phase can end while the diskis busy with low-priority activity. Therefore, the disk activity LED is not agood indicator of phase completion.

Visual Cues

There are no explicit visual cues for PostBoot. The phase beginsafter the user’s desktop appears and ends after satisfying the 10-second metricthat was explained earlier.

BootTransition Analysis: Capturing Traces

The first step in boot transition analysis is to capture a trace byusing the Xbootmgr tool. As mentioned earlier, Xbootmgr options control thetest environment and the level of detail in the trace.

To obtain a list of Xbootmgr commands, type the following command inan elevated command prompt:

Xbootmgr –help

 

 

For complete information about Xbootmgr options, see “On/OffTransition Trace Capture Tool Reference” on the MSDN® Web site.

“Timing Traces and Analysis Traces” earlier in this paper explainsthe difference between timing and analysis traces. Consider an analysis boottrace as an example. From an administrative command prompt, enter the followingcommand:

xbootmgr -trace boot -numRuns 3 -resultPath %systemdrive%\traces-postBootDelay 180 -traceFlags latency+dispatcher -stackWalkProfile+CSwitch+ReadyThread -prepsystem

 

In response, the following events occur:

·        The test system reboots within 5 secondsafter you press ENTER.

·        The -prepSystem option causes the Windows prefetcher to optimize itselfby booting the system several times. A status dialog box appears during eachboot to inform you of the current progress.

·        The system restarts again, and Xbootmgrtakes three traces during the boot process. It writes the traces to the folder thatwas specified in the –resultPath option—inthis case, the Traces folder on the system drive.

BootTransition Analysis: Processing Traces

The Xperf.exe and Xperfview.exe tools in WPT can help you analyzethe boot transition performance data. Xperf creates summary files forsimplified analysis, and Xperfview displays trace data in graphical form.

For details about Xperf and Xperfview, see the “Windows PerformanceAnalyzer Command Line Reference” on MSDN.

XMLSummary

To generate an XML summary of the boot trace, use the -a boot action with Xperf. For example,the following command takes as input the Trace.etl file and generates the Summary.xmloutput file:

xperf -i trace.etl -o summary.xml -a boot

 

 

It is easiest to view the XML file in a reader that lets youcollapse and expand XML nodes dynamically. In this paper, we use InternetExplorer to examine the Summary.xml file.

Open the Summary.xml file in Microsoft® Internet Explorer. If thegold Information Bar appears, click it and then click Allow blocked content to enable dynamic node expansion.

You should see XML output that resembles Figure 4.

Figure 4. Summary.xml output viewed in Internet Explorer

When you examine the XML report, remember the following:

·        The time unit appears in the timeFormat line at the top of the XMLsummary report. In Figure 4, the time unit is msec, for milliseconds.

·        Most intervals and operationsare described by a trio of start time, end time, and lifetime. If a process startsduring the trace and is still running at the end of the trace, both the endtime and the lifetime appear as -1.

Summariesof Plug and Play and Services Activity

Many boot performanceproblems are caused by Plug and Play devices and drivers or services. One wayto analyze this data is to create a scenario-specific, comma-separated value (.csv)summary, which you can read and manipulate by using Microsoft Excel® andsimilar tools. With a few exceptions, this paper does not use .csv files. Formore information on how to generate these summaries, see Appendix C.

BootTransition Analysis: Analyzing Traces

The first step in any boot transition performance analysis is tocompare overall timing metrics of a modified system to a baseline system.

Beginning with the Summary.xml file that appeared earlier in Figure 4,we collapsed most of the nodes so that the high-level summary nodes are visible.Figure 5 shows the high-level entries in the boot node.

Figure 5. Summary.xml output with nodes collapsed

The following are the entries in the boot node:

·        ProcessSummary contains overviewperformance data about the processes that run during the boot transition andacts as a parent node for process timing data.

·        Timing summarizes transition timeperformance data and acts as a parent node for most of the boot transitionphase summary data.

·        Services contains overview performancedata for services that the SCM starts during boot and is a parent node forservice-specific data.

·        PNP is a parent node for Plug and Play driverand device performance data such as enumeration and start times.

·        GroupPolicy is a parent node for GroupPolicy script performance data, if any.

 

To begin to analyze boot performance, you should determine theoverall boot time and the relative phasetimes for the phases that were described earlier in this paper for both thebaseline and modified trace.

If you expand the timingnode, you should see output that resembles Figure 6.

Figure 6. Summary.xml output with expanded timing node

In the preceding data, the bootDoneViaExplorerkey shows the duration of the boot (in milliseconds) until the start of Explorer.exe.In this case, it is 24.773 seconds. As mentioned earlier in the “BootTransition: Post Boot Phase” section, the PostBoot time is measured by using aspecial metric. The bootDoneViaExplorerfigure excludes the PostBoot time.

The bootDoneViaPostBoot key,which appears immediately following the bootDoneViaExplorerkey, is the length of the boot transition including PostBoot. This metric representsthe total time of a boot transition. In Figure 6, the total boot time is40.973 seconds, or30.973 seconds if the 10 seconds of PostBoot wait time issubtracted. Over 30 seconds for a boot is not especially good. This systemcan be optimized to boot more quickly. If you have taken a baseline trace inaddition to a trace on a modified system, compare the bootDoneViaPostBoot values minus the 10‑second wait to determinethe effects of system modifications on performance.

If the results for thebaseline and modified systems differ significantly—that is, by several seconds—thenext step is to examine the individual phase times to determine whether theincrease occurred in one specific phase. By comparing interval durationsbetween the modified and baseline systems, you can more deeply examineperformance issues.

The main timing nodecontains OSLoader phase timing data. Timing data for other phases appears inthe interval subnodes under the timing node. Each interval node contains the name of the interval, a start time, anend time, and a duration. The PostExplorerPeriod node contains the PostBoottime.

The TraceTail interval containsthe rest of the trace data that was recorded after the 10-second PostBoot criterionwas fulfilled, so you can generally ignore it.

On correctly trained systems, boot performance is generallyconsistent. However, occasionally times vary from run to run on identicalmachines because of nondeterministic components of the boot process. Toillustrate a comparison of boot and phase times with variance, we generatedanother trace on the machine with no changes. The resulting Summary.xml file isshown in Figure 7.

Figure 7. Summary.xml output for second boot

Table 5 compares the boot and phase times for the two trace runs,which are named Run 1 and Run 2. The boot plan was optimized before the traceswere run.

Table 5. Boot and Phase Times for Two Boot Traces on the Same Hardware

Phase or subphase	Run 1	Run 2	Difference	%Delta
OSLoader	1926	1926	0	0
PreSMSS	10753	10642	111	1.0%
SMSSInit	5461	5601	-140	-2.6%
WinLogonInit	3697	3947	-250	-6.8%
ExplorerInit	4861	3408	1453	29.9%
PostBoot	16200	17100	-900	-5.6%
BootDoneViaExplorer	24773	23599	1174	4.7%
Total Boot	30973	30699	274	0.7%

 

As Table 5 shows, large changes that occur in individual phasescan have only a small effect on boot. The data in Table 5 shows that datawas likely prefetched during ExplorerInit in Run 1, but was prefetched duringthe PostBoot phase in Run 2. This inflated the BootDoneViaExplorer timeand ExplorerInit phase time fairly significantly, but overall boot time variedby less than 1 percent.

The best way to determine whether a system modification has adistinguishable effect on boot is to run several traces. Another approach is toexamine other nodes of the XML output such as individual phase nodes, the pnp node, or the services node.

Boot is a resource-intensive process, and contention for resourcesis common. The introduction of new drivers or services can increase resourcecontention and therefore prolong boot times. If you notice that one particularphase has an increased time, you can expand its timing node to view CPU anddisk statistics. Figure 8 shows the expansion of the PreSMSS interval.

Figure 8. Summary.xml with expanded PreSMSS interval node

The following are the subnodes in the PreSMSS interval:

·        perProcess lists all processes in orderfrom highest CPU usage to lowest CPU usage.

·        perPriority lists the CPU priorities andthe time that the CPU spent at each priority.

·        diskIO contains disk metrics such as thenumber of bytes that were read and written, the number of read and writeoperations, and how long was spent performing disk reads and writes. It alsoincludes totals for each of these categories along with additional statistics.It further separates disk activity to byFileand byExtension.

 

These disk and CPU statistics should provide a good indication of wheretime and resources are being spent. The following are several points that youshould note:

·        The file that is named “Unknown(0x0)” dominates disk read I/O during most boot phases. This represents theboot prefetcher while it reads data into memory. You can usually ignore thisfile.

·        Data that was prefetched for aparticular process does not appear in the statistics for that process name inthe PreSMSS interval. To obtain complete disk metrics for a particular process,use the FILE_IO trace flag when you capture a boot trace and then examine theFile I/O graph in Xperfview to see the complete disk metrics(reads/writes/flushes) for that process.

·        The disk in Figure 8 spentmore than 7.5 seconds servicing prefetcher disk reads. The CPU spent almost thesame time in the idle thread, waiting on the diskIO read operations tocomplete.

·        Devices and services that causesystem waits and delays are difficult to detect through these metrics. Oneindication that a system extension introduces delays is an increase in CPU idletime without a corresponding increase in disk I/O time.

Boot Transition Analysis: PhasePerformance Vulnerabilities and Analysis

The next step is to digdeeper into problematic scenarios or phases that present performance issues.This section describes each phase and identifies any performancevulnerabilities.

For a list of bestpractices related to on/off transitions, see “Windows On/Off TransitionsSolutions Guide” on the WHDC Web site.

BIOSInitialization Performance Vulnerabilities

You must manually determine whether BIOSInitializationconsumes too much time. One performance problem that is typically associatedwith BIOSInitialization is the time that is required for extended memory tests.Fast POST settings skip these tests and therefore reduce the time that is spentin BIOSInitialization. To minimize BIOS effects on boottransition, configure the system BIOS for fast POST, if this is possible.

OSLoader Performance Vulnerabilities

The OSLoader phase is primarily I/O-bound. Faster disks generallylead to a faster OSLoader phase.

During the OSLoader phase of the boot transition, Windows verifies thesignatures on BOOT_START drivers. Drivers can be signed in one of two ways:catalog signing (which includes the signature in a catalog file) or embeddedsigning (which embeds the signature in the driver file).

BOOT_START drivers that are catalog-signed can cause 1-second to 3‑seconddelays, depending on the hard disk speed. To verify a catalog-signed file,Windows must locate the catalog files on disk and load them, which reduces performance.This is a significant delay when you consider that the OSLoader phase isgenerally less than 3 seconds long.

The catalog load penalty does not apply for each catalog-signeddriver. Windows loads the catalog files only one time. However, this shows acommon theme in boot performance analysis: one badly behaving component on thecritical boot path can introduce significant system-wide delays.

OSLoaderPerformance Analysis

To obtain a list of the BOOT_START drivers, type the followingcommands:

xperf –i trace.etl –o trace.txt –a dumper

findstr /C:"I-DCStart" trace.txt

 

Ensure that all drivers in this list are embedded-signed. Use SignTool.exefrom the Windows Driver Kit (WDK) to verify the embedded signatures,substituting the appropriate driver name. For example:

signtool verify /v driver.sys

 

 

The OSLoader phase occurs early in the boot process. In this earlystage of boot, WPT has no adequate infrastructure to track CPU or disk usage. Therefore,OSLoader does not have its own intervalnode with CPU and disk information. Instead, its duration appears in the timing node, as highlighted in Figure 9on the following page.

Figure 9. Location of osLoaderDuration in Summary.xml

PreSMSSPerformance Vulnerabilities

Devices and drivers can affectthe time that is required for Plug and Play enumeration and initialization duringthe PreSMSS subphase. Some devices and drivers require lengthy initializationperiods because they spend a long time processing the IRP_MN_QUERY_DEVICE_RELATIONSand IRP_MN_START_DEVICEIRPs.

Long delays during IRP processing can cause significant bootperformance degradations. The design of the PnP manager enables groups ofdevices and associated drivers to begin loading and initialization in parallel.However, all IRP_MN_START_DEVICE and IRP_MN_QUERY_DEVICE_RELATIONS requests ina particular device node must be complete before the PnP manager can traverseto a subsequent node. In other words, each root device must start beforedevices that are attached to it can start.

Therefore, a reduction in the initialization time for a singledriver or device might not reduce the overall boot time by the same amount,depending on the length of the initialization delay and whether the delayblocked node traversal. Regardless, it is always a good practice to reduceinitialization time because the degree of parallelism within this subphasevaries with each system configuration. Small savings on one system couldrepresent a significant improvement on another.

Instead of processing IRP_MN_START_DEVICE and IRP_MN_QUERY_DEVICE_RELATIONSdirectly in a dispatch routine, a driver should return STATUS_PENDING so thatthe PnP manager can process other requests while the driver processes the IRP. Alldrivers should return STATUS_PENDING if they can to increase parallelism andreduce boot time.

As a demonstration, we took sample runs with and without pending theIRPs in a customized driver. The driver in these tests was named Ramdisk, andthe data appears in Table 6.

Table 6. Effect of Pending IRPs on Driver Initialization andBoot Times (in milliseconds)

	PreSMSS time	Plug and Play system start time	Ramdisk load time	Ramdisk start time	Ramdisk query relations time	Total boot time	Differ-ence
No Pended IRPs	26636	20813	9214	3000	3000	44923	Not applicable
Pend Start; do not pend Relations	17919	13007	0	3000	3000	36839	8084
Pend Start and Relations	17294	12343	0	3000	3000	35409	9514

 

As the data in Table 6 shows, pending IRPs can improve bootperformance significantly.

PreSMSSPerformance Analysis

The phase time for PreSMSS appears in its interval node, as highlighted in Figure 10. During PreSMSS,the boot Plug and Play and system Plug and Play initialization sequences occur.The pnp node summarizes the Plug andPlay data in phase nodes that are namedbootStart and systemStart. These are also highlighted in Figure 10.

Figure 10. Location of PreSMSS duration and Plug and Play phasedurations
                  in Summary.xml

Boot and system Plug and Play analysis is a detailed process. Forstep-by-step instructions and the details about the effects of pending on boottransition performance, see “Identifying Boot and System Plug and Play Issues”in Appendix A.

SMSSInit Performance Vulnerabilities

Video drivers are a common source of performance problems in the SMSSInitsubphase. The video driver must be initialized first in the system session andthen in the user session. Reduction of video driver initialization time leadsto a direct wall-clock reduction in boot time.

Initialization in the user session is typically much faster than inthe system session because Windows performs common initialization tasks duringthe system session. You can infer the start times and end times of theseinitialization operations from the events that appear in the raw dump of thetrace. Measuring these values is important when you evaluate an updated videodriver for boot performance.

SMSSInitPerformance Analysis

The time for the SMSSInit subphase appears its interval node, as highlighted in Figure 11.

Figure 11. Location of SMSSInit duration in Summary.xml

Calculating the SystemSession Video Initialization Time

No specific events are associated with the system session videoinitialization process, but you can infer the time that is required by calculatingthe time difference between the completion of the first Csrss.exe startup by Smss.exeand the startup of Wininit.exe by Smss.exe.

The examples that follow use a .csv file. For information aboutcreating a .csv file, see Appendix C.

To calculate the video driver initialization time in the systemsession

1.       Filter out all SMSS events of interest:

findstr.exe /C:"Microsoft-Windows-Subsys-SMSS"trace.csv > trace.csv.filtered

findstr.exe /i “csrss wininit”trace.csv.filtered

 

2.    Locate the end of thefirst start of Csrss.exe:

·        Event type is in the firstcolumn:
Microsoft-Windows-Subsys-SMSS/smss:ExecuteImage/Stop

·        The timestamp is in the secondcolumn.

·        The process name is in thesixth column.

Note that two starts of Csrss.exe are expected, one per session, withthe first corresponding to the system session.

3.    Locate the beginning of Wininit.exestart:

·        Microsoft-Windows-Subsys-SMSS/smss:ExecuteImage/Start

4.    To determine the time thatis required for system session video initialization, calculate the differencebetween these two timestamps.

Calculating the UserSession Video Initialization Time

You can infer the time that the user session video initializationprocess requires by noting when the second Csrss.exe startup by Smss.exe iscomplete and when the startup of Winlogon.exe by Smss.exe begins.

To calculate the video driver initialization time in the usersession

1.    Filter out all SMSSevents of interest:

findstr.exe/C:"Microsoft-Windows-Subsys-SMSS" trace.csv > trace.csv.filtered

findstr.exe /i "csrss winlogon"trace.csv.filtered

 

2.    Locate the end of thesecond launch of Csrss.exe.

Note that two launches of Csrss.exe are expected, one per session, withthe second launch corresponding to the system session.

3.    Locate the start of Winlogon.exelaunch:

Microsoft-Windows-Subsys-SMSS/smss:ExecuteImage/Start

4.    To determine the time thatis required for user session video initialization, calculate the differencebetween these two timestamps.

WinLogonInitPerformance Vulnerabilities

Many operations occur in parallel during WinLogonInit. On manysystems, this subphase is CPU bound and has large I/O demands. Good citizenshipfrom the services that start in this phase is critical for optimized boottimes.

Services can declaredependencies or use load order groups to ensure that they start in a specificorder. Windows processes load order groups in serial order. Service initializationdelays in an early load order group block subsequent load order groups and can possiblyblock the boot process .

We created a customized service that is called “Slowsvc” todemonstrate how service initialization delays in early load order groups canaffect boot performance. This service waits for 6 seconds during itsinitialization routine. Table 7 shows the boot and service start times fortwo runs: one run includes Slowsvc in an early load order group, and the otherdoes not.

Table 7. Effects of Service Delays in Early Load Order Groupson Service Start and Boot Times

System	SlowsvcInit time	WinlogonInit time	ExplorerInit time	Total services start time	Total boot time	Boot time reduc­-tion
Slowsvc assigned to an early load order group	6000	7459	1822	10720	32805	Not applicable
Slowsvc not assigned to a load order group	6000	3893	2864	12566	31888	917

 

Long delays during any service initialization can increase the time thatthe boot transition requires. If you can do so, set services to demand start ortrigger start. Demand-start and trigger-start services start after the bootprocess is complete and therefore reduce overall boot time.

The presence of persistent network connections can cause variabledelays in the WinLogonInit subphase. Therefore, to ensure that each run is consistent,we recommend that you delete all persistent network connections before youtest.

If the test machine is connected to a domain that deploys GroupPolicy, test results sometimes show that WinLogonInit requires lots of time.The actual time varies depending on the specifics of the policy or policies.See the groupPolicy node of the Summary.xmlfile to determine the effects of any Group Policy scripts on your boot times.

WinlogonInitPerformance Analysis

As with durations for the other subphases, WinlogonInit subphaseduration appears in the corresponding intervalnode in the Summary.xml file.

The services and groupPolicy nodes in the Summary.xmlfile (which are highlighted in Figure 12) contain the performance data forindividual services and Group Policy scripts, respectively, that execute duringboot.

Figure 12. Location of WinLogonInit duration, Services, andGroupPolicy nodes in
                  Summary.xml

You can find information about service start timing by examining theservices node in the Summary.xmlfile. Each service has its own subnode, and the time that is required for theservice to begin is in the totalTransitionTimeDeltaattribute. Or, you can use the xperf –aservices command or the Xperfview visualization tool to identify services thathave long start delays. For step-by-step instructions on how to analyze serviceinitialization and the effects of load order groups on boot transitionperformance, see “Identifying Service Start Time Issues” in Appendix A.

ExplorerInitPerformance Analysis

The ExplorerInit subphase duration appears in the corresponding interval node in the Summary.xml file.

Applications—such as antivirus programs or application servers—thatare created during service start in this or previous phases can consume CPUresources during ExplorerInit. Some services might not be started yet when ExplorerInitis complete.

Analysis of the operating system activityduring this phase is complex and beyond the scope of this paper.

PostBootPerformance Vulnerabilities

During PostBoot, Windows examines the entries in the various Run and RunOnce keys (Run, RunOnce, RunOnceEx, RunServices,and so on) in the registry and the Startup folder in the file system, and then startsthe listed applications.

To improve performance, the goal for this phase should be to quantifyand then limit the background processing that continues after the desktop isvisible. Such processing includes running startup applications, creating trayicons, and so on.

PostBootPerformance Analysis

The time that is spent in the PostBoot phase appears in the interval node that is named PostExplorerPeriod. The duration ofthis phase is highlighted in Figure 13.

Figure 13. Location of PostBoot duration in Summary.xml

After the PostBoot phase begins, a user can start applications.However, in a controlled test environment for performance analysis, most of thePostBoot time typically involves completion of the loading and initializationof services and applications.

If your test system remains in PostBoot for an extended period, apoorly performing application or service might be preventing the system from becomingidle. Expand the perProcess and diskIO nodes and check whether aparticular application or service uses an excessive amount of CPU or diskresources.

BootTransition: Summary

Users perceive boot time as an important aspect of systemperformance, so it is critical to optimize boot transition performance. Thefollowing is a list of important things to consider:

ü  Use WPT to measure the performance of drivers, applications, andservices during all on/off transitions.

ü  Use Windows Driver Foundation (WDF) to write drivers.

ü  Minimize BIOS initialization time by configuring the system BIOS forfast POST.

ü  Ensure that all BOOT_START drivers are embedded-signed to avoid theperformance cost of checking catalog files.

ü  Mark drivers as BOOT_START only when it is required.

ü  Increase parallelism during device enumeration and startup byreturning STATUS_PENDING for IRP_MN_START_DEVICE andIRP_MN_QUERY_DEVICE_RELATIONS requests.

ü  Ensure that all nonessential services are converted to demand start ortrigger start to make system resources available during boot.

ü  Avoid using load order groups to express service dependencies.

ü  Reduce application resource consumption during PostBoot.

ü  Limit background processing after boot by minimizing the number ofapplications that start from the Runor RunOnce registry keys.

ü  Perform testing in a controlled way, and make comparisons against avalid baseline. Obtain a baseline measurement on a system with as few systemextensions as possible. Add devices, applications, and services one at a time,and test for unacceptable regressions in on/off transition times.

 

For details about these recommendations, see “Windows On/OffTransitions Solutions Guide” on the WHDC Web site.