Becoming an Xperf Xpert Part 4: What Did the WDIService Host Ever Do To You?

Hey y’all, Mark here again with another real world WDRAP (Windows
Desktop Risk Assessment Program) case. I’ll be spending 6 of my next 8 weeks performing WDRAPs, and it seems these blogs are helping my customers look deeper into Windows client performance. Imagine how many skeletons we can pull out of your desktop closet
(don’t worry they are friendly skeletons). Talk to your TAM today to get a WDRAP scheduled.

In the past,
I briefly talked about using the XPERF Services pane and on which to focus, but my guidance lacked clear and concise direction. So let me take another swing at this. First, install XPERF and pull up the services pane. Go back to my
original blog if you’re just getting started with XPERF.

In the services pane, you’ll want to look for things that are taking a long time to start or things that seem abnormal. How would you ever know what is abnormal if you’ve never done this before? Below is a sample trace that I would consider normal.
Notice a few things. First, at the very top there is a service there called “AutoStart.” That’s not actually a service. “AutoStart” is a heading, and any services that are beneath it are set to start type “Automatic”. Parts of the boot process will not begin
until the AutoStart group has completely finished. Also evident in this trace is that the SLInstall service is sort of holding up things for us. As soon as SLInstall finished, a bunch of other services such as W32Time, SessionEnv and Browser all start around
the 24 second mark. Determining why this service is taking so long to start, or even moving it to a “Automatic (Delayed Start)” might speed things up, but that’s not what this blog post is about. Instead, I would also say this trace is good enough or “normal”
looking.

Now, let’s take a look at a trace that is “abnormal”.
Yikes! I believe the technical term for this is behavior is “all jacked up”. So what is going on with the WDIServiceHost? Has it gone crazy? What does this thing even do? Since I’ve never heard of it I probably don’t need it.

Actually, the WDIServiceHost is used for built in Windows diagnostics. This includes things such as, disk diagnostics that utilize SMART and reports back disk health through the storage driver. SMART, through the WDIServiceHost will notify you when your disk
is going to fail and remind you to backup. WDIServiceHost is also used for network diagnostics and troubleshooting when various related networking problems arise. Another function of WDIServiceHost is resource exhaustion prevention such as memory leak diagnosis.
Finally, it’s used for performance diagnosis around, start up, shutdown, standby/resume and system responsiveness. Based on certain timing thresholds Windows will detect problems, log them in the Event Log, which can provide resolutions and walkthroughs to
attempt to fix the problem. Fundamentally, WDIServiceHost is a good thing, so we should not accuse it of being the source of our problem. Rather, something is interfering with WDIServiceHost, causing it problems as it attempts to start. For more information
on these types of Windows inner workings pick up the Windows
Internals book. There is no better technical depth, and the book has also been known to cure mild cases of insomnia so that’s a bonus.

Time to get to the bottom of this. Most times I’ve seen this type of behavior with a service startup in a customer environment, it has been because someone locked down the image a little bit too tight (or the admin had too much time on their hands). They’ve
usually removed the required permissions for the service. First let’s see what service this account is running under by going to the Services Snapin.
Generally this part is not changed but they’ve actually removed this account from the “Profile System Performance” User Rights Assignment. To check launch the Group Policy Management Council (gpedit.msc). Drill down to Computer Configuration, Windows Settings,
Security Settings, Local Policies, User Rights Assignment. This is what you might see.
The system has been secured so the OS can’t even get in the way to help. Alright, so now we need correct the permissions. In this case, you’ll want to add back the “NT Service\WDIServiceHost”. It should look like this:

 
After rebooting we took another trace and verified that we were back to “normal”. Now you might be asking yourself, how someone gets themselves into this type of situation. This is generally how the conversation goes when someone has changed the defaults on
something without knowing the consequences.

Mark: Why did you guys remove this built-in service account from this user rights assignment?

Customer: It’s a security vulnerability.

Mark: What is the vulnerability?

Customer: I read that it was not needed in this lockdown guide.

Mark: Which lockdown guide?

Customer: I read it on some Internet site.

Mark: Who wrote it?

Customer: Some guy

Mark: So you removed a built in service account’s default permissions because some guy on the internet told you that you didn’t need it?

Customer:…….. (doing the mental math on this statement)

Mark: Boom lawyered!

OK, they all don’t go like this but honestly some do. I can’t tell you how many times I’ve had customers show me incorrect information on web sites, forum posts or anywhere else. Microsoft has recommend security settings that you can find at, http://technet.microsoft.com/en-us/solutionaccelerators/cc835245.aspx so
please don’t just make changes without understanding the impact. A little bit of testing, might help as well.