Windows 10 Flaw Could Corrupt Drive

  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!

    /Steve.
  • Larger Font Styles
    Guest:

    Just a quick heads-up that I've implemented larger font variants of our forum's light and dark page styles. You can select the style of your choice by scrolling to the footer of any page here. This might be more comfortable (it is for me) for those with high-resolution displays where the standard fonts, while permitting a lot of text to fit on the screen, might be uncomfortably small.

    (You can permanently dismiss this notification with the “X” at the upper right.)

    /Steve.

Intuit

Active member
Dec 27, 2020
34
7

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)