WinXP does a CHKDSK on my D drive every bootup

[SunnyD]

I'm not kidding. Every time I turn the machine on, CHKDSK does a "consistency check" on my D: drive. Only the D: drive, never the C: drive. It never finds anything wrong tho.

Anybody else have this problem? Anybody know a solution to it? It's not really a major problem, it's just annoying.

SunnyD

 

[bacillus]

try looking in my computer under properties for D. you may well have scan disk at every boot box checked!

 

[SunnyD]

<< try looking in my computer under properties for D. you may well have scan disk at every boot box checked! >>



There is no such thing - even I know that.

 

[c0rv1d43]

Open a CMD prompt. Type "chkntfs" (no quotes), and hit the Enter key. If you are told that the drive is "dirty", then something is wrong with the file system or with some software that is accessing the drive. If you are told that the drive isn't dirty, then it's possible that the system isn't shutting down properly. That can actually happen without any apparent symptoms other than chkdsk running at boot time. However, I'd think that, if this were the case, chkdsk would also be run on your other hard drive(s). BTW, are your drives C: and D: just two partitions on a single hard drive, or are they separate physical drives? On which drive is WinXP installed? Are you multi-booting?

You can issue "chkntfs /d" at the CMD prompt to make certain that the system is using the default settings. In that case it only runs a disk check on a partition / disk at boot time IF the drive is dirty. (The "dirty bit" is set after a successful boot. It only gets turned off during a successful shutdown. If the system is not shut down "properly", then the dirty bit is left in place and the system runs a check on the partition / disk during the next startup.)

Type "chkntfs /?" to get info on the command. You can see that you would be able to set the drive to be excluded from checking. I don't recommend that. If WinXP thinks chkdsk should be run on the drive, it's probably right. Could be an incipient failure of the drive or some other issue with the OS / software, as I said before.

- Collin

Edit: Oops! Meant to suggest that you run "chkdsk /f /r d:" at a command prompt. You will be asked if you wish to run the check during the next boot. Confirm, then reboot. It's possible that there's a surface problem on drive D: that isn't getting fixed during the normal automatic autochk-iniciated chdksk executed at boot time. the "/r" switch forces surface checking and repair / "walling off" off damaged sectors on the drive so that they can't continue to cause trouble. This is a bit of a stretch, but it might be helpful.

 

[SunnyD]

Thanks Collin, I'll check into that later tonight.

My system specs, C: is master primary IDE, 1 partition, XP is on this drive, D: is the slave primary IDE, 1 partition, Win2K is on this drive. Setup is to multiboot, but I don't have any reason to, I never use 2K anymore.

I wonder if I scheduled a Win2K chkdsk and never rebooted into 2k to do it... hmm...

SunnyD

 

[c0rv1d43]

Hmmm. WinXP is on drive C:, which is drive 0 on the primary IDE channel. Win2K is on drive D:, which is drive 1 on the primary IDE channel. How did you go about installing them? This is a sort of unusual arrangement. I'm wondering if something has prevented the D: drive from being converted (properly?) to NTFS 5.1 and that's what is causing the behavior. How does the OS install history go? Am I correct in assuming that a third party partition management utility was used then?

Normally, you'd install Win2K first, then WinXP on a subsequent drive. At that point, the NTFS 5.0 Win2K partition should be converted to 5.1. But I imagine that some schemes for installing the operating systems in the order you describe might prevent that from happening, particularly if some utility were being used to hide Win2K from WinXP during the installation, or if something went wrong in the installation that effectively hid the partition at a critical moment.

Of course, if you're using FAT32 partitions, then all of this is out the window. I'm realizing, belatedly, that I never asked about that.

- Collin

 

[thebubala]

This happened to a friend of mine. I think this is how you fix it. Open a command prompt. Type chkntfs /x
I think that stops it from checking at boot. Tell me if it works.

 

[c0rv1d43]

Yes, I already covered that (by implication) in an earlier message. But I think SunnyD needs to find out why this is happening so that the cause can be corrected. Just using the /x switch will eliminate the symptom, but not the cause. It's better, I think, to take proper care of the file systme than to just stop the annoyance of autochk.exe doing its thing at boot time.

- Collin

 

[SunnyD]

Ooohhhhkay... here we go (taking a deep breath):

We'll go with C: being the Maxtor drive which has WinXP Pro, Primary Master...
D: being the WD drive which has Win2K Pro, Primary Slave...
And FYI, Secondary Master has a CDRW on it, nothing on slave.

What happened here was Win98 was originally on the Maxtor using FAT32 across 3 partitions, Win2K was on the WD using NTFS, set up for dual boot, everything was working properly. I then got sick of 98, so I fdisk'd the Maxtor and formatted it into 1 NTFS partition using the WinXP installer, and proceeded to install and setup WinXP on it.

After everything was installed, I reconstruced the boot.ini record to include Win2K, and disabled the menu. I can switch OS's via the system menu in either OS, as they both read the same boot.ini record.

Then, my problem was, everytime I ran CHKDSK, it would find errors here and there, but nothing major. There are no physical problems with either drive. I attribute this to WinXP.

I was sporadically getting chkdsk run for a "consistency check" on either drive, but not every bootup.

