Error message: "Could not start the Cluster Service on Local Computer"

Windows Clustering reports details about changes in the cluster in a log file. If this file becomes corrupted for any reason, the Cluster service may not start. You may receive the following error message when you attempt to start the Cluster service: The following events may be reported in the system event log:

Event ID: 1019
Event Type: Warning
Event Source: ClusSvc
Event Category: Log Mgr
Description: The log file Q:\MSCS\quolog.log was found to be corrupt. An attempt will be made to reset it, or you should use the Cluster Administrator utility to adjust the maximum size.

Event ID: 1148
Event Type: Error
Event Source: ClusSvc
Event Category: Log Mgr
Description: Cluster service encountered a fatal error. The vital quorum log file 'Q:\MSCS\quolog.log' is corrupt. If you have a backup of the quorum log file, you may try to start Cluster service by entering 'clussvc -debug -noquorumlogging' at a command window, copy the backed up quorum log file to the MSCS directory on the quorum drive, stop Cluster service, and restart Cluster service normally using the 'net start clussvc' command. If you do not have a backup of the quorum log file, you may try to start Cluster service as 'clussvc -debug -resetquorumlog' and this will attempt to create a new quorum log file based on possibly stale information in the server cluster database. You may then stop Cluster service and restart it normally using the 'net start clussvc' command.

The error message can occur if the quorum log file (Quolog.log) cannot be found or read at Cluster service startup. This file must be readable to confirm that the cluster configuration on the local node is current. If the Cluster service cannot read the log, the service is not prevented from loading stale configuration data.

The log file may be corrupted if the time and date stamp of the Chkxxx.tmp file does not match the stamp of the Quolog.log file in the \MSCS folder on the quorum drive. The corruption can occur if you recently performed a restore operation, or if you experienced a power outage.

To resolve this issue, start the Cluster service with the -ResetQuorumLog switch:

1. Start the Computer Management snap-in.
2. Open the properties of the Cluster service.
3. In the Start Parameters box, type -ResetQuorumLog, and then start the Cluster service.
4. To make sure that everything is running correctly, stop the Cluster service, and then start it again without any parameters. If this procedure does not start the Cluster service, you may have to completely re-create the checkpoint and the Quolog.log file from the local cluster registry. To do so:
   1. Start Computer Management.
   2. Open the properties of the Cluster service.
   3. In the Start Parameters box, type -NoQuorumLogging, and then start the Cluster service.
   4. Start Windows Explorer, and then move the Quolog.log file and all the Chkxxx.tmp files that are in the MSCS folder that is on the quorum drive to the root of the quorum drive so that they do not exist in the MSCS folder.
   5. Switch to Computer Management, and then stop the Cluster service.
   6. In the Start Parameters box, type -ResetQuorumLog, and then start the Cluster service again.
      
      Note If the cluster is running Windows 2000 Service Pack 4 (SP4), and if the KB 872970 hotfix is installed, do not use the -ResetQuorumLog switch. You may start the Cluster service normally.
   7. Stop the Cluster service, and then start it again without the startup parameters.

You can restore the quorum from a backup source by restoring the system state on one of the nodes that contains the most recent changes that were made to the cluster. For more information about backing up and restoring cluster configuration information, click the following article number to view the article in the Microsoft Knowledge Base:

Cluster database and registry management

Each node that participates in a cluster maintains a local copy of the cluster database in the %SystemRoot%\Cluster\Clusdb file. When the Cluster service starts for the first time on a node, an updated copy of the cluster database is created and maintained as a registry hive (HKEY_LOCAL_MACHINE\Cluster). When you restart the cluster server, the existing cluster hive is used and then updated.

The Cluster service replicates the cluster registry in a file located on the quorum resource. The checkpoint file is located at \Mscs\Chkxxx.tmp. Every time a checkpoint is taken in, a checksum record is logged to the \Mscs\Quolog.log file. The following events trigger cluster registry checkpointing:

• The first node forms the cluster (after the quorum resource comes online).
• The Cluster service stops on any node.
• The Quolog.log file reaches its reset size limit (64 KB in Windows 2000).
• If there have not been any changes, the Cluster service checkpoints the cluster registry based on a time interval that is specified in the following registry key (if no value is defined, the default value is 4 hours):
  HKEY_LOCAL_MACHINE\Cluster\Quorum\CheckpointInterval

Cluster log management

The cluster server uses quorum logging to record changes to the cluster registry. Changes are tracked so that when cluster nodes rejoin the cluster that was offline, the nodes undergo all the modifications that were made to the cluster configuration while they were offline.

When you disable quorum logging within a cluster, changes to the cluster configuration cannot be logged. If a node goes offline during this period, recent changes may be lost if the changes cannot be communicated to the other node. Quorum logging should only be disabled when it is necessary to recover from log file corruption.

Quorum logging is turned on every time a node goes offline and a checkpoint is taken, and it is turned off when all cluster nodes are running. The Quolog.log file is located in the \Mscs folder on the quorum drive. When the cluster is formed, the latest \MSCS\Chkxxx.tmp file is used to load the cluster registry, by default. The \Mscs\Quolog.log file is used to apply all the changes to the cluster database since the last checkpoint. This algorithm applies even if the node was down for period of time.

For more information about the the KB872970 hotfix, click the following article number to view the article in the Microsoft Knowledge Base: