How do I review the results of check disk that is run on a D: (data) drive? They are not in Event Viewer / Windows Logs / Application.
Also, I found these check disk results that were evidently performed on my E: drive this morning (I did not even know that it ran). I believe my E: drive is my legacy 256 GB SSD and that my local (second) SSD with the active OS is my C: drive (at least that is what Windows calls them when I boot up into Windows on my second SSD, but when I boot into the legacy hard drive I think it swaps the letters and assigns C: to my E: drive).
How concerning are these results? Also, it appears the results at the end of the report are cut off when viewed in Event Viewer. I am providing the Stage 2 results below. Note that they end by stating "The down pointer of current index entry with length 0xa8," which is not even a complete sentence.
As background, my legacy SSD is a 256 GB SSD that came with the laptop. My second SSD is a 1 TB SSD from Crucial to which I restored a backup from my previous laptop. I would expect both of the SSDs not to have errors since they are new, but it appears there are errors below.
Stage 2: Examining file name linkage ...
155 reparse records processed.
Index entry MI74ED~1.MUM of index $I30 in file 0x969f points to unused file 0x2b360.
Deleting index entry MI74ED~1.MUM in index $I30 of file 969F.
Index entry MIC28B~2.MUM of index $I30 in file 0x969f points to unused file 0x2b361.
Deleting index entry MIC28B~2.MUM in index $I30 of file 969F.
Index entry microsoft-windows-editionspecific-enterprisesn-package~31bf3856ad364e35~amd64~hr-hr~10.0.18362.997.mum of index $I30 in file 0x969f points to unused file 0x2b361.
Deleting index entry microsoft-windows-editionspecific-enterprisesn-package~31bf3856ad364e35~amd64~hr-hr~10.0.18362.997.mum in index $I30 of file 969F.
Index entry microsoft-windows-editionspecific-enterprisesn-package~31bf3856ad364e35~amd64~hu-hu~10.0.18362.997.cat of index $I30 in file 0x969f points to unused file 0x2b362.
Deleting index entry microsoft-windows-editionspecific-enterprisesn-package~31bf3856ad364e35~amd64~hu-hu~10.0.18362.997.cat in index $I30 of file 969F.
Index entry microsoft-windows-editionspecific-enterprisesn-package~31bf3856ad364e35~amd64~hu-hu~10.0.18362.997.mum of index $I30 in file 0x969f points to unused file 0x2b360.
Deleting index entry microsoft-windows-editionspecific-enterprisesn-package~31bf3856ad364e35~amd64~hu-hu~10.0.18362.997.mum in index $I30 of file 969F.
The VCN 0x22 of index $I30 in file 0x14226 is already in use.
The VCN 0x20 of index $I30 in file 0x14226 is already in use.
The VCN 0x23 of index $I30 in file 0x14226 is already in use.
Correcting error in index $I30 for file 14226.
The index bitmap $I30 in file 0x14226 is incorrect.
Correcting error in index $I30 for file 14226.
The down pointer of current index entry with length 0xa8
Check disk results on SSDs
-
- SilverLounger
- Posts: 2419
- Joined: 28 Mar 2010, 01:49
Check disk results on SSDs
Regards,
JMT
JMT
-
- SilverLounger
- Posts: 2419
- Joined: 28 Mar 2010, 01:49
Re: Check disk results on SSDs
I just ran check disk on my local C: drive. I ran chkdsk c: /f. It took only about a minute to run, even though C: has about 150 GB of data on it. Did check disk run correct? Is the checking of errors on the volume bitmap reported below something to be concerned about?
Checking file system on C:
The type of the file system is NTFS.
A disk check has been scheduled.
Windows will now check the disk.
Stage 1: Examining basic file system structure ...
938240 file records processed.
File verification completed.
Phase duration (File record verification): 13.27 seconds.
9444 large file records processed.
Phase duration (Orphan file record recovery): 0.00 milliseconds.
0 bad file records processed.
Phase duration (Bad file record checking): 1.08 milliseconds.
Stage 2: Examining file name linkage ...
633 reparse records processed.
1119564 index entries processed.
Index verification completed.
Phase duration (Index verification): 27.59 seconds.
0 unindexed files scanned.
Phase duration (Orphan reconnection): 3.27 seconds.
0 unindexed files recovered to lost and found.
Phase duration (Orphan recovery to lost and found): 510.40 milliseconds.
633 reparse records processed.
Phase duration (Reparse point and Object ID verification): 9.81 milliseconds.
Stage 3: Examining security descriptors ...
Deleting an index entry with Id 4F35 from index $SII of file 9.
Deleting an index entry with Id 4F36 from index $SII of file 9.
Deleting an index entry with Id 4F35 from index $SDH of file 9.
Deleting an index entry with Id 4F36 from index $SDH of file 9.
Cleaning up 11561 unused index entries from index $SII of file 9.
Cleaning up 11561 unused index entries from index $SDH of file 9.
Cleaning up 11561 unused security descriptors.
CHKDSK is compacting the security descriptor stream
Security descriptor verification completed.
Phase duration (Security descriptor verification): 400.54 milliseconds.
90663 data files processed.
Phase duration (Data attribute verification): 1.20 milliseconds.
CHKDSK is verifying Usn Journal...
Usn Journal verification completed.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.
No further action is required.
367305687 KB total disk space.
119031384 KB in 451791 files.
270612 KB in 90666 indexes.
0 KB in bad sectors.
1021363 KB in use by the system.
65536 KB occupied by the log file.
246982328 KB available on disk.
4096 bytes in each allocation unit.
91826421 total allocation units on disk.
61745582 allocation units available on disk.
Total duration: 45.14 seconds (45149 ms).
Internal Info:
00 51 0e 00 64 46 08 00 d7 66 0e 00 00 00 00 00 .Q..dF...f......
fc 01 00 00 7d 00 00 00 00 00 00 00 00 00 00 00 ....}...........
Windows has finished checking your disk.
Please wait while your computer restarts.
Checking file system on C:
The type of the file system is NTFS.
A disk check has been scheduled.
Windows will now check the disk.
Stage 1: Examining basic file system structure ...
938240 file records processed.
File verification completed.
Phase duration (File record verification): 13.27 seconds.
9444 large file records processed.
Phase duration (Orphan file record recovery): 0.00 milliseconds.
0 bad file records processed.
Phase duration (Bad file record checking): 1.08 milliseconds.
Stage 2: Examining file name linkage ...
633 reparse records processed.
1119564 index entries processed.
Index verification completed.
Phase duration (Index verification): 27.59 seconds.
0 unindexed files scanned.
Phase duration (Orphan reconnection): 3.27 seconds.
0 unindexed files recovered to lost and found.
Phase duration (Orphan recovery to lost and found): 510.40 milliseconds.
633 reparse records processed.
Phase duration (Reparse point and Object ID verification): 9.81 milliseconds.
Stage 3: Examining security descriptors ...
Deleting an index entry with Id 4F35 from index $SII of file 9.
Deleting an index entry with Id 4F36 from index $SII of file 9.
Deleting an index entry with Id 4F35 from index $SDH of file 9.
Deleting an index entry with Id 4F36 from index $SDH of file 9.
Cleaning up 11561 unused index entries from index $SII of file 9.
Cleaning up 11561 unused index entries from index $SDH of file 9.
Cleaning up 11561 unused security descriptors.
CHKDSK is compacting the security descriptor stream
Security descriptor verification completed.
Phase duration (Security descriptor verification): 400.54 milliseconds.
90663 data files processed.
Phase duration (Data attribute verification): 1.20 milliseconds.
CHKDSK is verifying Usn Journal...
Usn Journal verification completed.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.
No further action is required.
367305687 KB total disk space.
119031384 KB in 451791 files.
270612 KB in 90666 indexes.
0 KB in bad sectors.
1021363 KB in use by the system.
65536 KB occupied by the log file.
246982328 KB available on disk.
4096 bytes in each allocation unit.
91826421 total allocation units on disk.
61745582 allocation units available on disk.
Total duration: 45.14 seconds (45149 ms).
Internal Info:
00 51 0e 00 64 46 08 00 d7 66 0e 00 00 00 00 00 .Q..dF...f......
fc 01 00 00 7d 00 00 00 00 00 00 00 00 00 00 00 ....}...........
Windows has finished checking your disk.
Please wait while your computer restarts.
Regards,
JMT
JMT
-
- Administrator
- Posts: 12833
- Joined: 16 Jan 2010, 15:49
- Location: London, Europe
Re: Check disk results on SSDs
The errors on your C drive are not important. They may be due to a sudden loss of power some time in the past that prevented a file system operation from finishing.
The errors on the D drive are more worrying, you have at least one corrupt file - you will probably never notice this, but I would keep an eye on that drive, maybe check it weekly for a while.
The errors on the D drive are more worrying, you have at least one corrupt file - you will probably never notice this, but I would keep an eye on that drive, maybe check it weekly for a while.
StuartR
-
- SilverLounger
- Posts: 2419
- Joined: 28 Mar 2010, 01:49
Re: Check disk results on SSDs
StuartR,
I did not post my check disk results for my D: drive. Did you see the question posted in my first question above:
How do I review the results of check disk that is run on a D: (data) drive? They are not in Event Viewer / Windows Logs / Application.
I posted the results of two check disks above. The first one is of my E: drive. I believe that is my legacy 256 GB hard drive. However, I am not sure. When I boot into my 1 TB SSD, Windows assigns my legacy 256 GB hard drive E:. However, when I boot into my legacy 256 GB SSD, I think Windows assigns that drive (the 256 GB SSD) the letter C:. So I am not sure which drive is being reported.
Where are you seeing that one of my files is corrupt above? Is it on the E: drive or C: drive?
Why did the check disk of my C: drive take only about a minute to run, even though it has about 150 GB of data on it? I ran the command chkdsk c: /f at an elevated command prompt.
It appears the check disk results reported in Event Viewer for the E: drive are cut off and incomplete. The report ends with “The down pointer of current index entry with length 0xa8.” How can I review the full results?
Is it safe to run chkdsk c: /r or chkdsk c: /b on a SSD?
I did not post my check disk results for my D: drive. Did you see the question posted in my first question above:
How do I review the results of check disk that is run on a D: (data) drive? They are not in Event Viewer / Windows Logs / Application.
I posted the results of two check disks above. The first one is of my E: drive. I believe that is my legacy 256 GB hard drive. However, I am not sure. When I boot into my 1 TB SSD, Windows assigns my legacy 256 GB hard drive E:. However, when I boot into my legacy 256 GB SSD, I think Windows assigns that drive (the 256 GB SSD) the letter C:. So I am not sure which drive is being reported.
Where are you seeing that one of my files is corrupt above? Is it on the E: drive or C: drive?
Why did the check disk of my C: drive take only about a minute to run, even though it has about 150 GB of data on it? I ran the command chkdsk c: /f at an elevated command prompt.
It appears the check disk results reported in Event Viewer for the E: drive are cut off and incomplete. The report ends with “The down pointer of current index entry with length 0xa8.” How can I review the full results?
Is it safe to run chkdsk c: /r or chkdsk c: /b on a SSD?
Regards,
JMT
JMT
-
- Administrator
- Posts: 12833
- Joined: 16 Jan 2010, 15:49
- Location: London, Europe
Re: Check disk results on SSDs
Do not use chkdsk /R or /B on an SSD. These commands are intended to detect bad clusters, which are a feature of physical disk drives. SSDs work differently.
My comment about corrupt files was about your first post...
My comment about corrupt files was about your first post...
It looks like the file with ID 14226 used some disk blocks that were also in one or more other files, so some data may have been lost or overwritten.The VCN 0x22 of index $I30 in file 0x14226 is already in use.
The VCN 0x20 of index $I30 in file 0x14226 is already in use.
The VCN 0x23 of index $I30 in file 0x14226 is already in use.
Correcting error in index $I30 for file 14226.
The index bitmap $I30 in file 0x14226 is incorrect.
Correcting error in index $I30 for file 14226.
StuartR
-
- SilverLounger
- Posts: 2419
- Joined: 28 Mar 2010, 01:49
Re: Check disk results on SSDs
Thanks StuartR.
Does anyone know the answers to the other questions I posted above, namely:
How do I review the results of check disk that is run on a D: (data) drive? They are not in Event Viewer / Windows Logs / Application.
Why did the check disk of my C: drive take only about a minute to run, even though it has about 150 GB of data on it? I ran the command chkdsk c: /f at an elevated command prompt.
It appears the check disk results reported in Event Viewer for the E: drive are cut off and incomplete. The report ends with “The down pointer of current index entry with length 0xa8.” How can I review the full results?
Does anyone know the answers to the other questions I posted above, namely:
How do I review the results of check disk that is run on a D: (data) drive? They are not in Event Viewer / Windows Logs / Application.
Why did the check disk of my C: drive take only about a minute to run, even though it has about 150 GB of data on it? I ran the command chkdsk c: /f at an elevated command prompt.
It appears the check disk results reported in Event Viewer for the E: drive are cut off and incomplete. The report ends with “The down pointer of current index entry with length 0xa8.” How can I review the full results?
Regards,
JMT
JMT
-
- Administrator
- Posts: 12833
- Joined: 16 Jan 2010, 15:49
- Location: London, Europe
Re: Check disk results on SSDs
If I issue the command chkdsk c: /f then it doesn't run the chkdsk immediately, it schedules it for the next reboot. Is this what you saw?
Command Prompt wrote: Microsoft Windows [Version 10.0.19042.630]
(c) 2020 Microsoft Corporation. All rights reserved.
C:\WINDOWS\system32>chkdsk c: /f
The type of the file system is NTFS.
Cannot lock current drive.
Chkdsk cannot run because the volume is in use by another
process. Would you like to schedule this volume to be
checked the next time the system restarts? (Y/N)
StuartR
-
- SilverLounger
- Posts: 2419
- Joined: 28 Mar 2010, 01:49
Re: Check disk results on SSDs
No; I am referring to running check disk on a disk other than the disk partition that holds the OS. I ran it while I was in C: and the check disk was performed on my D: (data) drive. I cannot find the results in Event Viewer. As I recall, the Command Prompt prompted me to dismount D: before I could run the check disk, which I did. Are the results recorded anywhere?
Regards,
JMT
JMT
-
- Administrator
- Posts: 7298
- Joined: 15 Jan 2010, 22:52
- Location: Middle of England
Re: Check disk results on SSDs
You could try running this from a CMD prompt (as administrator):
chkdsk d: > d:\log.txt
...then you can examine the results in the log.txt file.
chkdsk d: > d:\log.txt
...then you can examine the results in the log.txt file.
Leif
-
- SilverLounger
- Posts: 2143
- Joined: 25 Jan 2010, 02:12
Re: Check disk results on SSDs
My understanding of CHKDSK output is that it logged only when CHKDSK is run at boot time. Otherwise, it is console output which may be captured as Leif posted.
Unfortunately, right now I do not have access to a system with more than one drive to test this.
Unfortunately, right now I do not have access to a system with more than one drive to test this.
Joe
-
- Administrator
- Posts: 7298
- Joined: 15 Jan 2010, 22:52
- Location: Middle of England
Re: Check disk results on SSDs
Running a scan from the drive properties:
...does appear to show up in event viewer: (Note - you need to look at the 'Details' tab.)
(This is a 250GB partition on a single 500GB SSD, running W10 Pro.)
...does appear to show up in event viewer: (Note - you need to look at the 'Details' tab.)
(This is a 250GB partition on a single 500GB SSD, running W10 Pro.)
You do not have the required permissions to view the files attached to this post.
Leif
-
- SilverLounger
- Posts: 2419
- Joined: 28 Mar 2010, 01:49
Re: Check disk results on SSDs
JoeP:
To clarify, I am running a disk check of the D: partition while I am on the C: partition. Both partitions are on the same SSD. The C: partition holds my OS. The D: partition holds my data.
Leif:
Apparently, the results for the d: drive when run from an elevated Command Prompt do save in Event Viewer, but they are saved as “Chkdsk” in the Source column, not as “Wininit,” which is where my c: drive scans normally save.
I have copied the results of my d: drive scan disk. This is of a brand new Crucial.com SSD two weeks after I restored the image of the data drive of my previous laptop to it a couple of weeks ago. How concerned should I be of the multiple “Deleting corrupt attribute record (0x80, "")” results? Why would a new SSD have all of these errors?
I am only displaying part of the results because this Lounge's platform allows a maximum of 7500 characters and also because the log in Event Viewer is truncated, so I do not have all of the results in the log anyway.
To clarify, I am running a disk check of the D: partition while I am on the C: partition. Both partitions are on the same SSD. The C: partition holds my OS. The D: partition holds my data.
Leif:
Apparently, the results for the d: drive when run from an elevated Command Prompt do save in Event Viewer, but they are saved as “Chkdsk” in the Source column, not as “Wininit,” which is where my c: drive scans normally save.
I have copied the results of my d: drive scan disk. This is of a brand new Crucial.com SSD two weeks after I restored the image of the data drive of my previous laptop to it a couple of weeks ago. How concerned should I be of the multiple “Deleting corrupt attribute record (0x80, "")” results? Why would a new SSD have all of these errors?
I am only displaying part of the results because this Lounge's platform allows a maximum of 7500 characters and also because the log in Event Viewer is truncated, so I do not have all of the results in the log anyway.
Code: Select all
Chkdsk was executed in read/write mode.
Checking file system on D:
The type of the file system is NTFS.
Chkdsk cannot run because the volume is in use by another
process. Chkdsk may run if this volume is dismounted first.
ALL OPENED HANDLES TO THIS VOLUME WOULD THEN BE INVALID.
Would you like to force a dismount on this volume? (Y/N) Volume dismounted. All opened handles to this volume are now invalid.
Volume label is Data.
Stage 1: Examining basic file system structure ...
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0x105fc for possibly 0x1b clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0x3957 is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0x3957.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0x105c4 for possibly 0x38 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0x4139 is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0x4139.
Attribute record of type 0x80 and instance tag 0x1 is cross linked
starting at 0xa01779 for possibly 0x1a clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x1
in file 0xd6a3 is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0xD6A3.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0xf492b2 for possibly 0x1a clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0xd6b9 is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0xD6B9.
Attribute record of type 0x80 and instance tag 0x1 is cross linked
starting at 0xf49335 for possibly 0x16 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x1
in file 0xe75a is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0xE75A.
Attribute record of type 0x80 and instance tag 0x1 is cross linked
starting at 0xf49355 for possibly 0x25 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x1
in file 0xe7fa is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0xE7FA.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0x3df4671 for possibly 0x37 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0xe8c5 is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0xE8C5.
Attribute record of type 0x80 and instance tag 0x1 is cross linked
starting at 0x3df46a8 for possibly 0x34 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x1
in file 0xe919 is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0xE919.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0xf492cc for possibly 0x46 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0xe97d is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0xE97D.
Attribute record of type 0x80 and instance tag 0x1 is cross linked
starting at 0xf492e7 for possibly 0x47 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x1
in file 0xe997 is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0xE997.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0x12cebea for possibly 0x7e clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0xe9ac is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0xE9AC.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0x12cecc1 for possibly 0x55 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0xe9d2 is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0xE9D2.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0x3df4643 for possibly 0x2e clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0xe9e9 is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0xE9E9.
Attribute record of type 0x80 and instance tag 0x4 is cross linked
starting at 0x12cec6e for possibly 0x18 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x4
in file 0xea74 is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0xEA74.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0x15f354a for possibly 0x2 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0x11182 is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0x11182.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0xf4932e for possibly 0x2 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0x12000 is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0x12000.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0xf4934b for possibly 0x9 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0x1201e is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0x1201E.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0xf49354 for possibly 0x1 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0x1201f is already in use.
Deleting corrupt attribute record (0x80, "")
from file record segment 0x1201F.
Attribute record of type 0x80 and instance tag 0x3 is cross linked
starting at 0x3d9f41d for possibly 0x5 clusters.
Some clusters occupied by attribute of type 0x80 and instance tag 0x3
in file 0x120cf is already in use.
Regards,
JMT
JMT
-
- Administrator
- Posts: 12833
- Joined: 16 Jan 2010, 15:49
- Location: London, Europe
Re: Check disk results on SSDs
You could get file system errors like this if Windows crashed, or was powered down, while it was in the middle of creating/modifying/deleting a file.
StuartR
-
- SilverLounger
- Posts: 2143
- Joined: 25 Jan 2010, 02:12
Re: Check disk results on SSDs
The different sources (wininit and chkdsk) are normal. Wininit is from boot time scan, Chkdsk is from a manual scan within WIndows.
Joe