IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
So now that you are in the loop on the XPERF greatness, let’s look at a real world example of how XPERF can help us optimize boot
(For those of you that missed the XPERF memo, go back and read Mark’s post)
When we first started looking at this client laptop, he was getting to a usable desktop in about 2 minutes. Not bad right? But not great either.
So we took a trace.
For those of you that are curious, the syntax we used to gather the trace is as follows:
xbootmgr -trace boot -traceFlags Latency+DISPATCHER -postBootDelay 120 -stackWalk Profile+ProcessCreate+CSwitch+ReadyThread+Mark+SyscallEnter+ThreadCreate
Note: Notice that we have -stackwalk as one of our switches.
Recall, stackwalking allows us to review modules and function calls in our trace, if needed. Refer to the links in Mark’s blog for instructions on setting up and configure symbols, if needed. Since I have -stackwalk as one of my parameters, before gathering a trace on an x64 bit machine, I must first disable the paging executive as part of the kernel is paged out. This is easy to do, but it does require a reboot. Simply run the following command from an administrative command prompt and you’re good to go:
Reg.exe add “HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management” -v DisablePagingExecutive -d 0x1 -t REG_DWORD -f
After gathering our trace, we next opened it in Performance Analyzer. For those of you new to this, Performance Analyzer (aka xperfview) is the tool we use to analyze XPERF traces. It is installed with the Windows Performance Toolkit which is a part of the Windows SDK. See the previous link for more information.
One of the first things I do is open System Configuration by clicking on the Trace menu and selecting System Configuration. I do this just to see what I’m dealing with. For customer privacy reasons, I have
removed the first and second line containing the Computer Name and Domain Name from my screen shot:
I can see from here that the client is running Windows 7 Professional SP1 (as indicated by the 6.1 OS version) along with lots of other potentially useful information. Make sure to check it out for yourself. My above screen shot is from the General tab, which is one of many tabs available:
After a cursory glance at the default graphs, including the Boot Phases graph that shows the ~ 2 minute time to reach a useable desktop:
I decide to focus on services. Just like in Mark’s example trace in his blog, some services quickly jump out:
Namely, it looks like NetTcpPortSharing service is causing ~ a 30 second delay during startup while we wait for it to start before NlaSvc starts. Then the NetPipeActivator service is causing a similar delay. Also, why is NlaSvc taking nearly 20 seconds to start?
Let’s clean this up a bit by changing the NetworkList service from Manual to Automatic and take another trace. After popping open the trace, we already know these changes have helped as we are down to a usable
desktop in ~ 99 seconds.
We again scroll down to services, and see the following:
We still have some room for improvement. We move on to disabling the NetTcpPortSharing and NetPipeActivator services. For those of you that are not aware, these are .Net Framework 4.0 services related to .Net
development. This user does not do any .Net development so we figured we’re safe to disable these and alert the user we have done so (just in case). We also have them disabled by default on our Microsoft internal image. After disabling these services, we take another trace, and we again see improvement. We reach a usable desktop in ~ 80 seconds.
We again scroll down to services. This is more along the lines of what we like to see. We don’t like to see a lot of what we call “stair stepping”. We still have a little of that going on and suspect that some of this will be cleared up with the application of the Symantec SEP RU6MP3 update mentioned here.
We went on to take traces of some additional machines and confirmed we were seeing similar delays across the board. Just as easy at that and in about 30 minutes, we reduced our boot time to a usable desktop from 120 seconds to ~ 80 seconds. How ’bout that? 🙂 If you experience a similar delay with NlaSvc, rather than change the Network List service to start automatically, try applying the following hotfix, which should correct this problem:
Delay occurs when you log on to a domain from a computer that is running Windows 7 or Windows Server 2008 R2
(Note: We’re still waiting to hear what impact the Symantec update has on the clients and suspect that the 80 second timeframe to a usable desktop will be further reduced.)
~ Charity Shelbourne