Server 2008 Hangs at “Applying Computer Settings”

Update: Microsoft has released a hotfix for this issue, see: http://support.microsoft.com/kb/2379016

Last week I Windows Server 2008 machine that was taking a very long time to get past the “Applying Computer Settings” screen; Once it finally did get past that screen logging in would take a very long time and things in general were very slow with many applications failing to launch altogether.

In the Application log there were 3 Warning messages from Winlogon that would show up with every boot:

Event ID 6005: The winlogon notification subscriber <GPClient> is taking long time to handle the notification event (Logon).
Event ID 6006: The winlogon notification subscriber <GPClient> took 3599 second(s) to handle the notification event (CreateSession).
Event ID 6005: The winlogon notification subscriber <GPClient> is taking long time to handle the notification event (CreateSession).

Since these warning messages pointed to a potential issue with Group Policy I enabled group policy logging. There were tons of error messages, but none of them proved to be particularly useful. These messages were repeated throughout the log file:

GPSVC(6d0.704) 10:54:06:941 Client_InitialRegisterForNotification: User = machine, changenumber = 0
GPSVC(6d0.704) 10:54:06:941 Client_RegisterForNotification: CheckRegisterForNotification returned error 0x6d9
GPSVC(6d0.704) 10:54:06:941 CGPNotify::RegisterForNotification: Service not RUNNING. waiting
GPSVC(6d0.704) 10:54:06:941 CGPNotify::RegisterForNotification: Trying to recover from error 1753
GPSVC(6d0.704) 10:54:06:941 CGPNotify::RegisterNotificationAsynchronously: Starting async registration
GPSVC(6d0.704) 10:54:06:941 CGPNotify::RegisterNotificationAsynchronously: Created thread 1804
GPSVC(6d0.70c) 10:54:06:941 CGPNotify::RegisterNotificationAsynchronously: Waiting for service to start
GPSVC(6d0.704) 10:54:06:941 CGPNotify::RegisterNotificationAsynchronously: Exiting with status = 0
GPSVC(6d0.704) 10:54:06:941 CGPNotify::RegisterForNotification: Exiting with status = 0
GPSVC(264.2f8) 10:57:09:087 CGPNotify::WaitForServiceChangeAndRegister: Failed to wait for svc change with 258
GPSVC(30c.320) 10:57:09:352 CGPNotify::WaitForServiceChangeAndRegister: Failed to wait for svc change with 258
GPSVC(6d0.70c) 11:04:06:948 CGPNotify::WaitForServiceChangeAndRegister: Failed to wait for svc change with 258

After troubleshooting for quite some time I found that the issue had nothing to do with Group Policy. The problem turned out to be caused by a lock on the Service Control Manager (SCM) database.  To validate that this was the issue I ran “sc querylock” which gave this output:

C:windowssystem32>sc querylock
[SC] QueryServiceLockstatus - Success
        IsLocked : True
        LockOwner : .NT Service Control Manager
        LockDuration : 3751 (seconds since acquired)

This message indicates that there is a deadlock between the Service Control Manager and http.sys. To resolve this issue simply add the following registry key and reboot the system.

In the HKLMSystemCurrentControlSetServicesHTTP create the REG_MULTI_SZ value named DependOnService and set the value to CRYPTSVC

Related Microsoft KB article: http://support.microsoft.com/kb/2004121

Normal output from “sc querylock”

C:windowssystem32>sc querylock
[SC] QueryServiceLockstatus - Success
        IsLocked : False
        LockOwner :
        LockDuration : 0 (seconds since acquired)

Nodes Not Setting DNS When Using /etc/hosts in Perceus

While moving a cluster from assigning node IP’s via DHCP to static assignment I had problems with the Nodes not properly setting the DNS server in /etc/resolve.conf when using /etc/hosts in Perceus to assign IP addresses. The nodes were defaulting to the values that were already in the vnfs capsule instead of updating them. This caused very slow ssh login times because the DNS server that was in the vnfs capsule /etc/resolve.conf file did not exist.

I wasn’t able to figure out how to fix this issue, so for now I just updated the resolve.conf file in the vnfs capsule.

For some background information on what led to this problem please see this old post: [intlink id=”87″ type=”post”]old post[/intlink].