F
FredS63
A while back I upgraded to Windows 10 Home Premium 64 bit from 32 bit (The system was 64 bit compatible, though it had shipped with 32 bit Windows Vista which I then upgraded to Windows 7 32 bit). System is an HP m7640n media center PC. I upgraded to Windows 10 64 bit in order to break the 4 GB RAM limit in 32 bit windows 10 and installed 8 GB RAM DDR2 RAM. I installed a new Seagate 2 TB hard drive. I reinstalled all software and new 64 bit drivers as necessary, and I copied my personal files from the 32 bit system. Everything was ok for a while until I decided to divide the drive into two partitions using Disk Manager and moved my libraries to the new partition in order to make more room on the C: drive. At first everything was ok and the partitioned drive worked fine and I did regular system image backups for about 6 months until the Fall Creator's edition came out. Attempting to upgrade to the creators edition the system would hang and fail and I had to revert back to the previous version of Windows 10 in Windows RE. For some reason, because the creator's edition was a major upgrade, it did not like the fact that the libraries were on a different volume, D:\ than the system volume, C:\. After researching and finding that that might be the problem (there was an MS tech document on the bug as there were complaints by users about the creator's edition), I decided the best recourse was to delete the second partition/volume using Disk Manager and return to a single C: volume. Here is where it gets interesting. I saved a system image successfully of the existing partitions, C: and D:, moved my personal files back to C: and deleted the D: volume on the disk. I then extended the C: volume to take up the unallocated space on the whole drive and upgraded to the Fall Creator's edition. Success.
Now, everything seemed ok until I ran a system image backup. The image backup failed due to bad sectors and it instructed me to run a chkdsk /r and run the system image again. I exited to Windows RE and ran a chkdsk /r on the volume C:\. It found over half the drive with bad clusters. Getting back into Windows 10 half my free space on the drive had disappeared in "This PC" and the drive said I was using 1.1TB of space when in actuality it was around 300 GB. I tried reshrinking and extending the volume C: and got errors in Disk Manager. Thinking I had a failing drive, I purchased a new Seagate drive and reinstalled the system from an old successful image backup prior to the Fall Creator's edition that had the two partitions. Again, I moved my files from D: to C: drive, deleted the D: volume and extended the C: volume in Disk Manager. Ran image backup and got the same error. I ran Seagate Seatools and the disk passed. At this point I contacted Seagate support and they were stumped and suggested I try the drive in another system. Not having another system, I did some research and this is what I did to resolve the issue:
Here’s what I did.
1.) I ran a “chkdsk c:” without flags to check the disk using windows command prompt from within windows 10. I received an error:
"Error detected in index $I30 for file (file number)”
Chkdsk cannot continue.
2.) I did some research on this and found this thread on Microsoft site:
https://support.microsoft.com/en-us...n-the-chkdsk-exe-utility-in-read-only-mode-on
Apparently, it seems to be a volume shadow copy issue on extended volumes. I remember that I did extend the volume on the C: partition.
3.) Next, I ran a “chkdsk /i” in Windows Recovery Environment (RE) to check indexes for errors. I then got back into Windows 10 and ran “chkdsk c:” without flags again and the $i30 error was gone and got no errors.
4.) I then ran an image backup in windows. And I received the following error, although the backup seemed to complete and the files were all there in the “windowsimagebackup” directory on the external USB drive:
“New bad clusters were found on the source volume. These clusters were not backed up. (Error 0x8078007D)”
5.) Next, remembering that I had extended the “c: volume” when I reinstalled the system and OS and files from a windows image backup, I shrunk the “c: volume” from 2TB in Windows Disk Manager to the maximum allowed shrink of about 580 GB leaving 1.2TB in allocated space on the disk.
6.) Next, I tried creating a new volume in Windows disk manager of 1.2TB and that was created although and error popped up, but the partition was still created. However, when I tried to “format” the partition it failed and left the new volume unformatted, although it showed as “d: drive” in windows “This PC”.
7.) I rebooted to Windows RE command prompt “Diskpart” and attempted to format the new partition there. I did a full format and after hours it stopped at 35%. I cancelled the "format" operation.
(Note: Do not use quotes in commands)
8.) I selected the partition, "Diskpart>List Disk", "DiskPart>select disk 0"
"DiskPart>list partition", "Diskpart>select partition (number)". and deleted the failed partition in “Diskpart>delete partition”.
8.) Back in Windows everything seems ok. The original problem of the lost space after running “chkdsk /r” seemed to be gone and my image backups are working normally.
Conclusion:
Windows 10 extended volume in disk manager was causing an index issue and chkdsk /r was not properly recognizing the extended volume clusters restored from image backups that used Volume Shadow Copy Service (VSS), and marking them as bad stealing space from the hard drive. This issue was an old one that was supposed to have been resolved in new windows releases but apparently has not been. The solution is to create and format any new volumes in Diskpart and not use extended volumes. I don’t know if the issue is related to my particular system, but the issue happened on two separate Seagate 2TB disks that I loaded the operating system from an image backup on. Because VSS is used when creating the image backup, the index entries are not properly changed or updated when the restored “c: volume” from the image backup is extended onto a larger drive. Apparently, chkdsk /r marks the new extended space as bad clusters or sectors. Hopefully, this issue will get resolved by Microsoft at some point.
I know this is long but I'm hoping that this might help someone and that microsoft will find a solution to that VSS error corrupting the disks on extended volumes.
Fred
Continue reading...
Now, everything seemed ok until I ran a system image backup. The image backup failed due to bad sectors and it instructed me to run a chkdsk /r and run the system image again. I exited to Windows RE and ran a chkdsk /r on the volume C:\. It found over half the drive with bad clusters. Getting back into Windows 10 half my free space on the drive had disappeared in "This PC" and the drive said I was using 1.1TB of space when in actuality it was around 300 GB. I tried reshrinking and extending the volume C: and got errors in Disk Manager. Thinking I had a failing drive, I purchased a new Seagate drive and reinstalled the system from an old successful image backup prior to the Fall Creator's edition that had the two partitions. Again, I moved my files from D: to C: drive, deleted the D: volume and extended the C: volume in Disk Manager. Ran image backup and got the same error. I ran Seagate Seatools and the disk passed. At this point I contacted Seagate support and they were stumped and suggested I try the drive in another system. Not having another system, I did some research and this is what I did to resolve the issue:
Here’s what I did.
1.) I ran a “chkdsk c:” without flags to check the disk using windows command prompt from within windows 10. I received an error:
"Error detected in index $I30 for file (file number)”
Chkdsk cannot continue.
2.) I did some research on this and found this thread on Microsoft site:
https://support.microsoft.com/en-us...n-the-chkdsk-exe-utility-in-read-only-mode-on
Apparently, it seems to be a volume shadow copy issue on extended volumes. I remember that I did extend the volume on the C: partition.
3.) Next, I ran a “chkdsk /i” in Windows Recovery Environment (RE) to check indexes for errors. I then got back into Windows 10 and ran “chkdsk c:” without flags again and the $i30 error was gone and got no errors.
4.) I then ran an image backup in windows. And I received the following error, although the backup seemed to complete and the files were all there in the “windowsimagebackup” directory on the external USB drive:
“New bad clusters were found on the source volume. These clusters were not backed up. (Error 0x8078007D)”
5.) Next, remembering that I had extended the “c: volume” when I reinstalled the system and OS and files from a windows image backup, I shrunk the “c: volume” from 2TB in Windows Disk Manager to the maximum allowed shrink of about 580 GB leaving 1.2TB in allocated space on the disk.
6.) Next, I tried creating a new volume in Windows disk manager of 1.2TB and that was created although and error popped up, but the partition was still created. However, when I tried to “format” the partition it failed and left the new volume unformatted, although it showed as “d: drive” in windows “This PC”.
7.) I rebooted to Windows RE command prompt “Diskpart” and attempted to format the new partition there. I did a full format and after hours it stopped at 35%. I cancelled the "format" operation.
(Note: Do not use quotes in commands)
8.) I selected the partition, "Diskpart>List Disk", "DiskPart>select disk 0"
"DiskPart>list partition", "Diskpart>select partition (number)". and deleted the failed partition in “Diskpart>delete partition”.
- I recreated the partition in: “Diskpart>create partition primary” and it created a new partition of 1.2TB in the unallocated space.
- Then, selected the partition and formatted it: “Diskpart>format fs=ntfs quick. Success.
- I then assigned a letter to the new formatted volume: "Diskpart>assign letter (letter)"
- Next, exited Diskpart and ran “chkdsk d: /f /r /x”
- No cluster errors.
- Next, ran “chkdsk c: /f /r /x”
No cluster errors.
8.) Back in Windows everything seems ok. The original problem of the lost space after running “chkdsk /r” seemed to be gone and my image backups are working normally.
Conclusion:
Windows 10 extended volume in disk manager was causing an index issue and chkdsk /r was not properly recognizing the extended volume clusters restored from image backups that used Volume Shadow Copy Service (VSS), and marking them as bad stealing space from the hard drive. This issue was an old one that was supposed to have been resolved in new windows releases but apparently has not been. The solution is to create and format any new volumes in Diskpart and not use extended volumes. I don’t know if the issue is related to my particular system, but the issue happened on two separate Seagate 2TB disks that I loaded the operating system from an image backup on. Because VSS is used when creating the image backup, the index entries are not properly changed or updated when the restored “c: volume” from the image backup is extended onto a larger drive. Apparently, chkdsk /r marks the new extended space as bad clusters or sectors. Hopefully, this issue will get resolved by Microsoft at some point.
I know this is long but I'm hoping that this might help someone and that microsoft will find a solution to that VSS error corrupting the disks on extended volumes.
Fred
Continue reading...