Possible false positive errors from AOMEI Partition Assistant CHKDSK scan?

hbenthow

Distinguished
Dec 11, 2014
276
1
18,795
I need to create some extra unallocated space on my system drive (in case Windows later needs it to create extra recovery partitions). I was told that AOMEI Partition Assistant was a good program to use, so I downloaded and installed it. The program featured a link to an article about the safest way to edit partitions, in which it recommended using AOMEI's option to check the disc for errors before going through with the actual editing.

As was recommended, I selected my Windows partition, went to "Advanced", then selected "Check Partition", then ran it with the option "Check partition for errors by using chkdsk.exe" selected.

It ran a quick scan of the partition and found some errors. Here are the results:

Disc%20check_zpsiv3verbf.jpg


There was an option to let AOMEI try to fix the errors. I selected that option, whereupon the computer restarted and went through a CHKDSK session, at the end of which it said that it had finished checking for and fixing errors. Once I booted back into Windows after CHKDSK finished, I checked the disc with AOMEI yet again. This time, it showed almost the same message as before, but this time with different index items listed as having errors. So I again selected the option to let AOMEI try to fix it. The computer again restarted and went through a CHKDSK session, again claiming that it had finished checking for and fixing errors. I again booted into Windows and started up AOMEI. I again used it to check the partition. This time, it gave me this ominous-sounding message:

Disc%20check%202_zpsotfdqcos.jpg


Take special notice of the part that says, "The master file table's (MFT) BITMAP attribute is incorrect. The Volume Bitmap is incorrect. Windows has checked the file system and found problems. Please run chkdsk /scan to find the problems and queue them for repair."

I opened up an elevated command prompt and ran chkdsk /scan, with the following result:

C:\WINDOWS\system32>chkdsk /scan
The type of the file system is NTFS.
Volume label is Windows.


Stage 1: Examining basic file system structure ...
414720 file records processed.
File verification completed.
11758 large file records processed.
0 bad file records processed.


Stage 2: Examining file name linkage ...
551150 index entries processed.
Index verification completed.
0 unindexed files scanned.
0 unindexed files recovered to lost and found.


Stage 3: Examining security descriptors ...
Security descriptor verification completed.
68216 data files processed.
CHKDSK is verifying Usn Journal...
55142544 USN bytes processed.
Usn Journal verification completed.


Windows has scanned the file system and found no problems.
No further action is required.


976146431 KB total disk space.
96321096 KB in 312241 files.
233428 KB in 68217 indexes.
0 KB in bad sectors.
568675 KB in use by the system.
65536 KB occupied by the log file.
879023232 KB available on disk.


4096 bytes in each allocation unit.
244036607 total allocation units on disk.
219755808 allocation units available on disk.

AOMEI's message had implied that the way to fix the errors that it found was to run chkdsk /scan in an elevated command prompt. However, when I did so, CHKDSK neither found nor corrected any errors. It gave a clean result.

Then, I decided to check the disc with AOMEI once again, and got this message (presented as text instead of a screenshot this time due to its longer length):

Checking (C: ), please wait a few seconds or minutes...-------------------------------------------------------------
Volume label is Windows.


Stage 1: Examining basic file system structure ...

414720 file records processed.


File verification completed.

11758 large file records processed.

0 bad file records processed.

Stage 2: Examining file name linkage ...
Index entry f_0019dd in index $I30 of file 67450 is incorrect.
Index entry TransportSecurity in index $I30 of file 126169 is incorrect.
Index entry TRANSP~1 in index $I30 of file 126169 is incorrect.
Index entry etilqs_3Hy1jlzOXbrisVu in index $I30 of file 333284 is incorrect.
Index entry ETILQS~3 in index $I30 of file 333284 is incorrect.
Index entry the-real-index in index $I30 of file 378443 is incorrect.
Index entry THE-RE~1 in index $I30 of file 378443 is incorrect.
Index entry a77cc5d7cc40a365_0 in index $I30 of file 378447 is incorrect.
Index entry A77CC5~1 in index $I30 of file 378447 is incorrect.
Index entry todelete_c85599bd7115f7eb in index $I30 of file 378447 is incorrect.
Index entry TODELE~1 in index $I30 of file 378447 is incorrect.
Index entry the-real-index in index $I30 of file 378450 is incorrect.
Index entry THE-RE~1 in index $I30 of file 378450 is incorrect.

