This article describes Microsoft Support experiences in troubleshooting boot and logon delays, specifically the root causes. Other related topics include:
The goal of this content is to create awareness among IT administrators, support professionals, and consultants, about the tools, causes, and resolutions for boot and user logon delays. The primary focus is on domain-joined clients and servers. The article
does not pertain to slow boots and logons on consumer desktops in a workgroup, but some of the tools and methods would still apply, such as enabling verbose logging and noting the message and duration where the boot or logon hung.
Edited by: Justin Hall
There is no shortage of root causes for boot and logon delays. Some delays are caused by code-defects in the OS or applications on the computer experiencing slow boot or logon. Other root causes lie with the underlying network, remote servers, or Administrator
Don’t worry about tracking the QFEs for Windows. We’ll be publishing a list of recommended fixes in the near future.
The following sections explain some of the problems that have been seen to date, and how to resolve them.
Boot and logon delays can be caused by applications as innocuous as utilities and applets to mission critical applications. Examples of utilities and applets that can cause boot and logon delays include software that monitors ambient light sensors to dynamically
adjust monitor brightness or applications that mute built-in microphones on laptop computers. Hardware developers are generally diligent about finding such delays and resolving them in later software versions. Hardware developers also identify and report delays
in the core operating system too.
Version 2.8.300 resolves known delays during user logon.
Performance improvements in VirusScan 8.8 over 8.7.
Disabling “process on enable” scans may improve boot and logon performance. The setting is enabled on 8.7. The setting is disabled in version 8.8 but a setting may be persisted by policy. Retry boot and logon with setting disabled if a boot trace shows McShield
consuming sufficient disk or CPU resources or has long execution times in the auto-start base of a boot trace.
Microsoft Application Virtualization (App-V) 4.6
App-V prior to version 4.6 SP1 should have Hotfix 3 (KB 2571168) or later installed. Delay identified by long execution time for SFTLST.EXE in autostart pane of XBOOTMGR trace. Due to WMI dependency,
also install KB 2617858.
Data Protection Manager (DPM) 2010
Scheduled tasks can delay OS startup. Install KB
Forefront Endpoint Protection (FEP) 2010
FEP 2010 with pre-6903 engines may cause boot and logon delays. To check engine version, click Help, and then click About in Forefront Endpoint Protection. Ensure that FEP and other Microsoft security software is configured to receive monthly updates.
Verbose logging enabled by "Turn on logging in Lync" can degrade system performance, especially if beta versions of Lync were installed.
Performance improvements in SEP 12.1
Laptop computers can have an “acoustic mode” BIOS setting, which reduces drive noise by slowing the rotational speed of platters on the drive. Battery life improves but disk throughput is decreased during the i/o intensive boot and logon phases. The point
is to be aware of such settings and configure the laptop depending on whether you need a quieter work environment with longer battery life or faster boot, logon and post logon disk throughput.
Just as software vendors continually improve performance through incremental and milestone updates, hardware vendors improve performance in Bios and Firmware updates, so it’s a good idea to check with your hardware support sites for potential performance
updates then do some testing with XBOOTMGR.
Also, it’s a good idea to run a query on your make and model computer in your
favorite search engine to see if the community has latched onto any make and model specific defects.
Boot and logon performance depends heavily on disk drive speed so you can see performance gains as you transition from 5400 to 7200-rpm drives or to solid state drives (SSD).
Locator, or DCLocator, is the component used by a domain-joined computer to locate domain controllers for computer authentication, user authentication, ldap queries and more. Due to the iterative network I/O generated, operating system boots and user logons
on domain-joined computers enjoy the fastest performance when serviced by a domain controller connected by a fast LAN. Conversely, performance is degraded when boots and logons are serviced by DCs and file servers in in remote Active Directory sites and subnets.
When clients do not use site-optimal domain controllers, profile servers, and application servers, the boot and logon process becomes vulnerable to the following challenges:
A domain-joined client computer may discover a DC in a remote site rather than its own site for the following reasons:
There are also root causes that can prevent clients from connecting to in-site DFS targets including the SYSVOL share on domain controllers. Clients accessing group policy, logon scripts, startup scripts, or paths referenced in executing scripts on remote
DFS shares may result in boot and logon delays.
User logons to W2K8 R2 DCs with XenApp residing RODC-covered sites are slow due to the credential provider making an ADSI call that makes an implicit DsGetDC call which cannot be satisfied by the RODC.
Workaround: ensure that XenApp servers reside in RWDC-covered sites. Citrix has a technical support article on this issue:
Windows Server 2003
Failure to define valid subnet, site and subnet-to-site mapping increases the probability that clients will use a remote-site DC. Check System event logs on DCs for NETLOGON event 5807: “During the past (x) hours there have been (y) connections to this Domain
Controller from client machines whose IP addresses don't map to any of the existing sites in the enterprise.”
Review KB 306602 to determine whether branch-site DCs should continue to register siteless SRV records.
A story: User logons from Windows 7 clients were taking 5 minutes. Enabling verbose status messages revealed that the Group Policy Local Users and Groups client-side extension was taking about 160 seconds to apply. GPRESULT /Z <filename.ext> confirmed that
the client was applying Local Users and Groups Group Policy preferences. A review of the clients NETLOGON.LOG revealed that the client had initially discovered an in-site DC but subsequently issued a second DSGETDC call specifying the /TIMESERV flag. The client
then discovered a remote-site DC advertising the time flag located half-way around the world to source the remainder of policy. Root cause: causes for the logon delay:
Windows Server 2003
Windows Server 2003 DCs auto-register sitefull DNS SRV records for a site covered by an RODC unless the RODC compatibility pack is installed on the Windows Server 2003 DCs. See
Windows Server 2008 R2
Reverse-name lookups in un-mapped sites are slower on Windows Server 2008 R2 DCs compared to Windows Server 2003 and Windows Server 2008. This problem is fixed in Windows 8 Server Beta.
Workaround: ensure that valid subnet; site and subnet-to-site mappings are defined for authenticating computers.
In extreme cases, this condition can cause LDAP queries to run long, exhausting the worker thread pool on DCs
The CTS SBSL team has experienced a number of network-related causes for slow boots and logons. From an operating system perspective, the best network throughput occurs when “up-level” clients (Windows Vista, Windows 7, Windows Server 2008, Windows Server
2008 R2) are communicating with “up-level” servers to take advantage of performance enhancements in the SMB 2.0 protocol.
In some cases it is sufficient to take a network trace that only captures traffic to and from the slow boot or logon computer. In cases where network packets are being dropped, it’s important to take concurrent traces from both the caller and the target
computers, then reconcile whether packets issued by the caller actually made it to the target computer and vice versa. One suggestion when reviewing such traces is identify ports and IP addresses that the caller is using to reach the target computer, then
create display filter that isolate conversations of interest in both traces.
A more comprehensive NETMON 3.4 display capture filter created by Joel Christenson of the Microsoft CTS networking team can be found in the
Feel free to apply that display filter to your slow boot and logon and other network traces. Modify as needed.
Windows Server 2008
Story: Windows 7 clients report intermittent logon delays of 45 to 90 seconds while applying user settings A Network Monitor trace with the display filter “Property.TcpSynRetransmit==1” shows the client issuing multiple SynReTransmits in the “high” ephemeral
port range between ports 49152 and 65535. User logons are fast when randomly serviced by Windows Server 2003 DCs. Root cause for the slow logon occurred because network connectivity over the “high” RPC port range was blocked by intermediate network devices.
Logons serviced by Windows Server 2003 DCs remained “fast” as the connectivity over the “low” RPC port remained unblocked. See
Active Directory and Active Directory Domain Services Port Requirements.
Large collections of 6to4 adapters in Networks in Control Panel delays OS boot until
KB 980486 is installed.
A failure to negotiate opportunistic locking can delay the application of policy and other files from remote servers being read in 2-byte increments until you add the BufferPolicyReads registry setting on Windows Server 2003 and XP clients explained in
<need to figure this out>
Accessing files with long file names or in long paths may generate repetitive SMB transact2 network traffic that can delay the application of computer policy, user policy, user profile load or logon script load until the Infocache registry setting is set
to 10 as specified in KB 834350.
Windows – All versions
Sample experience: Logons to one server take some number of seconds longer than logons on another identical server. Root cause is that server 1 resides in a resource domain whose DNS Server is unable to resolve the DNS name for the profile server, \\<single
label host name>\sharename, to an IP address. The inability to resolve DNS names to home directories, startup scripts, logon scripts or paths referenced in scripts can trigger long boot and logon delays. We recommend that you use fully qualified DNS names
in paths for home directories, user profile, startup and logon scripts as well as paths referenced in those scripts. For example,
file:///public vs. file:///public.
Common DNS blockers include:
A common problem the CTS SBL team sees in XPERF traces is a 30 second delay waiting for the network to start before a user profile is loaded. The problem exists only on Windows 7 and Windows Server 2008 R2 computers. Resolved by installing MS KB
Window 7 clients and Windows Server 2008 R2 servers that receive DHCP addresses using a DHCP relay experience a delay getting IP addresses. Boot delays of 5-30 seconds have been reported. Computer policy may fail to apply until the next refresh interval.
Netlogon event 5719 with extended error “there are currently no logon servers available to service the logon request” in the System event is a partial telltale event. A network trace will show that the client acknowledged the DHCP request but the boot time
firewall policy drops the unicast response from the DHCP relay. By the time the timeout interval expires, the firewall has started and the retry operation succeeds. Resolve by installing
KB 2459530 on DHCP clients
Story: Users logons with cached profiles take 2 minutes to complete. The WINLOGON pane in XPERF shows that the profile service, which loads user profiles and maps home directories, has a long execution (up to 2 minutes). The stack trace in CPU Scheduling
with Ready thread shows the profile service mapping a home directory to a DFS path on the network. The TCP/IP Count Summary TABLE width="99%" time-cloned during the logon delay shows two session resets. A network trace shows the client sending an SMB Dialect
negotiation request which the server never responds to, at which point the client resets the TCP session. No packets are exchanged for 60 seconds until the pattern is repeated for a second 1-minute delay. That the server fails to reply with an SMB dialect
indicates a server side problem. The failure in the netmon trace is consistent with third-party TDI drivers interfering with the network stack. Start by installing the latest TDX.SYS from
KB 961775, and then enable the TdxPrematureConnectIndDisabled registry on the remote server followed by a remote. Remove TDI filter drivers as a last resort.
Windows Vista and Windows Server 2008 and later
User logons from domain-joined W7 clients normally take 30 seconds but intermittently take 8 minutes. XPERF shows that a series of logon scripts called by Group Policy preferences to establish mapped network drives are taking a long time to execute. A network
trace shows clients experiencing slow logons authenticating with a local DC, pulling policy from a local DC but sourcing scripts defined in Group Policy preferences from a remote DC half-way around the world. On the client computer, IPv6 is bound in Network
Connections in Control Panel (NCPA.CPL) but unbound on all DCs (that is, the TCP/IPv6 check box is cleared in the network adapter properties).
Clearing the IPv6 check box does not disable the IPv6 protocol.
Enabling the IPv6 binding in NCPA.CPL and setting disabledcomponents=FFFFFFFF on the Windows 7 client results in consistently fast logons as Group Policy preferences scripts are sourced from the local DC. One change to investigate is whether creating IPv6
subnet and subnet-to-site mappings would have resolved this problem.
Windows 7 clients experiencing slow logons due to the inability to resolve certain IPv6 records to a valid IP address for target computers used in the logon process. A review of the forward lookup zone showed duplicate AAAA records present for each DC in
the client domain. Each DC had a single NIC which was assigned a single IP address. PINGS of current AAAA records would resolve while others would not. Problem resolved by removing an intermediate device on the network which was issuing router advertisements.
Users experience slow logon times. The WINLOGON pane from an XPERF trace shows execution time by GPCLIENT. Similarly, the Generic Events Summary TABLE width="99%" shows large delays in gpclient execution. CPU Scheduling with ready thread summary TABLE width="99%"
reveals that the GPSVC is waiting on GPSCRIPT.EXE to execute scripts. GPSCRIPT in turn is waiting on WSCRIPT.EXE to execute WSH scripts such as .vbs and .js scripts. The File I/O summary TABLE width="99%" reports a 45-second sharing violation encountered while
accessing a script from a remote server. The next action is to identify the source of the file lock.
You could argue that all of the Windows fixes mentioned previously are operating system (OS) bugs, but one point needs to be clear: code fixes for the majority of slow boot and logon root causes in Windows 7 and Windows Server 2008 R2 have long since been
resolved by Service Pack 1 and post Service Pack 1 QFEs but as of (today's date = 2012.04.19) were not installed on the production clients and servers the SBSL team reviewed.
Microsoft Support CTS still gets slow boot and logon calls from deployments running Windows 7 RTM or Windows XP or Windows Server 2003 SP1. Hopefully those deployments are in the minority.
Console logons to Windows 7 and Windows Server 2008 R2 computers with multiple monitors hang at black screen. Resolved by
Windows Servers hosting the domain controller and DNS Server role may hang for nearly 20 minutes and log DNS Event ID 4013 due DNS waiting on Active Directory to replicate before loading DNS zones deadlocked with Active Directory waiting on DNS to load Active
Directory-integrated zones so that it can resolve DC CNAME records to source IP addresses. This problem is primarily caused by configuring DCs to point to itself exclusively or as Primary DNS server. Point to one or more alternate DNS Servers and stage DC
reboots smartly to ensure that DCs being rebooted point to an online DNS Server that can resolve DNS queries for direct replication partners during OS boot. See
KB 2001093 for more information.
SSL-enabled web servers may hang while “applying security policy” for several minutes to several hours due to http<-> crypto deadlock. Another clue: Numerous services that are configured to start automatically on reboot fail to auto-start. Install
KB 2379016 to resolve the problem. Extremely common problem on SSL-enabled Windows Server 2008 servers.
Windows Server 2008 R2 not impacted.
Every other boot is slow on computers configured with more than 96 DPI. Problem resolved by installing
KB 977419 or reducing DPI.
Wake from hibernate is slow on BitLocker-enabled computers unless
KB 2294019 is installed.
Boot and logon delays caused by Group Policy range from:
A good practice would be to profile computer and user policy application times to test the performance impact around the number of policies being applied and various policy settings, especially those that involve Group Policy preferences or drive mappings
or the sourcing of data over the network (such as application installations, remote program execution, and so on). Also, review the network conversion between client servers and policy services to look for inefficiencies and reduce network I/O as much as possible.
A side note, enabling the user environment logging can help to locate which policy takes too much time to execute and load (KB 221833 or
KB 944043 (see the last section about gpsvc.log))
Enabling “Delete cached copies of roaming profiles” policy setting delays logoff as some yet-to-be-identified component in the OS is triggering Windows desktop search to cache settings on behalf of each locally cached profile at logoff. Larger numbers of
cached profiles cause longer logoff delays. Logoff is fast when desktop search is disabled or the policy setting is not applied. Root cause is being investigated.
Enabling “Do not automatically make redirected folders available offline” policy causes delayed logon when offline files have been cached on the client, and redirected folders have been manually pinned to be available offline. Resolve by installing
Windows Server 2003 and later
Enabling “Shutdown: clear virtual memory pagefile” delays OS shutdown due to the workload associated with “clearing” the contents of pagefile.sys and hiberfil.sys. High workload causes longer wait.
Internet Explorer 7
Enabling Internet Explorer branding on computers running Internet Explorer 7 and Internet Explorer 8 may cause a 20-secondlogon delay unless
KB 941158 is installed with the corresponding registry setting.
Installation of unsigned or “package-unaware” printer drivers via Group Policy preferences may result in slow logon. Install fixes
KB 973772 or
Group Policy preferences installation of printer files causes slow first-time logons due to time spent copying a 300-500 MB file over the network, and executing the printer installer. Group Policy preference-based printer drive installation runs synchronously
meaning that the operation must complete before the user logon operation can continue. High workload causes longer wait. Evaluate whether print drivers need to be installed on each unique logon. Install multiuser and "silent" printer driver installers as required.
Group Policy preferences configured with item level-targeting on security groups perform inefficient recursion of group members. The large number of LDAP queries causes boot or logon delays on the client and high CPU utilization on the servicing DC. Install
the hotfix in KB 2561285 (for Windows 7) or a later version of GPPREFCL.DLL.
In extreme conditions we have seen item-level-targeting generate 17K and even 30K LDAP queries in a single user logon.
Windows 7 RTM clients subject to Group Policy preferences with item-level targeting issue a DSGETDC call requiring a wriTABLE width="99%" DC unless
KB 983531 is installed. The RWDC requirement may trigger the selection of a remote-site DC or logon failure in a DMZ scenario.
The Vista version of this fix is
Windows 7 or Windows Server 2008 R2 computers applying printer drivers by using Group Policy preferences in RODC-covered sites need
KB 2537549 installed to remove a wriTABLE width="99%" DC dependency.
Compared to the networking and policy areas, profiles generate comparatively few logon delays. As with all network I/O, sourcing user profiles over latent WAN links will delay both user logon and user logoff. Also, when you see long execution times for the
profile service in the WINLOGON pane of an XPERF trace, don’t assume that it is the profile load that is running long. Other root causes include:
First-time user logons where new user profiles are derived from default user profiles are delayed by the execution of Active Setup routines that setup desktop shortcuts for Mail, Internet Explorer, and others. Active Setup does not execute on 2nd
time logons using roaming profiles. Active Setup does execute for all logons using mandatory profiles or 2nd time logons where the cached roaming profile has been deleted by one of two policies. Artifact of profile
change in windows Vista and later.
Windows XP or Windows Server 2003 and later
Users report that first-time logons to a new computer are “slow” but subsequent logons to the same computer are “fast.” XPERF shows the profile service executing for 98 seconds and shows high disk I/O once profile load completes. A review of the default
user profile shows that the c:\users\default\downloads folder contains some 381 MB of data, which gets copied every time a user logs on to a new computer and likely every logon to an RDP server or kiosk computer. High workload causes high delay.
Windows Vista or Windows Server 2008 and later
User Logons hang for an extended time. Citrix logons hang while displaying “please wait for local session manager.” Microsoft-Windows-User Profiles Service event 1521 indicates that Windows cannot locate a profile due to error “access is denied.”
Root cause: Folders and subfolders were manually copied into the users profile tree instead of following the steps in
OS startup is delayed, and remote logon can be blocked, when services configured with a custom service account attempt to load a roaming profile while the “delete user profiles older than a specified number of days” policy attempts to delete the same profile.
Setting the policy to delete profiles older than 1 day combined with daily reboots exacerbates the delay.
Readyboot has generated low volume with two exceptions. Windows 7 hotfix
2505454 resolves a condition where a computer with a large drive and a large number of system restore points, which are created after installing fixes from Windows Update for example, can cause a computer to boot without the benefit of Readyboot. The 2nd
issue is the disabling of Readyboot through improper registry changes or service start values.
Windows 7 computers with the OS stored on mechanical drives may boot slowly if the superfetch service has been disabled in Services Control Manager or if the prefretch service has been disabled in Services.msc or the registry. Verify that startup value and
service status for “superfetch” is “automatic” and “started.” The registry values for enablePrefetcher and enablesuperfetch on a computer with a hard drive that is not solid state should have both settings be set to 1.
Windows 7 computers installed on partitions larger than 2 Terabytes may be slower to boot when the number of restore points causes OS startup to occur without the benefit of readyboot. Install
Remote Desktop servers and similar technologies are vulnerable to all of the root causes that can affect performance for a single user on physical hardware, plus the RDP- specific additions. Slow boots on RDP servers are fortunately rare. The CSS SBSL team
likes the idea of reference fix lists like the one Citrix maintains
See Locator section.
See Citrix support article
http://support.citrix.com/article/CTX129229 for a list of Citrix recommended hotfixes and fixes that Citrix recommends from Microsoft.
See http://support.citrix.com/article/CTX127030 for Citrix guidelines for configuring Antivirus software.
Install KB 2661001 to resolve a “Please wait for Local Session Manager” caused by the remote procedure call service incorrectly
handling startup failure in the tstheme.exe process
Troubleshooting slow boots and logons revealed the how critical WMI was to boot and logon performance.
KB 2617858 resolves repository verification following graceful shutdown that also includes the high CPU consumption fix from
KB 2505348. Larger repositories make for longer verification e which in turns causes both boot and logon delays.
Reference WMI fix list KB 2591403 does not reference
KB 2617858 as superseding
KB 2505348 (but it does!)
As you can see, there are a number of root causes for slow boots and logons, including the important realization that many slow logons are actually caused by slow OS startup delaying the user logon operation
Windows Performance Analyzer (WPA)
A more comprehensive NETMON 3.4 display capture filter created by Joel Christenson of the Microsoft CTS networking team. Copy and save as NM3.4colors.nmcr.
<start copy here>
<end copy here>