How is this possible?

[Ichinisan]

I've seen this so many times that it's really starting to bother me. With most errors on the system boot drive, ChkDsk demands that I schedule a disk check and reboot the system. However, I sometimes specifically want to scan in read-only mode, so I type "CHKDSK" from the command line without the "/F" switch parameter.

Many times, this is what I will see:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Administrator>chkdsk
The type of the file system is NTFS.

WARNING! F parameter not specified.
Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...
File verification completed.
CHKDSK is verifying indexes (stage 2 of 3)...
Deleting index entry CHKDSK.EXE-0C6DCB55.pf in index $I30 of file 10203.
Deleting index entry CHKDSK~1.PF in index $I30 of file 10203.
Index verification completed.

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

C:\Documents and Settings\Administrator>

Changing the contents of a drive with errors can compormise your ability to recover the data with professional tools. It is *really* bad that the chkdsk utility makes changes to the drive when it is supposedly in "read-only mode".

 

[dclive]

Originally posted by: Ichinisan
I've seen this so many times that it's really starting to bother me. With most errors on the system boot drive, ChkDsk demands that I schedule a disk check and reboot the system. However, I sometimes specifically want to scan in read-only mode, so I type "CHKDSK" from the command line without the "/F" switch parameter.

Many times, this is what I will see:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Administrator>chkdsk
The type of the file system is NTFS.

WARNING! F parameter not specified.
Running CHKDSK in read-only mode.

CHKDSK is verifying files (stage 1 of 3)...
File verification completed.
CHKDSK is verifying indexes (stage 2 of 3)...
Deleting index entry CHKDSK.EXE-0C6DCB55.pf in index $I30 of file 10203.
Deleting index entry CHKDSK~1.PF in index $I30 of file 10203.
Index verification completed.

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

C:\Documents and Settings\Administrator>

Changing the contents of a drive with errors can compormise your ability to recover the data with professional tools. It is *really* bad that the chkdsk utility makes changes to the drive when it is supposedly in "read-only mode".

Hmm.... it's deleting 2 prefetch files that are put there when you run a new executable, thereby putting your system back to the same place it was before you ran CHKDSK.

 

[kylef]

I have seen this too, but it only happens during stage 2 (verifying indices).

From what I understand, "read-only" mode does not mean that it won't fix anything: it means that it won't obtain a write lock on your entire drive. This allows you to check some things in the background while you keep doing normal work on that drive.

Contrast that with fixing bad clusters/sectors (stage 3), where Chkdsk must obtain a lock on your entire drive. This effectively means the drive must be unmounted. That's typically why you must reboot. (I believe there is an option that lets you force the drive to be unmounted right now, but that invalidates all open file handles to that drive, which may be a very bad idea.)

 

[bsobel]

Changing the contents of a drive with errors can compormise your ability to recover the data with professional tools. It is *really* bad that the chkdsk utility makes changes to the drive when it is supposedly in "read-only mode".

Actually, as I recall it's not. It's reporting what it would do if in write mode. I'd have to dig back in to verify is that where true (its been awhile). The errors you are seeing are due to the fact that the OS is continuing to run and the file system is locked (e.g. your modifying it while running chkdsk).

Try running vrfydsk.exe instead (from the 2003/XP resource kit, free download from MS). That takes a volume snapshot and then runs chkdsk against the snapshot. The snapshot is consistent so these phantom errors shouldn't happen.

Bill

 

[VirtualLarry]

Originally posted by: Ichinisan
Changing the contents of a drive with errors can compormise your ability to recover the data with professional tools. It is *really* bad that the chkdsk utility makes changes to the drive when it is supposedly in "read-only mode".

Reminds me of the operation of the WD DataLifeguard tools 2.6 DOS-based boot-disk. It comes with embedded "BackWeb" spyware, which is automatically installed. It does so *before* you actually do the disk-scan. It boggles my mind that such a low-level diagnostic tool that would ordinarily be used in the cases of potentially needing data-recovery, would be allowed to do such a thing, potentially destroying chances of recovering the customers' data, simply because of the desires of their marketing dept. to "pull one over" on the user. DataLifeguard 2.8 was only slightly better, you have to be very careful when going through the various prompts, there is one that will allow you to bypass installing it, if you hit 'N' in response to the prompt, but any other key triggers installation, and it doesn't clear the keyboard buffer when prompting.

Then again, simply booting a Win98se boot disk can do similar things, since it writes files to the root dir, and updates some filesystem boot-record data as well.

A DOS 6-era boot-disk is necessary for use with diagnostic tools, if you don't want to write to the drive at all.

PS. CHKDSK.EXE is crap, at least in W2K. It cannot detect/fix some errors, that Win98se's SCANDISK.EXE does find, and fix. I don't know if MS enhanced CHKDSK for XP or not.

 

[kylef]

Originally posted by: VirtualLarry
PS. CHKDSK.EXE is crap, at least in W2K. It cannot detect/fix some errors, that Win98se's SCANDISK.EXE does find, and fix. I don't know if MS enhanced CHKDSK for XP or not.

