This morning, I saw a YouTube video in which the video’s creator had just suffered a major data loss event. As is so often the case in IT, it wasn’t just one thing that went wrong to cause data loss. Instead, a lot of little things culminated into a catastrophe.
An underlying factor that contributed to the YouTuber's data loss event was bit rot -- the slow degradation of data over time. I have written about bit rot in the past, particularly with regard to how the ReFS (Resilient File System) can help reverse the related damage. But what if your file system is based on NTFS (New Technology File System)?
Unfortunately, NTFS does not support the use of integrity streams in the way that the ReFS does. Even so, it is possible to use PowerShell to detect and assess corruption on an NTFS volume. If you do find corruption, then you can deal with the problem before things get any worse. This may mean initiating a volume repair, restoring files from backup, or perhaps replacing aging hard disks.
Regardless of what the underlying resolution process ultimately looks like, the key is to be proactive. Look for corruption on your NTFS volumes so that you can do something about it.
So, with that said, let’s look at how the process works.
Using the CHKDSK Utility
CHKDSK has long been the go-to mechanism for checking a volume’s integrity. Although early versions of CHKDSK (particularly those designed for the FAT and FAT-32 file systems) provided a limited amount of information, newer versions produce output that is much more detailed. Figure 1, for example, shows the output that is produced when running CHKDSK on Windows 11.
Figure 1
This is an example of the output that is generated by the CHKDSK utility.
While this information can be helpful, the CHKDSK utility produces quite a bit more data than what it displays onscreen. The additional data can help you to assess the level of corruption that might exist on a NFTS volume. The trick to enumerating the data collected by the CHKDSK utility is to use a PowerShell cmdlet called Get-VolumeCorruptionCount.
Get-VolumeCorruptionCount Cmdlet
The Get-VolumeCorruptionCount cmdlet is a part of PowerShell’s Storage module. Typically, you won’t have to manually load the Storage module, but if it becomes necessary to do so, you can use PowerShell’s Import-Module cmdlet. You can see the process of manually importing the Storage module in Figure 2.
Figure 2
This is how you can manually import the Storage module.
To use the Get-VolumeCorruptionCount cmdlet, just enter the cmdlet, followed by the drive letter that you want to analyze. The drive letter must be entered without the colon (e.g., C instead of C:). As you can see in Figure 3, the Get-VolumeCorruptionCount cmdlet returns a numerical value that reflects the number of errors on the specified volume. In this case, there are no errors. If errors did exist, then you could use the count to assess the extent of the problem.
Figure 3
The Get-VolumeCorruptionCount cmdlet returns the number of errors present on the volume.
The -Verbose Parameter
Although a volume error count can be useful in the right circumstances, all it really does is to give you a general sense of the volume’s overall health. However, you can force the Get-VolumeCorruptionCount cmdlet to provide much more detailed information about each instance of corruption that exists on the volume. The trick is to include the -Verbose parameter between the Get-VolumeCorruptionCount cmdlet and the drive letter. If you wanted to see detailed information about the C: drive, for example, you could use this command:
Get-VolumeCorruptionCount -Verbose C
Unfortunately, adding the -Verbose parameter has no effect unless corruption exists on the volume. Figure 4 illustrates the use of the Get-VolumeCorruptionCount cmdlet with and without the Verbose parameter.
Figure 4
If no errors exist on the volume, then the Get-VolumeCorruptionCount cmdlet will produce exactly the same output as it does without the -Verbose switch.
If you are curious as to the types of information that the Get-VolumeCorruptionCount cmdlet can return when a volume contains errors and the Verbose parameter is used, check out Microsoft’s documentation. The documentation provides an example of the type of output you can expect.
