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.
Until next time!
In our case, we'd controlled that user rights assignment setting to 'add a domain security group' to the default list of names so that members of the group (service accounts and tools) 'could' access the performance data. Along came devices with “NT Service\WDIServiceHost” (seemingly out of the blue) and we ran into the issue as well. Easy solution of course, just add “NT Service\WDIServiceHost” to our controlling GPO. We love the SCM tool noted in the link!!! Download today folks.
Glad you were able to root cause that yourself. And yes that Security Compliance Manager is really sweet. I point people to it all the time.
Another neat post .. thanks Mark! I was wondering if it is possible to actually pinpoint a group policy or file starting one particular service..?
I'm not totally sure what you mean. You have a service starting up and you don't know where it's coming from? You could check blogs.technet.com/.../becoming-an-xperf-xpert-part-2-long-running-logon-scripts-inconceivable.aspx which uses the process to figure out what's starting where. You could try and use that.
Thank you for your response.. appreciate it!
I realized later that it might be difficult to understand what I meant. Trying again.. :
We are having a problem with a service (actually server service) which starts on all clients automatically. That is not intended. In order to find out who or what is starting the service I started using Xperf. Xperf is showing us that the server service is started in the same period as all GPO's are applied. So great I thought. It's a gpo! Normally that is not a problem - but we are having a large number of policies configured which makes it less efficient to go through all those policies and look for the one setting enabling this service. So here my question: Is it possible to trace a name of a policy or file to a start of a service..?
Hope that was better to understand..
Too many group polices! Sounds like you guys need a GPO Health Check. First I would run gpresult.exe /v to figure out what policies are being applied. But to answer your question, you can find out more GPO info through Xperf, sounds like a post I should write. If you right click down in "Generic Events" and select Summery Table, there will be a provider called "Microsoft-Windows-GroupPolicy" You should then see which policy is being applied at what time and narrow down to the time the service is starting. You can also get this info out of the Group Policy event logs.
I need to do this exact same thing, except I cannot add a user to the list in "Profile system performance Properties" - it is greyed out even when logged in as a domain admin or to the local computer administrator account. What could be locking it up, a GPO? If so, where in Group Policy (controlled on DC) do I need to look? Also, I cannot add the NT SERVICE\WpiServiceHost via GPO because the server will not validate that name. I'm stuck!
Additional detail: endpoint is a Windows 7 machine, server is Windows Server 2003.
Try running this on the host to see which policy is applying that setting.