Dual-Booting XP and Windows 7 triggers a chkdsk?

B

BSchor

Member
Since installing Windows 7 on 4 of my PCs, I have been plagued by frequent (maybe 50% of the time) "One of your disks needs to be checked" messages when booting (or rebooting). This has happened on multiple PCs, multiple hardware and software (e.g. different anti-virus programs), several machine less than a year old (so unlikely to be truly failing disks). Every time ChkDsk runs, it finds nothing wrong. Sometimes it checks the "system disk" (where the OS lives), sometimes a "data disk" (a separate drive or partition that I use to relocate "My Documents".

One thing that all of my systems have in common that they are dual-boot configurations that use EasyBCD (which I really like, by the way). It occurs to me that this "slightly-non-traditional" Windows 7 configuration might either (a) reveal a subtle flaw in Win 7 that is letting the Dirty Bit get set when I close down Windows, or (b) be a bug that happens on boot-up (possibly even by EasyBCD!) that (falsely?) detects a Dirty Bit.

Here is the build scenario for all four PCs. First, all originated as Windows XP (SP3) machines, with Win XP on the system (and boot) partition, C:. Most machines had an additional data partition (D:smile: where I stored "My Documents", with the DVD being moved "out of the way" to M:.

Windows 7 was installed either on its own, separate hard drive (E:smile: or on another partition (also E:smile:. When Windows 7 begins running after the installation, it has rearranged the drive letters so that its drive is now C:, the DVD is D:, and the other partitions are E: and F:. I rearrange the drive letters so that the naming is consistent: C: is the "Current OS" system disk (either Windows 7 if I'm running Windows 7, or the original Windows XP disk), D: is the "data" partition, E: is the partition for the "Other OS", and M: is the DVD.

I now install EasyBCD (1.7.2) and rename the "Other Version of Windows" to "Windows XP".

Now I start to use these machines. I do occasionally go "back and forth" between the OS's, but typically I simply let the default Windows 7 boot (though I often hit <Enter> to speed up the boot process). Shortly after the Windows logo appears, I may get the ChkDsk screen, and have to wait for ChkDsk to run (and report no errors).

Before I installed Windows 7 on these machines (always using this dual-boot approach facilitated by EasyBCD, with Windows 7 being specifically not on the boot disk), I did not see ChkDsk run. Now, as I stated, it is not an infrequent occurance. It does not seem to matter too much whether I'm mainly booting Windows 7 (as is the case with the PC I'm using right now), or whether I boot into Windows XP (which I just did on another PC, only to again have ChkDsk do it's thing, and find nothing). Different PCs, different manufacturers, different hard drives, sometimes multiple hard drives (one OS on one, one on another), different anti-virus software (Sophos, Norton), one laptop and three desktops. The things that are the same are: same version of Windows XP, same version of Windows 7, installed in same manner (first XP, then Windows 7 on a separate partition, then EasyBCD 1.7.2 to manage the dual-boot).

The "acid test", of course, would be to simply "start over" and rebuild one system, putting Windows 7 alone on the boot disk. However, as these machines are all being used for software development, and I need (on occasion) to go back to the original XP configuration (virtual XP won't work for me here), I'm not able to do this yet.

Has anyone else seen this behavior with dual-boot systems? Is it possible that EasyBCD is interacting with Windows somehow so that whatever the "Dirty Bit" is that signals ChkDsk to run, it is being set inappropriately?

BS
 
Last edited:
We had a member here some years ago that had a similar problem - booting into one of XP or Vista would corrupt the other.

He came here looking for a solution and asking if *installing* EasyBCD would help. Unfortunately, if I recall correctly, we were not able to solve the actual issue - it's (one of many) Microsoft bugs.

I get that you can't run XP in a VM at the moment - but how about this: does your XP need to see your Windows 7 partition? Are you sharing data between them? Because you can just hide the other partition entirely from the OS, thereby preventing one from corrupting the other :smile:
 
I don't think this is a question of one OS "corrupting" the other. Example -- this particular dual-boot PC has only booted Windows 7 the last 10-12 reboots. The only partitions that I am presently accessing are C: (where the Windows 7 files, Program Files, etc. are stored) and D: (where "My Documents" are stored). The partition with Windows XP is "visible", but not being accessed (and I haven't run Windows XP in a dozen reboots). Yet last week, when I rebooted, I got a ChkDsk on D: (the "data" disk).

When I do use both OS's, I do "share data" between them because all of the data are on the common D: partition. Each OS, of course, has its own set of "programs" installed in its own set of "Program Files" on its own C: drive.

Too bad I don't have yet another PC -- I'm really 90% certain that the underlying issue involves dual-booting, in particular having the "boot" and the "system" partitions being different. The only question is what role, if any, does the boot manager and/or EasyBCD play in this situation? Clearly, if I had a dual-boot system without EasyBCD, and saw the same problem, then it would clearly be a MicroSoft issue, but if such a dual-boot was "clean", then one has to ask about EasyBCD ...

BS
 
There is no such thing as a "clean dual-boot" or an "EasyBCD dual-boot" when we're talking about dual-booting Windows & Windows.

In such a case, EasyBCD just takes the configuration you want and tells *Microsoft's software* to implement it.
 
BS, You seem to have a fundamental misunderstanding about the nature of EasyBCD.
It is not a boot manager.
It takes absolutely no part in the booting or running of your system.
It's a tool you can use to manipulate the contents of the Windows 7 BCD
It's provided so you don't have to learn the syntax of the command line utility BCDedit, which is the only facility MS gives you.
Installing it on your system does nothing (except use a little space).
If you run it, it does only what you tell it to. In your case it would seem, just an edit of the name field of one of the BCD entries.
That's not executable code, just a data field which is accessed by MS bootmgr to display on your boot menu.

Incidentally, I've been running W7 as my main system since September, (Betas in test before that) and I multi-boot it with Vista SP2, XP SP3 and Ubuntu 9.10, and I've never seen a chkdsk, so you're not seeing a problem that's inherent to W7.

There are two possible sources of contention between XP and Longhorn systems. First, if one of the systems is not C:, but can see another OS called C: (not a problem for the OS, but confuses the hell out of certain ubiquitous 3rd party apps), which you seem to have avoided. Second, the well documented propensity of XP to destroy the restore points and backups of the later OSs.

To prevent the latter, you should ensure that each OS only has system restore enabled for itself and any partition containing installed apps. Turn it off for the other OS and shared data (you cannot share apps), then run this registry hack on the XP system, and check that you are unable to access folders and files on W7 with Explorer.

If that doesn't work for you (it mostly does, but not for everyone (me included)), then you can always use NeoSmart's HnS to hide W7 from XP dynamically at boot time.
 
Try this:

chkntfs /D

That should set everything back to default state. Upon reboot it may run once, but reboot again and see if it'll stop.
 
Back
Top