The only thing that has changed since then is I installed the newest VIA IDE miniport driver for WinXP.

Every bootup, it seems to run a consistency check on the WD drive.

Weird stuff.

NTFS is on both drives.

SunnyD

 

[c0rv1d43]

Okay, so the installation looks pretty much like I guessed -- except that you did not use any third party partition management software. That's good for me because it reduces the number of possible candidates for troublemaker, and I just don't have that much experience with them that type of stuff -- especially when used with Win2K or WinXP.

Is there anything else about this system that might be unusual? I've seen both Exchange Server and Active Directory cause behavior of this general type when an unsupported library has sneaked into the mix (usually because WFP has been defeated for some purpose). But, of course, that's looking past the obvious possibility that WinXP might not like being first in the partition order. If so, it wouldn't be the first MS OS to "feel" that way. AFAIK, Microsoft always recommends installing the earlier Windows versions on earlier partitions. I don't seem to recall the knowledge base being specific as to why, though I suspect it has something to do with the handling of boot-time chores and drive geometry issues. Could you post the contents of your boot.ini file? Also, did you try using the "chkdsk /f /r" command on drive d:. (Wouldn't hurt to run it on drive c: either, since you were getting sporadic running on both drives / partitions if I read your message correctly.)

I'm tempted to suggest running "fixboot /mbr" from the WinXP repair console (while booted from the CD), but I'm a little leary of that just because of the unusual configuration. Nonethless, it really shouldn't cause a problem because WinXP most certainly should have rewritten the MBR during installation anyway. In retrosepct, if I had to do what you were doing, I would have placed a small primary NTFS partition on the Maxtor drive, then let the rest of the drive contain the actual WinXP installation. In that way, the loader files would have been in C:, the Win2K installation would have been in D: on the second drive, and the WinXP installation would have been in drive E:. I suspect that might have worked better, though I have to admit that I have no hard data to back me up on that.

My alleged mind is sticking on the idea of this problem having something to do with the differences in the NTFS file systems of the two OSes. I find it interesting, for instance, that you had to "reconstruct" the boot.ini file at all. I would have though that Windows XP's setup procedure would have detected the Windows 2000 installation and included proper reference to it in the boot.ini file, though maybe it doesn't do this so well when the Win2K partition is on a "later" partition. Do you recall the contents of the boot.ini file as it existed immediately after the WinXP installation?

One other thing that might contain a clue -- did you check the system and application logs in the Event Viewer? I wonder if there might be a relevant error message or two in there?

I have to admit that this one has me flummoxed, which isn't really that hard to do. Since I usually do my system configurations pretty much by the book, working with unusual (in this sense) system configurations is something I'm not used to doing. I've done a lot of testing to destruction of both operating systems in the interests of being reasonably knowledgable about system recovery techniques, but I start with rather plain installations.

I hope something will shake loose. I'll stay tuned in the forlorn hope that I might be helpful. I should have a chance to do a little research on this later today.

- Collin

 

[SunnyD]

Ahh, I think I recall somethine that may cause a few problems now that I think about it.

I originally may have installed Win2K on the WD drive when it was Primary Master, and then changed it over after I got Win2K and removed Win98.

I still haven't taken much action, as I'm either sleeping or actually using the computer.

Still working on it.

And lastly, it's just a connundrum. This is an Eval version of WinXP (2600 final), so after I get the full version, Win2K will be wiped all together and XP will be the solo OS.

This is my current boot.ini:
[boot loader]
timeout=0
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINNT="Microsoft Windows 2000 Professional" /fastdetect

I'll try to get some time to work on it tonight. And then I'll get back to you.

Thanks!

SunnyD

 

[c0rv1d43]

<< I originally may have installed Win2K on the WD drive when it was Primary Master, and then changed it over after I got Win2K and removed Win98. >>



I'm assuming that the second time you say "Win2K" in the above sentence you mean WinXP. Hmmm. How did you get Win2K, and the installed apps, to know where they were, so to speak? In other words, if Win2K was installed on a partition named "C:", and then that drive / partition were moved to the slave position on that IDE channel that would surely confuse the OS, no? Maybe I'm not understanding the history.



<< And lastly, it's just a connundrum. This is an Eval version of WinXP (2600 final), so after I get the full version, Win2K will be wiped all together and XP will be the solo OS. >>



That's good. I'm sure you and the system will both be much happier that way.



<<
This is my current boot.ini:
[boot loader]
timeout=0
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)\WINNT="Microsoft Windows 2000 Professional" /fastdetect
>>



This appears to be in order judging from the information we've exchanged. I'd be very interested to know exactly what's causing this, but I suspect it may remain a bit of a mystery. I've seen all sorts of things cause sporadic or frequent autochecking, like out of kilter services (often third party services) that were not quitting access to the drive in question early enough in the shutdown process OR hard drive controller driver problems OR, in one case, a really weird pagefile configuration. If you solve it before it's time for the clean install of the new OS I hope you'll let us know what was going on. At least you can feel reasonably certain that you won't be seeing this problem afterward. (And, if you do see it after performing a standard installation, you can be pretty sure that the problem is with the hardware.)

Thanks for posing an interesting question. I only wish I could have been helpful. I'm going to keep this one in mind in case I ever come across something that might explain it.

- Collin