[Not a Bug] Inconsisent rebooting

Yikes!!! After several days of trying to find a pattern, have not discovered one. One an XP partition begins to reboot after getting to the Welcome screen, it will continue to do so from then on. If I then boot into a Windows 7 partition and from there restart and boot into an XP partition it successfully boots for one or more times, but never more than 3 times, then the rebooting begins during the Welcome screen. This inconsistency occurs whether using ntldr or easyldr.

I wonder if something is change the files during booting?

I have also have a question on the boot.ini files. I will attach the appropriate files to this reply. When I look at the boot.ini, for any of the 3 XP partitions, the partitions for rdisk(1) seem to be off by one, when compared to the computer management chart. However booting using this boot.ini works and find the correct C: drive when I can get the partition to boot. If I manually edit the boot.ini to match the computer management chart, then booting from rdisk(1) partition(1) actual boots from the drive shown as rdisk(1) partition(2). If I manually edit the boot.ini to match the computer management chart, then booting from rdisk(1) partition(2) returns a boot error. If I use a tool like GPARTED, it shows the partitions as hbb1: W7Main; hdb2: XPBkup1; hdb3: XPBkup2. It seems that the Computer Management chart is misleading, or I do not understand it.

Another thing the Computer Management chart show is XPMAIN is the active partition, which I expect, but W7Main is labelled boot.

Any help or information would be very helpful. If nothing abnormal is discovered, I will completely rebuild all 7 partitions and look for an alternative boot manager.

Again, thanks so much for your time and efforts.
 

Attachments

  • XPMainBootIniO.txt
    499 bytes · Views: 1
  • DiskMgtXPMain.jpg
    DiskMgtXPMain.jpg
    169.8 KB · Views: 5
  • EasyBCDSettings01.txt
    875 bytes · Views: 1
"boot" in Disk Management means "this is the system you're running at this moment"
It only shows in Vista/7, because XP doesn't display the full set of flags you'll see from Vista/7
The auto-generated boot.ini is correct. Don't go altering it.
The reason why the auto-gen code was written is precisely because you can't tell by looking at Disk Management what the BIOS ARC path values are.
NTLDR gets its partition number from the BIOS, which enumerates it from the entry in the partition table, not from it's physical location on the HDD.
On a newly formatted HDD with freshly installed systems, they are probably the same, but after, deleting, shrinking, extending, reformatting partitions here and there, there might be no correlation at all.
Until EasyBCD 2 about half-way through the Beta builds, we spent most of our time here explaining why it was probably quicker to try every combination of rdisk(0-x) and partition(1-y) in boot.ini until you lucked-in on the correct combo, because trying to work it out was not possible with available tools.
That prompted me to say to CG "wouldn't it be nice if we had a little app that would find this hidden info, so that we can just tell people the correct numbers", and about 2 days later he'd written it, and shortly after that incorporated it as tools/autoconfigure, since when it has grown in scope and function beyond the modest initial wish.
 
After many attempts to determine the cause of the intermittent reboots, I think I have the answer. After turning off restart after error, I discovered there is a stop error that occurs during the Welcome Screen for a driver component called “rcfilter.sys”. This seems to be a remnant from a tool called RestoreIt by FarStone. On my friend's computer, this tool is no longer installed, but the driver and several register entries still exist. I renamed the driver and the system seems to boot every time. I have done over 50 restarts in various combinations, without a single reboot or stop error.

Thanks again for your attention and support.
 
Congratulations on tracking it down.
Recommend to your friend, Revo Uninstaller (freeware)
It'll invoke the standard uninstaller, but follows it up with a deep scan for left-behind remnants and cleans them out.
 
Congratulations indeed!

I always twinge when I see rogue software messing up people's computers.... No software developer should have bugs like that in their code! Unfortunately, many times the developers are aware of these issues, but for time management reasons choose not to fix them.
 
Back
Top