Windows 10 20H2: ChkDsk damages file system on SSDs with Update KB4592438 installed

[German]In Windows 10 20H2 with installed cumulative update KB4592438, chkdsk causes massive issues. It destroys the file system during a disk check on SSDs, so Windows 10 can’t start after a reboot. Here is some information about the problem and the affected Windows 10 build.

I’ve been contacted by several German blog readers by email and via comments within my German blog (thanks for that). They all pointing to a strange bug, obviously brought to systems with cumulative update KB4592438.

The problem with ChkDsk

The problem was initially described by Nero24 in the German planet3dnow.de forum (the affected person contacted me via email). In a school, several systems with Windows 10 20H2 already installed should be manually updates to the current update status (Windows and Office updates). The administrator, who did the manual update install, decided to execute the following command after finishing the update installation:

chkdsk c: /f

The intension is to check the Windows drive for damage and (with the /f switch) immediately perform a repair. In the scenario described above, things went very badly wrong. The affected person had seven systems, that can no longer boot after the file system check including repair. The guy was able to prevent the re-boot from the other computers, after the seventh machine failed.

Stop error NTFS File System, Source: planet3dnow.de-Forum

The blue screen shown in the screenshot above appears with the stop code NTFS File System (it shows a NTFS FILE SYSTEM stop code, see here for an English version of the BSOD). The affected person was able to observe this on seven computers with Windows 10 20H2. When analyzing the affected disks (SSDs) on a working system, it could be determined that the logical Windows drive on the disk was detected only as a RAW partition. The /f option of chkdsk probably destroyed the NTFS file system.

Further analysis of the RAW partition with chkdsk in offline mode revealed errors with a corrupted ‘file 9’ and an error in the BITMAP attribute of the Master File Table. These could be corrected with chkdsk in offline mode. After that, the systems booted again after installing the SSD as a Windows disk in the original PCs.

Error analysis and condition

In the planet3dnow.de forum, the affected person gives some characteristics of the affected devices. Here is the relevant excerpt:

They are all Kaveri systems with ASUS A68HM-PLUS motherboard and Kingston SATA SSD running in AHCI mode with the Windows standard AHCI driver. At first I suspected a faulty TRIM behavior in combination with chkdsk and the fact that the system reboots immediately after completion.

But they are not identical SSDs. Most are Kingston A400s with Phison S11 controllers and 2D TLC NANDs, but there was also a Kingston V300 with Sandforce controller and MLC NANDs, which certainly has a completely different TRIM behavior than the Phison-fired ones.

Whether the hardware has an influence is currently unclear. Within my German blog a user reported, that the error didn’t occur on two systems with hard disks, but a 3rd system with a M2.SSD caused the BSOD as expected. The case was summarized on German site planet3dnow.de in this article. There, the affected person writes that it affects build 19042.685 of Windows 10 20H2. The cumulative update KB4592438 should be the culprit. The blog reader wrote to me:

Have you heard anything similar from your community in this regard? In the forum thread above, we were able to narrow it down quite well where it occurs and where not, but I would still be interested in external observations. 

After publishing the German edition of this blog post, several blog readers confirmed this bug. If you have further insights, please drop a comment. I will try to forward a link to this blog post to Microsoft’s developers.