I don't know how we got onto the subject of Scandisk... Scandisk doesn't even run on NTFS, which makes it pretty useless for 90% of W2k/XP users. It was great on Fat32, which is why MS used that by default for boot scans.

But for NTFS, Chkdsk works quite well.

 

[NogginBoink]

Chkdsk can indeed correct some, but not all, kinds of disk corruption in readonly mode.

 

[VirtualLarry]

Originally posted by: kylef
I don't know how we got onto the subject of Scandisk... Scandisk doesn't even run on NTFS, which makes it pretty useless for 90% of W2k/XP users. It was great on Fat32, which is why MS used that by default for boot scans. But for NTFS, Chkdsk works quite well.

Sorry, I was just mentioning it in the context of apparent deficiencies in CHKDSK, based on my own experiences with FAT32. It just seems strange to me, that MS would use a tool for boot-time filesystem-checking (at least on FAT32), that isn't even capable of fully diagnosing/fixing filesystem errors, when they have a much better tool available to them, that is shipped with a prior OS version. It kind of boggles my mind, really. It's also disturbing, when I see that CHKDSK runs after a system crash, and it corrects things, but it doesn't find/correct everything, and I have to boot to Win98se to run SCANDISK besides, to stave off futher potential filesystem corruption.

 

[kylef]

