Ask Premier Field Engineering (PFE) Platforms--The Slow Boot Case of the NetTCPPortSharing and NLA S

   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 times. 

   removed the first and second line containing the Computer Name and Domain Name from my screen shot:
desktop in ~ 99 seconds.
   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.
        (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

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

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

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? <img class="emoji" alt="