551146 index entries processed.

Index verification completed.

Errors found. CHKDSK cannot continue in read-only mode.

Chkdsk has completed, but some errors were found in the partition.
You could use AOMEI Partition Assistant to fix it.

This time, AOMEI's results appeared to show that the errors had not only not disappeared, but had actually multiplied!

I then decided to (using Windows itself) go to "This PC - Windows (C: ) - Right Click - Properties - Tools - Error Checking" in order to run an ordinary read-only CHKDSK scan directly from Windows itself (which one would think is identical to the AOMEI read-only scan that found the errors). I got the following result:

CHKDSK_zpsxpjkz8l7.jpg


I clicked "Show Details", and was brought to the Event Viewer, which showed this information about the scan:

[Log Name: ApplicationSource: Chkdsk
Date: 6/7/2017 3:40:30 PM
Event ID: 26226
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: WINDOWS-SJ9IF72
Description:
Chkdsk was executed in scan mode on a volume snapshot.


Checking file system on C:
Volume label is Windows.


Stage 1: Examining basic file system structure ...

414720 file records processed.

File verification completed.

11758 large file records processed.

0 bad file records processed.

Stage 2: Examining file name linkage ...

551150 index entries processed.

Index verification completed.

Stage 3: Examining security descriptors ...

Security descriptor verification completed.

68216 data files processed.

CHKDSK is verifying Usn Journal...

55868600 USN bytes processed.

Usn Journal verification completed.

Windows has scanned the file system and found no problems.
No further action is required.

976146431 KB total disk space.
96322176 KB in 312243 files.
233432 KB in 68217 indexes.
569507 KB in use by the system.
65536 KB occupied by the log file.
879021316 KB available on disk.

4096 bytes in each allocation unit.
244036607 total allocation units on disk.
219755329 allocation units available on disk.

----------------------------------------------------------------------

Stage 1: Examining basic file system structure ...

Stage 2: Examining file name linkage ...

Stage 3: Examining security descriptors ...

Windows has scanned the file system and found no problems.
No further action is required.

As you can see, CHKDSK didn't find any issues.

Directly after running the above CHKDSK scan, I opened AOMEI and ran another scan with it. Sure enough, it found errors. Here are the results:

AOMEI%20again_zpsufeg4tkv.jpg


CHKDSK (when run straight from Windows, rather than through AOMEI) doesn't seem to find or fix any errors, and running both sfc /scannow and dism /Online /NoRestart /Cleanup-Image /CheckHealth didn't find any errors either. Only running a scan through AOMEI finds errors. And both of the two times that I let AOMEI trigger a restart CHKDSK session, each session appeared to complete successfully, but subsequent scans with AOMEI still showed errors (albeit never the exact same errors as before).

I found this all very bewildering. Every built-in Windows test appeared to come back clean. The errors only showed up when scanning through AOMEI. I searched online for errors similar to those reported by AOMEI, and found something very interesting.

Here's a thread on another forum about someone who encountered an issue eerily similar to my current problem (but while using a Glarysoft product instead of an AOMEI one):

https://www.wilderssecurity.com/threads/glarysoft-utilities.384471/

In one of the replies in that thread, one user quoted the following from a linked Microsoft page:

Chkdsk is prone to falsely reporting errors when in read-only mode, and it might report that a volume is corrupted even when no corruption is present. For example, Chkdsk might report corruption if NTFS modifies an area of the disk on behalf of a program at the same time Chkdsk is examining the same area. To verify a volume correctly, the volume must be in a static state, and the only way to guarantee that state is to lock the volume. Chkdsk locks the volume only when you specify the /f, /r, or /x parameters. Thus, you might need to run Chkdsk more than once for Chkdsk to complete all stages in read-only mode.

Now, when I run CHKDSK by itself (even in read-only mode) it finds no issues on my computer. But running it through AOMEI always finds some kind of problem.

Could the particular way that AOMEI is using CHKDSK be causing false positive error messages for my system?
 

hbenthow

Distinguished
Dec 11, 2014
276
1
18,795


In this case, that's Western Digital Data Lifeguard (as my system drive is a Western Digital drive).

After receiving your response, I ran a quick test with Data Lifeguard, which passed. However, I intend to start an extended test with it sometime within the next hour.


 
1. First of all it's absurd to think you need "extra" unallocated disk-space in the event "Windows later needs it to create extra recovery partitions" at some future date. Forget about that.

2. What your PRIMARY concern should be is to create & maintain comprehensive backups of your system on a reasonably current basis so that you always have the wherewithal to return your system to an up-to-date functional state in the event the system drive becomes defective or the OS becomes corrupt beyond "fixing".

3. You can achieve the above through systematic cloning of your drive(s) to one or more destination drives so that you always have at hand a comprehensive backup of your system which can be easily & quickly restored.

4. If you're unfamiliar with disk-cloning (or disk-imaging) do some Google research on the subject. There's a wealth of information just waiting for you to access.

5. If you suspect your HDD (I'm assuming it's a HDD) might be defective (although it's not clear why you think so), simply check it out with one of the many HDD diagnostic programs that are available, preferably the one you can probably freely obtain from the disk's manufacturer.
 

hbenthow

Distinguished
Dec 11, 2014
276
1
18,795


I was told by a person that is very experienced with Windows 10 at Ten Forums that Windows sometimes needs to create an extra recovery partition when upgrading from one version to another (such as th Anniversary Update or the Creators Update).

Please read this:

https://www.tenforums.com/bsod-crashes-debugging/85943-weird-behavior-restart-please-help-analyze-error-reports-5.html

2. What your PRIMARY concern should be is to create & maintain comprehensive backups of your system on a reasonably current basis so that you always have the wherewithal to return your system to an up-to-date functional state in the event the system drive becomes defective or the OS becomes corrupt beyond "fixing".

3. You can achieve the above through systematic cloning of your drive(s) to one or more destination drives so that you always have at hand a comprehensive backup of your system which can be easily & quickly restored.

4. If you're unfamiliar with disk-cloning (or disk-imaging) do some Google research on the subject. There's a wealth of information just waiting for you to access.

I already create Macrium system image backups on a regular basis.

5. If you suspect your HDD (I'm assuming it's a HDD) might be defective (although it's not clear why you think so), simply check it out with one of the many HDD diagnostic programs that are available, preferably the one you can probably freely obtain from the disk's manufacturer.


As soon as I finish writing this post, I'm going to run an extended test using Data Lifeguard.
 
As long as the WD Data Lifeguard program (hopefully) reports no problems with your HDD that will set your mind at ease.

It's good that you use the Macrium Reflect program on a regular basis for creating comprehensive backups of your system. We use a different program but Macrium has a good reputation from what I hear. Also, we prefer disk-cloning rather than disk-imaging as our backup strategy. But if you're more comfortable with disk-imaging, that's fine.

We do not believe there is *any* need for creating additional unallocated disk-space because of some connection with the recent release of the MS Win 10 Creators Update or for any other reason that we're aware of.
 

hbenthow

Distinguished
Dec 11, 2014
276
1
18,795


Here is the result:

Data%20Lifeguard%202_zpsnh3osdem.jpg


Do you know of any way to know for certain whether AOMEI's results are correct or false positives?

We do not believe there is *any* need for creating additional unallocated disk-space because of some connection with the recent release of the MS Win 10 Creators Update or for any other reason that we're aware of.

But what about what dalchina (of Ten Forums) said? According to him, the update process sometimes creates an extra recovery partition (I think he said something to the effect that it happens if the existing one is too small for the new update), and it has happened to him. Do you think that what happened to him is some kind of fluke?

Also, is creating extra unallocated space (by taking it out the C partition) at all dangerous?
 
We do work with that AOMEI partition management program (the pro version), but we've never come across the "false positive" situation you've outlined.

We have never come across that situation involving an OS update that couldn't be installed for the reason you related. It seems incredible to me that such a situation could (or would) arise in the future with a MS OS.

I can't envision any problem arising merely because a user's C partition was shrunk in order to create unallocated disk-space. The OS would not permit shrinking a partition if the shrunken portion contained necessary OS files.
 

hbenthow

Distinguished
Dec 11, 2014
276
1
18,795


Based on the information that I've provided, how likely do you believe it is that AOMEI's results are indeed false positives, and what further steps (if any) would you recommend that I take?

EDIT: By the way, which method of disc checking did you select when using AOMEI? The one that I used is the one selected in the photo below. Maybe selecting one of the other two options would have a different result (especially if the method that you used did not run the scan in read-only mode).

Check_zpsoefcyyvs.jpg


Also, I decided to try a small experiment. I opened up AOMEI and used it to check my C partition (just as before). I then saved the result (which unsurprisingly contained several error messages). Here's the result, with the errors highlighted in bold text:

Checking (C:), please wait a few seconds or minutes...
-------------------------------------------------------------
Volume label is Windows.

Stage 1: Examining basic file system structure ...

414720 file records processed.

File verification completed.

11790 large file records processed.


0 bad file records processed.


Stage 2: Examining file name linkage ...
Index entry 03d1e1da-f580-45d7-afdd-3598ed7cdba4_withdraw.xml in index $I30 of file 170100 is incorrect.
Index entry 03D1E1~2.XML in index $I30 of file 170100 is incorrect.
Index entry eac38764-c24d-4954-8096-70b6c0a53e08_show.xml in index $I30 of file 170100 is incorrect.
Index entry eac38764-c24d-4954-8096-70b6c0a53e08_withdraw.xml in index $I30 of file 170100 is incorrect.
Index entry EAC387~1.XML in index $I30 of file 170100 is incorrect.
Index entry EAC387~2.XML in index $I30 of file 170100 is incorrect.


548140 index entries processed.

Index verification completed.

Errors found. CHKDSK cannot continue in read-only mode.

Chkdsk has completed, but some errors were found in the partition.
You could use AOMEI Partition Assistant to fix it.

I then opened and closed two Internet browsers (browsing the Internet for a few seconds in one before closing it), then ran another AOMEI disc check immediately afterward. This check was performed less than two minutes after the first check. Here are the results:

Checking (C:), please wait a few seconds or minutes...
-------------------------------------------------------------
Volume label is Windows.

Stage 1: Examining basic file system structure ...

414720 file records processed.

File verification completed.

11790 large file records processed.


0 bad file records processed.


Stage 2: Examining file name linkage ...
An index entry from index $O of file 25 is incorrect.
An index entry from index $O of file 25 is incorrect.
An index entry from index $O of file 25 is incorrect.
An index entry from index $O of file 25 is incorrect.
An index entry from index $O of file 25 is incorrect.
An index entry from index $O of file 25 is incorrect.
An index entry from index $O of file 25 is incorrect.
An index entry from index $O of file 25 is incorrect.
Missing object id index entry or duplicate object id detected
for file record segment 118856.
Missing object id index entry or duplicate object id detected
for file record segment 118858.
Missing object id index entry or duplicate object id detected
for file record segment 118865.
Missing object id index entry or duplicate object id detected
for file record segment 118869.
Missing object id index entry or duplicate object id detected
for file record segment 118889.
Missing object id index entry or duplicate object id detected
for file record segment 118894.
Missing object id index entry or duplicate object id detected
for file record segment 118895.
Missing object id index entry or duplicate object id detected
for file record segment 121311.
Index entry 1496964152 in index $I30 of file 95081 is incorrect.
Index entry 149696~1 in index $I30 of file 95081 is incorrect.
Error detected in index $I30 for file 109472.
Index entry 093b765d-d33c-40c6-bb61-39d9a8300f1b.up_meta in index $I30 of file 109472 is incorrect.
Index entry 093b765d-d33c-40c6-bb61-39d9a8300f1b.up_meta_body in index $I30 of file 109472 is incorrect.
Index entry 093B76~1.UP_ in index $I30 of file 109472 is incorrect.
Index entry 093B76~2.UP_ in index $I30 of file 109472 is incorrect.
Index entry 112bb30a-82e7-4493-8fd5-511661361c22.up_meta in index $I30 of file 109472 is incorrect.
Index entry 112bb30a-82e7-4493-8fd5-511661361c22.up_meta_body in index $I30 of file 109472 is incorrect.
Index entry 112BB3~1.UP_ in index $I30 of file 109472 is incorrect.
Index entry 112BB3~2.UP_ in index $I30 of file 109472 is incorrect.
Index entry 356d92a4-9645-4416-9e61-a64dbb9bc85c.up_meta in index $I30 of file 109472 is incorrect.
Index entry 356d92a4-9645-4416-9e61-a64dbb9bc85c.up_meta_body in index $I30 of file 109472 is incorrect.
Index entry 356D92~1.UP_ in index $I30 of file 109472 is incorrect.
Index entry 356D92~2.UP_ in index $I30 of file 109472 is incorrect.
Index entry 5d56c867-0039-4455-84be-b905cfb23b98.up_meta in index $I30 of file 109472 is incorrect.
Index entry 5d56c867-0039-4455-84be-b905cfb23b98.up_meta_body in index $I30 of file 109472 is incorrect.
Index entry 5D56C8~1.UP_ in index $I30 of file 109472 is incorrect.
Index entry 5D56C8~2.UP_ in index $I30 of file 109472 is incorrect.
Index entry 701762f0-9a08-4405-a4a0-ecbcc6f16a33.up_meta in index $I30 of file 109472 is incorrect.
Index entry 701762f0-9a08-4405-a4a0-ecbcc6f16a33.up_meta_body in index $I30 of file 109472 is incorrect.
Index entry 701762~1.UP_ in index $I30 of file 109472 is incorrect.
Index entry 701762~2.UP_ in index $I30 of file 109472 is incorrect.
Index entry 9dcb2f15-3845-4087-adf4-3aaa8fa3e86a.up_meta in index $I30 of file 109472 is incorrect.
Index entry 9dcb2f15-3845-4087-adf4-3aaa8fa3e86a.up_meta_body in index $I30 of file 109472 is incorrect.
Index entry 9DCB2F~1.UP_ in index $I30 of file 109472 is incorrect.
Index entry 9DCB2F~2.UP_ in index $I30 of file 109472 is incorrect.
Index entry a51d90a2-9284-4fb9-9e4c-9f57683da112.up_meta in index $I30 of file 109472 is incorrect.
Index entry a51d90a2-9284-4fb9-9e4c-9f57683da112.up_meta_body in index $I30 of file 109472 is incorrect.
Index entry A51D90~1.UP_ in index $I30 of file 109472 is incorrect.
Index entry A51D90~2.UP_ in index $I30 of file 109472 is incorrect.
Index entry e4e0c6ed-32c8-4a06-a13d-2673707a0f97.up_meta in index $I30 of file 109472 is incorrect.
Index entry e4e0c6ed-32c8-4a06-a13d-2673707a0f97.up_meta_body in index $I30 of file 109472 is incorrect.
Index entry E4E0C6~1.UP_ in index $I30 of file 109472 is incorrect.
Index entry E4E0C6~2.UP_ in index $I30 of file 109472 is incorrect.
Index entry 1496964147 in index $I30 of file 124497 is incorrect.
Index entry 149696~1 in index $I30 of file 124497 is incorrect.
Index entry 1496964152 in index $I30 of file 203996 is incorrect.
Index entry 149696~1 in index $I30 of file 203996 is incorrect.


548134 index entries processed.

Index verification completed.

Errors found. CHKDSK cannot continue in read-only mode.

Chkdsk has completed, but some errors were found in the partition.
You could use AOMEI Partition Assistant to fix it.

As you can see, AOMEI gave a drastically different list of errors in two separate scans run within mere minutes of each other, with only about a minute of browser use in between.

I then opened up my main browser (the one that I'm using now) typed this message up until this sentence, then (with this browser window still open) opened up AOMEI and ran a third scan, with these results:

Checking (C:), please wait a few seconds or minutes...
-------------------------------------------------------------
Volume label is Windows.

Stage 1: Examining basic file system structure ...

414720 file records processed.

File verification completed.

11790 large file records processed.


0 bad file records processed.


Stage 2: Examining file name linkage ...
Index entry Local State in index $I30 of file 126169 is incorrect.
Index entry LOCALS~2 in index $I30 of file 126169 is incorrect.
Index entry ssdfp5488.0.2004048940 in index $I30 of file 126169 is incorrect.
Index entry SSDFP5~1.200 in index $I30 of file 126169 is incorrect.
Index entry 03d1e1da-f580-45d7-afdd-3598ed7cdba4_withdraw.xml in index $I30 of file 170100 is incorrect.
Index entry 03D1E1~2.XML in index $I30 of file 170100 is incorrect.
Index entry eac38764-c24d-4954-8096-70b6c0a53e08_withdraw.xml in index $I30 of file 170100 is incorrect.
Index entry EAC387~2.XML in index $I30 of file 170100 is incorrect.
Index entry the-real-index in index $I30 of file 241580 is incorrect.
Index entry THE-RE~1 in index $I30 of file 241580 is incorrect.


548088 index entries processed.

Index verification completed.

Errors found. CHKDSK cannot continue in read-only mode.

Chkdsk has completed, but some errors were found in the partition.
You could use AOMEI Partition Assistant to fix it.

This time, the errors are very different from those reported by the second scan, but have some entries that are identical to some of those from the first scan.

What do you make of all this?

Also, should I run a restart CHKDSK session manually using Command Prompt, then find the log file and post its results here?

If so, do you know the exact best string of letters to enter when running CHKDSK? I usually run chkdsk C: /f /r /x, but I think I saw a claim somewhere that it's not necessary to enter all three letters (f, r, and x) at once.

EDIT: I decided to look the the Windows Event Viewer to see if I could find the logs from the two times that AOMEI triggered a restart CHKDSK session in order to repair errors (as a result of me selecting the option to let AOMEI attempt to fix the errors it had found). Sure enough, I was able to find them. Here's the first one (with a certain part highlighted in bold text for emphasis):

Log Name: Application
Source: Microsoft-Windows-Wininit
Date: 6/7/2017 2:36:14 PM
Event ID: 1001
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: WINDOWS-SJ9IF72
Description:


Checking file system on C:
The type of the file system is NTFS.
Volume label is Windows.


A disk check has been scheduled.
Windows will now check the disk.

Stage 1: Examining basic file system structure ...
414720 file records processed.

File verification completed.
11759 large file records processed.

0 bad file records processed.


Stage 2: Examining file name linkage ...
551140 index entries processed.

Index verification completed.
0 unindexed files scanned.

0 unindexed files recovered to lost and found.


Stage 3: Examining security descriptors ...
Cleaning up 3222 unused index entries from index $SII of file 0x9.
Cleaning up 3222 unused index entries from index $SDH of file 0x9.
Cleaning up 3222 unused security descriptors.
Security descriptor verification completed.
68211 data files processed.


CHKDSK is verifying Usn Journal...
53683240 USN bytes processed.

Usn Journal verification completed.

Windows has scanned the file system and found no problems.
No further action is required.

976146431 KB total disk space.
50080888 KB in 312140 files.
233412 KB in 68212 indexes.
0 KB in bad sectors.
567075 KB in use by the system.
65536 KB occupied by the log file.
925265056 KB available on disk.

4096 bytes in each allocation unit.
244036607 total allocation units on disk.
231316264 allocation units available on disk.

Internal Info:
00 54 06 00 9f cd 05 00 09 a7 0b 00 00 00 00 00 .T..............
25 02 00 00 92 00 00 00 00 00 00 00 00 00 00 00 %...............

Windows has finished checking your disk.
Please wait while your computer restarts.

And here's the second:

Log Name: Application
Source: Microsoft-Windows-Wininit
Date: 6/7/2017 2:42:11 PM
Event ID: 1001
Task Category: None
Level: Information
Keywords: Classic
User: N/A
Computer: WINDOWS-SJ9IF72
Description:


Checking file system on C:
The type of the file system is NTFS.
Volume label is Windows.


A disk check has been scheduled.
Windows will now check the disk.

Stage 1: Examining basic file system structure ...
414720 file records processed.

File verification completed.
11758 large file records processed.

0 bad file records processed.


Stage 2: Examining file name linkage ...
551148 index entries processed.

Index verification completed.
0 unindexed files scanned.

0 unindexed files recovered to lost and found.


Stage 3: Examining security descriptors ...
Cleaning up 3 unused index entries from index $SII of file 0x9.
Cleaning up 3 unused index entries from index $SDH of file 0x9.
Cleaning up 3 unused security descriptors.
Security descriptor verification completed.
68215 data files processed.


CHKDSK is verifying Usn Journal...
53965232 USN bytes processed.

Usn Journal verification completed.

Windows has scanned the file system and found no problems.
No further action is required.

976146431 KB total disk space.
50080608 KB in 312156 files.
233420 KB in 68216 indexes.
0 KB in bad sectors.
567651 KB in use by the system.
65536 KB occupied by the log file.
925264752 KB available on disk.

4096 bytes in each allocation unit.
244036607 total allocation units on disk.
231316188 allocation units available on disk.

Internal Info:
00 54 06 00 b3 cd 05 00 25 a7 0b 00 00 00 00 00 .T......%.......
25 02 00 00 92 00 00 00 00 00 00 00 00 00 00 00 %...............

Windows has finished checking your disk.
Please wait while your computer restarts.

Is this information of any use? I noticed some of the data stated, "Cleaning up [insert number here] unused index entries from index [insert index name here] of file [insert filename here]". Might these entries have anything to do with the errors that AOMEI gives?
 

USAFRet

Titan
Moderator


No.
During an Update of that level....Anniversary, Creators, whatever is coming in the fall, next Spring....
You personally do not have to screw around with manually making extra recovery partitions for it to work.
If that were the case, 98% of all Windows 10 installs would magically die, because no one does that.

If a large Win 10 update needs it...it will adjust things as needed.
 

hbenthow

Distinguished
Dec 11, 2014
276
1
18,795


I think that you may have misunderstood me. I had no intention of manually creating an extra recovery partition. I planned on creating 700 MB of unallocated space (the amount recommended by dalchina of Ten Forums) in case Windows 10 itself ever needs to automatically create an extra recovery partition. I currently have only 1 MB of unallocated space, so there's no space for Windows 10 to create another recovery partition if it ever needs to (unless it only needs to create a 1 MB recovery partition).

However, while I do want to know for certain whether I need to create the extra unallocated space, my main focus right now is on finding out whether or not I have a serious corruption problem on my system (and if so, what I should do about it). The scan results from AOMEI have me extremely worried, and I still don't know the exact significance of the CHKDSK reports that I quoted in my last post (as I'm not very knowledgeable about how to interpret such results - the parts that I have bolded particularly worry me).
 

hbenthow

Distinguished
Dec 11, 2014
276
1
18,795


I suppose I could hold off on making such changes. As long as I keep making system image backups, a failed Windows Update wouldn't be disastrous. (I could just run a restore operation, then edit the partitions on the restored system before going through with the update again.)