Chkdsk /R stalls requiring keystroke

For the past maybe 2 years, I have been noticing that Chkdsk, especially Chkdsk /R, will stall numerous times while checking a disk, during (stage 4 of 5) "verifying file data".
The PC red light remains on indicating that activity is occurring, but in fact nothing is happening.
Windows Task Manager display for Chkdsk.exe I/O Read Bytes has stopped increasing, and only begins increasing when the user selects the CMD.exe window within which the Chkdsk is running, then hits return.
This is a serious bug jeopardizing the users' data and thus should be top priority to fix at Microsoft. Why does this bug continue to exist ?
This Windows Vista 64 Ultimate SP2, //Q6600//12 GBytes Sdram// checking a 950 GByte partition on a 2TB physical drive separate from the boot drive.
When will this Chkdsk bug be fixed ?

I'd report it directly on MS site if you haven't already instead of hoping it filters back from here.

I did that 2 years ago. Since then I have reinstalled Windows Vista 64 several times and have encountered the same Chkdsk bug.

I don't think I've ever run chkdsk /R. Takes way too long. Probably why it's never tested.

Chkdsk /R is essential to check every sector on the hard disk partition for readability, retrying many times when necessary, and when a sector becomes hard to read, it is supposed to mark that sector as a Bad Sector and if any of your precious data resides on that sector, it is supposed to move your data to another healthy sector before it becomes completely unreadable, and again mark the Bad Sector.
For at least 6 years, Microsoft OS development capabilities have been in sharp decline, and when I installed Vista 64 for the first time about 2 years ago (after long usage of Windows XP which was MS's last competent and worthy OS work) , I noticed this Chkdsk /R Vista 64 problem.
Since posting this bug report today, I tried Chkdsk /R on Windows 7 installed on a different partition.
That ran for maybe 20 minutes and then hung the PC, forcing reboot.
After rebooting, I found a Computer_Management/Windows_Logs/Event/System entry which stated that:
"Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: chkdsk.exe (6120) consumed 7595696128 bytes,..."
Chkdsk should never be consuming 7 GBytes of Sdram when it runs.

I understand the theory. But I've never owned a PC long enough for a drive to fail. And I kept my 486 for like 8 years. Chkdsk ain't the greatest way to run diagnostics on a drive. For one thing, even if you have a drive in a docking station that just holds data, if you try to run chkdsk with /f or /r it will tell you it is in use and can only be run with a reboot. That's ridiculous! The system isn't even running off it. Better off just to get the diagnostic from the manufacturer of the HD and run it.

Running 3 day scans for TB drives is just adding wear and tear. Run a diagnostic and if it's showing high number of retries get another drive and get your data off the current one before it's too late.

You should be able to Command_Prompt//Chkdsk any drive partition other than the currently active running boot partition.
The obstacles to that are sometimes you are running an application which is using that drive and it must be terminated to Chkdsk that partition.
Another problem is that Windows sometimes will put Pagefile.sys's on drive partitions other than the drive partition which contains the active running \Windows directory. Chkdsk cannot perform on a drive partition which has an active running pagefile.sys .

As an extra bug detail, I tried yesterday running the Windows 7 Chkdsk after changing its performance configuration to implement a pagefile.sys and it did run properly, to completion without crashing or stalling.
I had disabled the Windows 7 pagefile.sys recently with the increased 12 GBytes Sdram. Everything else runs fine, except Chkdsk.
Vista chkdsk was running with a normal approx. 12 GByte pagefile.sys .
Since I watch and record HD TV on the PC, there is constant storage and deletions of large amounts of data on the drives in the PC.

These large Samsungs are extremely resilient, and after maybe 2 years, these are the first Bad Sectors to appear.
In my experience there will be another year of this beating before they fail finally.

You should be able to Command_Prompt//Chkdsk any drive partition other than the currently active running boot partition.

Click to expand...

I just tried it with automatically fix errors and it did complete the chkdsk. The cause, I see now, is I used to automatically share a folder from the drives in the docking stations. Now I don't. At least that's solved.

I haven't done Linux since ext3 file system. But that seems to be trouble free by comparison. I got a notice on boot after a rare hard lock, that the journal had a problem. Do I want to fix it? Yes I do. Hit Enter and 2 seconds later all is well.