I tried a lot of things but finally, the one which worked for me was to enable VSS for the drive and again disable it after I ran chkdsk with both the options checked for fixing the errors.
In my case, I fixed this by uninstalling hotfix ME2823324
wusa.exe /uninstall /kb:2823324 /quiet /norestart
In our case, this happened after installing Acronis v9.5. Anytime Backup Exec would run and perform a snap shot this error would be recorded. We finally flushed all the VSS images disabled VSS and then enable it via My Computer >> drive letter >> Shadow copy >> Disable >> Enable.
I had this event for months. Every time when the computer started it performed a check disk and I couldn't find the reason. Fortunately the problem was for partition D. I finally backed up the data, deleted that logical drive and recreated it. No more event messages.
In my case it was not possible to switch cluster group to second node, neither to get resource physical disk online on second node. Other symptom was that chkdsk would always fail with a "Free space verification is complete.An unspecified error occurred. " error message.
This issue can be caused by two root causes :
1. There is a permanent reservation on the disk and therefore the passive node cannot set its own SCSI reservation. Therefore the disk will not come online. Your SAN vendor should have a tool to remove such a reservation. If your vendor doesn't have it, the following should help:
- Disable the cluster services to remove the persistent reservation:
- To remove the persistent reservation from the quorum drive, disable the ClusDisk and ClusSvc services.
Note: You do not have to shut down the storage devices when you disable these cluster services
2. This problem is known to occur after you install or migrate to Symantec Endpoint Protection 11.0 Release Update 5 (RU5) on the cluster nodes. You can fix it immediately by:
- Killing process SMC.EXE
- Downgrade/Upgrade of SEP
- Disabling SMC service on both cluster nodes
I have had this error using Windows Media Center and spent an age trying to resolve it. In my case, it was caused by a power outage causing a problem with the "All Users\Documents\Recorded TV\TempRec\TempSBE" directory, which became corrupted. CHKSDSK did not find an issue (I think it is due to a case mismatch with CHKDSK between the MFT and FRS; see knowledgebase ME246026
). I could not delete the directory, using explorer or Delinvfile.
So CHKDSK says everything is OK, but the volume dirty bit is set when Windows starts. The trick is to identify which access is marking the volume as dirty. I ran Sysinternal’s Process Monitor and enabled Boot Logging (Options -> Enable Boot Logging). This resulted in a humongous log file but the process that set the dirty bit has a result of CORRUPT.
In my case I moved the corrupt directory (as it could not be deleted) to my root directory and created a new directory structure using the old (corrupt) path. I ran CHKDSK /F /R on restart, and no errors were detected. FSUTIL DIRTY QUERY C: showed the drive as clean and I could defrag my hard drive.
I got this error after rebuilding a RAID 5 partition. I resolved this problem by updating SCSI/RADI firmware, running chkdsk, and finally applying hotfix ME932578
for a hotfix applicable to Microsoft Windows Server 2003 and Microsoft Windows XP.
See the link to "SWSoft Support Article ID: 1008" for additional information about this event.
As per Microsoft: "The file system structure on the volume listed in the message might be corrupt because of one or more of the following reasons:
- The disk might have bad sectors.
- I/O requests issued by the file system to the disk subsystem might not have been completed successfully". See MSW2KDB
for more details.
As per Microsoft: "This behavior occurs when the cluster node computer starts. This behavior is caused by a conflict between the NTFS file system and the cluster services driver component (Clusdisk) filter. If you experience the behavior as it has been described, it does not indicate a problem with the cluster node hard disk and can be ignored". See the link to ME885688
for more details on this issue.
As per Microsoft: "If you are using MSDE, when the database size limit of 2 GB is reached or exceeded, MSDE is halted, no further jobs are scheduled, and a record similar to the following is written to the system event log". See the link to "DTM Database Options and Maintenance Best Practices" for additional information.
I have seen this error occur when using Tivoli’s TSM 5.2.3 Open File Support, which uses the Logical Volume Snapshot Agent. This may occur on database servers where a snapshot of a locked file may be in process. Uninstall Open File Support and use a product suited for databases.
for details on how to fix this problem.
If this is a logical drive, which has been given to a server via ''Selective Storage Presentation'' in a Heterogeneous SAN Environment running Windows 2000, make sure you have the correct zoning configuration implemented on the Fabric Switch; otherwise, this drive will be seen on other Fibre Channel hosts in your SAN. Thus, cause this error to appear.
This may be caused by corrupted pagefile. I got Event ID 55 every time chkdsk ran when WinXP Pro SP1 started. Solution: Take another disk/volume for pagefile. After this, you may delete old “pagefile.sys” and then change disk/volume for pagefile back to the previous one.
From a newsgroup posting: There could be several problems:
1. HDD is bad
2. If HDD is good, then the motherboard is bad
3. If the motherboard is good, then look in line 1 :)
Anyway, backup your critical data immediately. Then run chkdsk /f. To be on the safe side, it's better if you have Win2k machine around and you might check NT disk on this machine more safely.
Under stressful disk input/output (I/O) on a volume that uses the NTFS file system, disk inconsistency may occur. A fix is available from Microsoft for both Windows 2000 and Windows NT.
As per ME320866
, this problem may be caused by a condition in the Windows 2000 Disk Defragmenter tool that may prevent a particular cluster of data from being optimized. See the article for details.
This behavior can occur if the NTFS volumes' Master File Table (MFT) is corrupted. See ME246026