[Download] Vista Hide 'n Seek BETA

Some disappointing news to report here however. Upon restarting to go back into Vista the "no valid OS entry was found" type message along with the 0x000068 error code. The message stated using the startup repair tool or contacting your system admin or pc manufacturer.


Using the startup repair tool both versions have been booted into repeatedly without incident. The restore Vista mbr option in EasyBCD 1.7.2 while booted in XP had no effect while the repair tool saw immediate results for seeing Vista load right up.

On previous builds when Vista refused to load the restore option worked there but apparently no longer for the last few builds. The missing boot manager message had appeared again just before use of the repair tool. I thought I would add that here since it came up after posting.

It seems if Vista stalls without losing the option to boot XP the repair tool quickly solves the initial Vista problem following the first boot into XP when first seeing #60 put into use. The new screen with the "Hide'n'Seek" on it is still a plus. Now for an option for changing the background while still seeing the lettering remain. That would be a little more inviting for more users to try out and test HnS overall.
Last edited:
Removed the splashimage part of menu.lst as suggested. I'm fairly sure that the partition error message is still there, but now it appears and disappears so quickly that it is not readable - nor can I catch it with the pause key! I can't be certain, but I don't think the message even made a brief appearance before in build 56 - but perhaps I had become so used to a brief flicker that I was failing to notice that it was there.
I think that's the most likely explanation, geoff.

There are a number of debug options that show extra error messages - I'll be turning them off sometime soon, hopefully that error message will go away with them.
OK, that does seem most likely. The problem is minor, so I am happy to wait for the change to the debug options and will let you know how it performs then. Hope you are at last approaching the final hurdles.....
Your instinct was right CG. Taking the bootsect out put everything back to normal, and UI/HnS behaved perfectly with the correct outcome and successful boots into both systems.
This raises the question "what's wrong with my bootsect.exe ?" if this doesn't happen to anyone else, or is it that my configuration invokes bootsect in UI and others don't ?
What exactly is it there for if I can omit it without a problem ? (or more correctly not omit it with a problem)

Sorry Terry, I missed your reply earlier.

In order for bootsect to work, it temporarily halts any raw access to the physical disks that may be requested by running software. If you have a program that isn't 100% correctly written, it may not elegantly handle being told to shove off for a minute - and if it's a system-level program, then it can lead to system crashes or reboots.

