Windows 10 Flaw Could Corrupt Drive

  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

    /Steve.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)

Intuit

Well-known member
Dec 27, 2020
80
21

It seems that is being misreported.

It's been the case for quite some time that Windows automatically runs a scan whenever that message is generated; whether the message is legitimately generated or not. (Might be a Task Scheduler item that has an event defined as a trigger.) They seem to be under the assumption that the appearance of the message is validation that corruption has actually occurred. I opened a user privileged command prompt and typed "cd c:\:$i30:$bitmap". The corruption message appeared. I manually restarted the system, watched ChkDsk run, it rebooted into Windows as normal. Ran EventVwr.MSC, searched for "chkdsk" and confirmed that Windows has found no problems with the file system. Tried writing to the NTFS metadata file and of course access is denied; no such message about corruption or other was generated.


================================================================================


Unrelated, we've seen a number of odd occurrences with NTFS bug checks lately on 1809 systems with healthy HDDs.
Not sure whether it's actually ChkDsk that causes it though. That's something I'll be looking into. But to note, these systems are running third-party drive encryption which is known to be behind a long standing freezing issue (resulting from a cessation of all drive activity) on certain older Intel chipsets. The amount of time it takes for a freeze to occur on the systems that experience it, seems to be linked to the amount of disk activity. More disk activity, may result with more frequent freezing. One or two restarts a day may be required to workaround/avoid the issue. OS updates generate so much drive activity, there may not be a way to avoid a freeze, other than just decrypting the drive. The encryption software may have some incompatibility with post 1703 or 1709 Windows releases. (vendor has been made aware and may have a fix)