Originally posted by: VirtualLarry
[Sorry, I was just mentioning it in the context of apparent deficiencies in CHKDSK, based on my own experiences with FAT32. It just seems strange to me, that MS would use a tool for boot-time filesystem-checking (at least on FAT32), that isn't even capable of fully diagnosing/fixing filesystem errors, when they have a much better tool available to them, that is shipped with a prior OS version. It kind of boggles my mind, really. It's also disturbing, when I see that CHKDSK runs after a system crash, and it corrects things, but it doesn't find/correct everything, and I have to boot to Win98se to run SCANDISK besides, to stave off futher potential filesystem corruption.

IIRC, Scandisk talks to the disk controller directly, bypassing the OS. This is a big no-no under NT. Older DOS apps that try to do this on NT fail immediately. Win9X was more tolerant of such apps.

I'm betting that re-writing Scandisk to work for NT was not seen as a good option since it would be a ground-up rewrite, and Fat32 is not the recommended filesystem for NT. A boot disk to run the old Scandisk was seen as an acceptable compromise.

I doubt much development effort has gone into Fat32 support for several years now. Probably not since the year 2000.

 

[VirtualLarry]

Originally posted by: kylef
IIRC, Scandisk talks to the disk controller directly, bypassing the OS.

I don't believe that to be true, that doesn't make much sense. Also, it supports my 160GB drive as a single FAT32 parition, which would only really be possible if it simply used the BIOS disk APIs to read/write sectors, because it would require the assistance of my Promise controller's BIOS to "speak" 48-bit LBA.

Originally posted by: kylef
This is a big no-no under NT. Older DOS apps that try to do this on NT fail immediately. Win9X was more tolerant of such apps. I'm betting that re-writing Scandisk to work for NT was not seen as a good option since it would be a ground-up rewrite, and Fat32 is not the recommended filesystem for NT.

Well, it shouldn't have been too difficult a re-write. Probably more UI effort involved than anything else. (Perhaps I assume too much, perhaps it was actually part of the Central Point Software tools that MS licensed, the UI does bear a certain resemblance to the old MS-DOS 6.22 virus-scanner as well.)

Originally posted by: kylef
A boot disk to run the old Scandisk was seen as an acceptable compromise. I doubt much development effort has gone into Fat32 support for several years now. Probably not since the year 2000.

That's probably quite true, FAT32 under NT has always been a bit of a bastard stepchild in terms of "proper" support. However, that doesn't excuse MS's lacking and defective support for FAT32 using CHKDSK though. I have a feeling that since NT4 included CHKDSK, and then Win98 included SCANDISK (in addition to the legacy CHKDSK, which prints a message to use SCANDISK instead next time), and then W2K carried over from NT4, they just kept using CHKDSK, and never really "enhanced" it to fully support FAT32, when they added that to W2K. Kind of disturbing, actually, I wonder if there aren't more problems with CHKDKS's FAT32 support lurking in the wings somewhere.

It's bad enough that W2K SP2's Disk Management tool, when asked to create a FAT32 partition, seems to randomly do so using a FAT16 partition-code, which really, really screws older non-NT OSes up quite a bit. Thankfully Norton DiskEdit to the rescue fixes that up right quick with a partition-table sector-edit, but still.

 

[Nothinman]

That's probably quite true, FAT32 under NT has always been a bit of a bastard stepchild in terms of "proper" support

That's because they want you to use NTFS since FAT is ass. I'm sure it's the same motivation that caused them to limit the size of FAT volumes that disk manager will create to 32G or whatever it was.

I wouldn't be surprised if 'fixing chkdsk to work better on FAT volumes' was right below 'update the NetWare client to support IP' on the Windows developer's TODO list.

 

[kylef]

Originally posted by: VirtualLarry

Originally posted by: kylef
IIRC, Scandisk talks to the disk controller directly, bypassing the OS.

I don't believe that to be true, that doesn't make much sense. Also, it supports my 160GB drive as a single FAT32 parition, which would only really be possible if it simply used the BIOS disk APIs to read/write sectors, because it would require the assistance of my Promise controller's BIOS to "speak" 48-bit LBA.

Making BIOS calls is also illegal in Win32 apps running under NT.

Any attempt to write directly to hardware (BIOS or otherwise) will be trapped by the NT kernel and the app will be terminated. This has been the case since NT 3.1, and continues to be the case with XP.

 

[bsobel]

I don't believe that to be true, that doesn't make much sense. Also, it supports my 160GB drive as a single FAT32 parition, which would only really be possible if it simply used the BIOS disk APIs to read/write sectors, because it would require the assistance of my Promise controller's BIOS to "speak" 48-bit LBA.

Right idea, wrong explanation. It doesn't talk to the hardware disk controller directly, just to the block device. However, it needs to take exclusive file system locks, something that the NT family doesn't allow you to do without dismounting the file system.

(Perhaps I assume too much, perhaps it was actually part of the Central Point Software tools that MS licensed, the UI does bear a certain resemblance to the old MS-DOS 6.22 virus-scanner as well.)

It was licensed from Symantec, not CPS (the file system scanner, your correct that the anti-virus was licensed from CPS).

Bill

 

[VirtualLarry]

Originally posted by: bsobel

(Perhaps I assume too much, perhaps it was actually part of the Central Point Software tools that MS licensed, the UI does bear a certain resemblance to the old MS-DOS 6.22 virus-scanner as well.)

It was licensed from Symantec, not CPS (the file system scanner, your correct that the anti-virus was licensed from CPS).

Hmm. Are you sure about that? I thought that they both debuted in MS-DOS 6.2x, and both were licensed from CPS, which Symantec later bought out or something.

So who did the undelete/unformat utility for MS-DOS 6.xx then?

 

[VirtualLarry]

Originally posted by: kylef

Originally posted by: VirtualLarry

Originally posted by: kylef
IIRC, Scandisk talks to the disk controller directly, bypassing the OS.

I don't believe that to be true, that doesn't make much sense. Also, it supports my 160GB drive as a single FAT32 parition, which would only really be possible if it simply used the BIOS disk APIs to read/write sectors, because it would require the assistance of my Promise controller's BIOS to "speak" 48-bit LBA.

Making BIOS calls is also illegal in Win32 apps running under NT.
Any attempt to write directly to hardware (BIOS or otherwise) will be trapped by the NT kernel and the app will be terminated. This has been the case since NT 3.1, and continues to be the case with XP.

Apparently both you and Bill both missed my point. It was simply that it shouldn't be all that hard to transplant the actual logic from the real-mode DOS SCANDISK.EXE, which used BIOS calls to access the HD (not direct hardware access), and replace those BIOS calls with the equivalent Win32 DeviceIOControl stuff to directly access block-device disk sectors. Yes Bill, I know it would have to acquire exclusive access to the drive, just like CHKDSK already does - it would have to do those sorts of scans at boot-time, which was basically the point. The more that I think about it though, perhaps it was actually written in real-mode x86 ASM not C, so it would have been a bit more work than just a couple of disk-access I/O tweaks and a re-compile. I could see why they didn't feel it was worthwhile re-engineering for W2K it if that were true.

Btw, plenty of real-mode DOS apps that access the BIOS do work fine in NT, but of course that is under NTVDM that emulates the BIOS APIs, and not a "proper" 32-bit Win32 app, which doesn't support them. (I seem to recall that being an issue with some of the Borland language tools, making some interrupt-based calls that were supported by the DOS-extender built into Win9x, but they bombed hard on NT because of that very reason.)

 

[bsobel]

Hmm. Are you sure about that? I thought that they both debuted in MS-DOS 6.2x, and both were licensed from CPS, which Symantec later bought out or something.

Positive, I used to write Norton Utilities, I was there when we licensed the tools to MS. You'll notice the copyright information does reference Symantec (for checkdisk and defrag).

Apparently both you and Bill both missed my point.

I didn't miss your point, I wasn't even addressing it, just correcting Kylef's comment.

It was simply that it shouldn't be all that hard to transplant the actual logic from the real-mode DOS SCANDISK.EXE, which used BIOS calls to access the HD (not direct hardware access), and replace those BIOS calls with the equivalent Win32 DeviceIOControl stuff to directly access block-device disk sectors. /q]

Well, if you want to be technical about it, you mean to call the equivalent native NT api's to directly access the block device stuff, at the point that autocheck runs Win32 isn't up yet.

The more that I think about it though, perhaps it was actually written in real-mode x86 ASM not C, so it would have been a bit more work than just a couple of disk-access I/O tweaks and a re-compile. I could see why they didn't feel it was worthwhile re-engineering for W2K it if that were true.

For what it's worth, it's not, it's C code. Don't quote me, it's been a very very long time, but I think there license allowed them to pull the code forward into dos derivaties (e.g. Windows 3.1, 9x) but may have precluded the code from being ported to NT. If so, MS would have had to write it from the ground up.

Bill