- SmartDeploy: Rethinking software deployment to remote workers in times of a pandemic - Thu, Jul 30 2020
- Outlook attachments now blocked in Office 365 - Tue, Nov 19 2019
- PolicyPak MDM Edition: Group Policy and more for BYOD - Tue, Oct 29 2019
Rebooting a computer can be so painful! Watching (and waiting) for computer settings to be applied, counting the minutes as you are told to “Please wait…”. Somewhere between your lightning fast initial install and your current production state, something as slowed you down. To find out what, let’s create a trace using the Windows Performance Recorder.
You are going to need either a production machine that you can break or you are going to need to create a test machine that closely mimics your production environment. We are going to be editing services and disabling processes to fine tune our machines.
So do you have a “production” machine that you can mess up now? Great! Install WPT on it and then configure the machine to automatically logon. If needed, we covered both of these steps in Part 1 and 2. Restart once to ensure that your automatic administrative logon works. Launch the Windows Performance Recorder (WPR) – change the Performance scenario to Reboot and the iterations to 1. Press start, save and name your trace.
Windows Performance Recorder - Creating a trace
After the machine has rebooted, compiled, and saved the trace, open it from your administrative machine. Expand the System Activity center and expand the Boot Phases graph.
Just for reference, here is how our baseline looked:
Notice how short the Winlogon phase is, about 15 seconds in duration.
Here is a screenshot of our slow production machine:
Hovering over Winlogon shows us that it took 57 seconds on the production machine.
Not only was the Winlogon phase longer, but every single portion of the boot and login process was increased. To figure out why, we will start with our system services. From the Graph Explorer, add in Services Graph under the Boot Phases graph.
Normal services in our trace
This graph can be a little tricky to read at first. Each service has a unique color. The services above are normal as their duration is extremely small. A normal service is supposed to start and report back it was started. If it does anything else, it should do that with a separate process and not hold up any additional services.
If we scroll down our services graph, we begin to see something weird:
Abnormal services in our trace
Notice how the UevAgentService has an elongated duration (just over 5 seconds). You will also notice that right after the UevAgentService finishes, a bunch of other services fire off in rapid succession.
Looking through Microsoft’s Root Causes for Slow Boots and Logins, I don’t find any explanations on UE-V. Next, I opened the Service management console to take a look at the startup type. As suspected, it is set to Automatic:
UE-V Service Properties
Because our environment uses UE-V as a way of backing up user settings for programs, I am able to change the startup type to Automatic (Delayed Startup).
One final explanation about services and the duration graph. In the picture below, notice the WPDBusEnum service.
The WPDBusEnum service expanded
The WPDBusEnum service does not have a solid shade throughout the duration. While it looks like a 3 minute service, expanding it reveals two separate values (and a much shorter duration).
Wrapping up, WPT allows us to see some incredible details. While our sample machine didn’t have a huge host of problems, we were able to save 5 seconds from every startup. In our final post, we are going to look at the impact of Group Policy on our startup.