This puts me in the mind of suspecting antivirus software, backup utilities, and other low-level stuff that requires near real-time access to the disk (so they'll open raw file handles instead of using the basic read/write APIs).

As to what bootsect.exe accomplishes - it makes the bootloader search for BOOTMGR. Earlier builds (something in the 20s, perhaps) didn't use bootsect.exe and we came across a problem where people, having hidden the boot partition, need to load BOOTMGR from a different partition that HnS has specified. But if that partition contains Windows XP, its bootsector will search for NTLDR and not BOOTMGR, thus the need to use bootsect.exe to tell it to search for BOOTMGR instead.

Obviously if some software on your PC is causing the reboots then this is of concern because an unexpected reboot in the middle of such an important operation as writing the bootsector and modifying boot files could cause a serious problem for our users. Worst comes to worst, people having this problem could boot into Safe Mode and run HnS from there, but that's a serious hinderance.

What sort of system software are you running?

There's a possible solution that occurred to me, and that's that if Vista HnS is being run from Vista, then it's usually the case that the system drive is searching for BOOTMGR and not something else already. In this case, we can attempt to only update other drives, and not touch the system drive - which may prevent such glitchy system programs from crashing your OS. Let me give this idea a shot in a new build.


OK, new build.

Default is to only attempt to set the bootsector on non-system drives. (i.e. you don't need to touch UI.config.exe, Terry; it's already doing what we'd like to test).

            <setting name="InitializeBootsectors" serializeAs="String">
Valid "value" settings:
Compatibility: Update bootsectors except system drive
Full: Update all bootsectors
Disabled: Don't touch the bootsectors

Care to give it a shot with the default (compatibility) option?

Thanks, man!


Vista HnS Beta Build 61.rar
Last edited:
#61 just went here without incident. However despite the start over used in # 60 a fresh install of #61 on a new or recent XP/Vista dual boot without already seeing the HnS tool already on would be a thought to see if something did come up. Simply seeing a new sub folder created for this build under the main Hide'n'Seek folder saw it put to immediate application with both versions booting normally.

The one thing to note now however is no longer seeing the BootManager.hns type modification visible while seeing only one single "Vista.C.HnS" file at the root of the drive. So far I seem to have less problems overall by simply using the start over button, deleting the desktop shortcut for one build and creating one for the next, and simply resetting the amount of display time.
"Smooth as silk" would be the defintiion for #61. I'm glad to see you are out of jam there with the revision made. #60 saw a slight glitch with the "C:\Boot\BCD" file for some reason when that was tried previously. This one went on smooth and appears ready for more people to test.
That's good to hear. Obviously non-compatibility mode is more guaranteed to set everything straight; but even if compatibility mode doesn't work 100% the user will be able to use HnS to get into Vista from where we can recommend that he set the "Full" switch and try again. Hopefully we won't have to do that too often.

Thanks for all your help, Terry.

I'm not sure what to do about [#HNS-16] Prevent Windows Server 2008 from deleting XP/2003 restore points - NeoSmart Technologies BugCentral - do you think adding a 3rd value for entries when you click on them (Vista, XP, and also Server 2008) will clutter anything?
I don't think putting in a Server2008 option as a third click will cause any problem. Most people won't get that far, and even if they're over-quick with the index finger and accidentally click a Vista drive twice, it's only one extra click to get back to the start (or 2 if you add 2003 too). Not too much of an imposition. (though I think you'll need to be more specific in the instructions of the release build regarding exactly what to mark as what, eg "Mark as Vista all drives containing Vista restore point folders, mark as XP only drives containing a bootable XP system, etc. etc. especially when there are 4 options)

As to compatibility mode, Is there ever a need to reset the boot sector of the "system" partition? Surely, by definition on a Vista/XP dual boot the Vista bootmgr will have been installed there by setup or repair, even when like mine, it's the XP partition.
The one constant I've seen in all builds so far is the lack of seeing Vista specified on the first click but seeing XP shown on the second. When you are looking at both drives or partitions side by side Vista will be on the left where that is seen. The rest of the buttons will show Vista then XP as you click those or simply blank for non OS partitions/drives.

By default Vista's restore points are seen on the Vista primary while the backup files for system restoration can be designated to a different partition or drive there. Since a backup file is much like a disk image being compressed that is uneffected if a second Vista partition like one used for storage is visible. Most won't designate seeing restore points sent to another partition or drive however. The same would hold true for Server2008.

The extra click is simply an entry for that version of Windows while the first button not showing Vista in print while the remaining do is a concern there since knowing if it is set to the Vista click or left blank can be confusing until repeating all clicks over again. The additional click will simply be a part of the process and not noticable except for those running the server edition that will be looking for it.
I've never seen the symptoms you mention PCeye on any build right from the start.
One click marks a drive as Vista, a second marks it as XP.
That's the way it's always been in every build I've ever tried.
That's what I've been seeing here since the first build I ran. When first assigning each drive the first click on the first button for the Vista primary is blank. The first click for the XP drive however sees Vista first and then XP second in text appear. The third click is obviously blank again.

With the exception of seeing problems with 3 or 4 build out of all they all see a n MS Windows type colored pattern appear but no text for Vista on the first click. The second click does sees XP appear like the other buttons however. This is even after having moved Vista from an ide drive where Vista was first run onto a sata drive and reinstalling both versions at times as well as deleting one primary to see a new one created.
It seems another interesting problem came up. To free up space on the Vista drive for both partition 2nd for storage/backup I removed the no longer used VFat root and swap for ubuntu 7.10 still lingering there. 8.04 had been installed on the second XP drive and was waiting for the manual install of Grub.

The mbr on the second was where the original Grub entries temained having already corrected the Vista primary for the dual boot. That pointed at the Vista boot loader there from there no longer on the Vista drive yet saw a problem once the two Linux partitions were gone namely the "missing C:\boot.hns file" message came up and Vista refused to load.

Due to another discovery namely a bad data cable for the sata dvd burner booting up with the Vista dvd was futile since all you would see was the blue screen and nothing else as it stalled while loading up to get at the repair tools. The cable was replaced but still ended up in seeing a reinstall of Vista.

A planned stand alone reinstall of XP will now take place to allow XP to see itself as C not D from the last reinstall without unplugging the Vista drive first. Once XP is redone notes will be taken on just what files will have to be copied over to the Vista primary to see 61 put to use again. for reference. The part of the missing boot.hns fle error being seen seems odd since the mbr and boot sector shouldn't have seen any problems following the deletion of the two VFat partitions at the back end of the drive!
Hey CG I tried a registry edit to change the D drive letter designation back to C on XP following a repair install but will now have to see a fresh stand alone go on. Following that I again copy files from drive to drive again for #61.

The isolated fresh install added into Vista again will take notes for future reference on the proceedure and just what files are needed.
I posted this originally in the easybcd forum, but here is more appropriate.

Ok, it seems I've messed my partitions up using the Neogrub scripts. I was getting not found errors (hal.dll etc).

I would like to start from fresh. Please could someone review what I am about to do and advise.

1) Delete all partitions using norton Partition Magic.
2) Create 1 Primary drive
3) Create 1 Logic - (is this right or should both be primary?)

Here is question 2: is there any prefferable way regarding which system should be installed first, Vista or XP?
4)Install OS 1 in C
5)Install OS 2 to d:
6) install Vista Hide'n'seek

Thanks in advance.