XP Setup then quit corrupts Windows 7!

I noticed this ages ago, but someone else complained that they have just suffered from the same problem...

This problem is 100% repeatable on 3 different system and using different XP Install ISOs.

Scenario:

A notebook (not sure if this is important)

Notebook is installed with standard Win 7 (x86 or 64-bit - both are affected) - freshly install

Boot from E2B USB drive to Windows XP standard Install ISO to run stage 1 of Setup.

XP Blue screen is displayed and Setup starts to load the ramdrive and files from the ISO

XP Setup displays the Press F6 prompt

XP Setup displays the Press F2 prompt

(if reset at this point with CTRL-ALT-DEL then all is still OK)

XP now gets to the very first user prompt screen  'Welcome to Setup'  and get choice of  [ENTER] Repair or F3=Shutdown

If I now press F3 at this point and reboot to the Win 7 internal hard disk I get BSOD

Error 0xc000000e 'Boot selection failed because a required device is inaccesible.'

Complete power removal of adapter and battery did not help.

This has happened repeatedly on two of my notebooks (EeePC with non-SATA HDD so no Mass Storage Driver used, and Acer Aspire 7740G with SATA controller so a Mass Storage Driver was used). Also happened to a new user of E2B (which is why I looked at it again today!).

I fixed it by booting to the Win7 Install ISO from E2B and running bcdboot in a console - e.g.

bcdboot C: /s D:

where C: was the hidden system partition and D: contained the Windows OS.

(The user fixed his by running Hirens and using a Win 7 fix app and then running the standard Win7 Repair.)

When I then rebooted from the internal HDD, I got two BCD menu choices - both 'Windows 7'. The first one worked fine but the second one (presumably the original one) gave the BSOD error as before.

A bcdedit  output is attached.

I haven't fully tested it, so cannot be sure, but I have only noticed this issue when the original OS is Win7 (i.e. not WIndows 8 or XP).

Any ideas why this should be happening?

I will experiment using Rufus next and WinSetupFromUSB to see if they exhibit the same behaviour...

Any ideas why this should be happening?

Windows Boot Loader
-------------------
identifier {6130ffc6-d65c-11e4-b07e-f7da8e8b5442}
device unknown

After I repaired the BCD, I re-ran XP Setup and again, both 'Windows 7' BCD entries are now invalid.

It is highly unlikely that the disk signatures are the same. There is only the USB drive and the internal HDD.

Could this be the result of  grub4dos mapping and XP getting confused about disk IDs?

before I boot to the XP Install ISO, I re-map in grub4dos

map (hd0) (hd)   << set USB drive to last drive

map (hd1) (hd0) << set internal HDD as first drive

I just repaired the Win 7 again and the removed the grub4dos remapping  before booting to the XP Install ISO again ---> result - BCD is fine and boots to the 1st BCD entry (the last one repaired).

So it is the  map swapping that is causing the issue.

Edited by steve6375, 29 March 2015 - 08:56 PM.

Suggested Analysis of what is happening:

Before:

hd0 USB

hd1 HDD0

hd2 HDD1

map (hd0) (hd)   << set USB drive to last drive
map (hd1) (hd0)  << set internal HDD as first drive

After:

hd0 HDD0

hd1 HDD0

hd2 HDD1

hd3 USB    (not counted as HDD because HDD COUNT in BIOS not changed = 3)

So in MBR Setup mode, there are two HDD0's. So XP Setup sees two identical disks and changes one (or both?) of them (they are the same disk anyway!)

Fix:

Remap drives in grub4dos so:

HDD0

HDD1

USB     (not counted as HDD as HDD COUNT BIOS variable set to  map --harddrives=(max-1) = 2)

Now works OK

Edited by steve6375, 30 March 2015 - 04:27 PM.

But isn't this the same issue revolving around disks that should be exchanged or shifted in a circular set (so that a disk is not duplicated)?

http://reboot.pro/to...os-boot-win-xp/

http://reboot.pro/to...-xp/#entry72344

http://reboot.pro/to...f-hd-connected/

http://reboot.pro/to...r-of-map-slots/

http://reboot.pro/to...e-find-command/

How exactly (which commands in grub4dos) do you reach the situation stated for the "Fix"?

Wonko

# hd0 and hd1 cannot be same disk, so we can't just map hd1 as hd0
# All drives must be unique - otherwise XP Setup will change disk signature of HDD as soon as it loads!
set /a HDCNT=*0x475 & 0xff - 1 > nul
set topmap=(hd%HDCNT%) > nul
if "%HDCNT%">="15" echo -e TROUBLE! I detected %HDCNT% disks and card readers in this system (only maximum of 14 allowed)!!!! && pause
if %HDCNT%>=1 map (hd0) %topmap% > nul && map (hd1) (hd0) > nul && echo Mapping (hd0) to %topmap% and (hd1) to (hd0)
if %HDCNT%>=2 map (hd2) (hd1) > nul && if %HDCNT%>=3 map (hd3) (hd2) > nul && if %HDCNT%>=4 map (hd4) (hd3) > nul  && if %HDCNT%>=5 map (hd5) (hd4) > nul
if %HDCNT%>=6 map (hd6) (hd5) > nul && if %HDCNT%>=7 map (hd7) (hd6) > nul && if %HDCNT%>=8 map (hd8) (hd7) > nul
if %HDCNT%>=9 map (hd9) (hd8) > nul && if %HDCNT%>=10 map (hd10) (hd9) > nul && if %HDCNT%>=11 map (hd11) (hd10) > nul
if %HDCNT%>=12 map (hd12) (hd11) > nul && if %HDCNT%>=13 map (hd13) (hd12) > nul && if %HDCNT%>=14 map (hd14) (hd13) > nul
# USB drive is at top, remove it from the count
map --harddrives=%HDCNT%

Good , it is the same issue for which the hypothetical "shiftdisks" command might be useful.

shiftdisks [--offset=offset]
where offset is by default -1, i.e. all drives are shifted by one and current disk (hd0) becomes (hd31) or last available disk.

But I am not sure to understand why you need to decrease the number of devices.

Wonko

So the USB doesn't show up in the XP Setup drive list.

So the USB doesn't show up in the XP Setup drive list.

Well that was the idea, but in practice, it still lists the USB drive (guess it has loaded Protected Mode drivers by then). So it doesn't actually hide the USB drive  !

Good , we can remove the request for the lastdisk command, but the shiftdisks one would still be handy.


Wonko

shiftdisks would be handy, but any previous version of grub4dos would not support the command, so I won't use it for a while as I often need to test with older versions to check for bugs.

On several occasions I have hit bugs in grub4dos 0.4.6a with E2B and have managed to pinpoint exactly what version the bug was introduced at, by testing with older versions of 0.4.6a and 0.4.5c. So the E2B code has to work with older versions of grub4dos as much as possible (for about a year or so back anyway).

shiftdisks would be handy, but any previous version of grub4dos would not support the command, so I won't use it for a while as I often need to test with older versions to check for bugs.

On several occasions I have hit bugs in grub4dos 0.4.6a with E2B and have managed to pinpoint exactly what version the bug was introduced at, by testing with older versions of 0.4.6a and 0.4.5c. So the E2B code has to work with older versions of grub4dos as much as possible (for about a year or so back anyway).

But, as suggested elsewhere, grub4dos (since well more than one year) can run besides batches, and nothing would probably  prevent from making a shiftdisks.g4b batch, also "native" executables, so it would be perfectly possible to have shiftdisks as an external command or module, besides and before being - if considered worth it - added as "internal" command. 

Just a thought .... 

Wonko

You could make a .g4b batch file and then compress it to a .gz file and just call it  shiftdisks.

See if this fits the bill:

!BAT
#SHIFTDSK.G4B by jaclaz
#to shift disks by 1 in a rotating stack
map --status | set last=
call :parse %last%
if %last%==1 goto :eof
set /a from=%last%-1 > nul
:loop
set /a to=%from%-1 > nul
if %from%==0 set /a to=%last%-1 > nul
echo map (hd%from%) (hd%to%)
set /a from=%from%-1 > nul
if %from%>=0 goto :loop
echo map --hook
goto :EOF

:parse
set last=%4
if "%last:~1,1%"=="," set /a last=%last:~0,1% > nul
if "%last:~2,1%"=="," set /a last=%last:~0,2% > nul
goto :EOF

Wonko

yep - seems to work.

maybe add

if not "%8"=="%last%" pause WARNING: harddrives have been remapped already (originally %last%, currently %8)!

just before  goto :EOF to check if drives have already been added/deleted by user?

It is dependant on grub4dos output of map -status command not changing though.

using 

set /a last=*0x475 & 0xff > nul

would give the same number direct from the BIOS and does not rely on grub4dos messages ...

Yep.

I initially thought to use %8 and a check similar to that one, but then changed my mind.

The idea (but I am not too sure if is a right one ) is to create the rotating stack ONLY out of the "harddrives_orig", no matter if the user has previously added via map something else (let's say a mapped image).

I.e. with three harddrives_orig, you would have:

------ <- fictional begin of virtual rotating stack

(hd0) harddrives_orig (hd0)

(hd1) harddrives_orig (hd1)

(hd2) harddrives_orig (hd2)

----------< - fictional end of the rotating stack

and after the shiftdsk:

------ <- fictional begin of virtual rotating stack

(hd0) harddrives_orig (hd1)

(hd1) harddrives_orig (hd2)

(hd2) harddrives_orig (hd0)

----------< - fictional end of the rotating stack

but a user may want/need to add a mapped image, say:

map --mem /myniceimg (hd12)

map --hook

so he/she will have:

------ <- fictional begin of virtual rotating stack

(hd0) harddrives_orig (hd0)

(hd1) harddrives_orig (hd1)

(hd2) harddrives_orig (hd2)

----------< - fictional end of the rotating stack

(hd12)

And after the shiftdsk:

------ <- fictional begin of virtual rotating stack

(hd0) harddrives_orig (hd1)

(hd1) harddrives_orig (hd2)

(hd2) harddrives_orig (hd0)

----------< - fictional end of the rotating stack

(hd12)

The set of "harddrives_orig" are (or should be) a guarantee that they were numbered one after the other, with no "holes" in the numbering, if the user has already re-mapped one of the existing  "harddrives_orig" to a new drive i.e. if he/she remapped a hard disk without exchanging it, i.e. just, say:

map (hd0) (hd1)

map --hook

instead of the "proper":

map (hd0) (hd1)

map (hd1) (hd0)

map --hook

it should fall in the "then do your remapping manually and stay clear of shiftdsk" case.

Getting the number from BIOS is good of course, as long as it "was always there and will always be there", I quickly checked the output of map --status and it seems the same in all versions I tested.

Wonko

The BIOS number should be the same as  the orig number

Presumably if map --harddrives=n is used, then both  the BIOS value and the map --status  orig value change?

[Edit] map --harddrives=5 changes 0x475 but does not change the  harddrives_orig number.

So using map --status is better than using *0x475

Edited by steve6375, 31 March 2015 - 09:26 PM.

The BIOS number should be the same as  the orig number

Presumably if map --harddrives=n is used, then both  the BIOS value and the map --status  orig value change?

Cannot say, the point I was addressing was different.

If one maps an image to a new drive, "harddrives_orig" remains the same, "harddrives_curr" should be +1, and there is no guarantee that in the example case of three "harddrives_orig"  the new drive will be (hd0,3) , as in the example it can well be (hd12) and the batch would attempt to remap a non-existing disk.

By leaving it "outside of the rotating stack" one needs not to worry.

Wonko

The BIOS number should be the same as  the orig number
Presumably if map --harddrives=n is used, then both  the BIOS value and the map --status  orig value change?
 
[Edit] map --harddrives=5 changes 0x475 but does not change the  harddrives_orig number.
So using map --status is better than using *0x475

 
I traced back (possibly ) the source of this piece of info (that 0x475 holds the BIOS number of harddrives) to this post by ilko_t:
http://reboot.pro/to...orial/?p=147021
 
 
 

With recent grub4dos builds:

set /a hdn=*0x475 & 0xff

hdn will be the total number of disks as BIOS reports them. ...

 

which reports the content of a Chinese guide:
http://cvwyg-blog.ap...UB4DOS5mlsy.htm
which, via Google translate amounts to:
 

Calculate the number of physical hard disk 
0x475 lower 2 bytes are stored in the number of physical drives, so to get rid of the high 2 bytes

calc * 0x475 & 0xff

If you save a variable hdn, with set / a hdn = * 0x475 & 0xff

it is entirely possible (as it seems) that more than "lost in translation"; the:

as BIOS reports them

was "added in translation", without making a distinction between harddrives_orig and harddrives_curr, for the use explained in that post and that is commonly made of 0x475, it is correct, as you normally want to know how many drives in total (including both "real" and "mapped" ones) are seen at grub4dos "level" (possibly the same in practice as "in BIOS").

AND judging from here, it seems like 0x475 can be directly manipulated with map --harddrives=n , which actually changes harddrives_curr

http://code.google.c...ues/detail?id=9

so definitely it is not what is needed/desired.

 
So, given then the low 2 bytes of 0x475 hold harddrives_curr, surely some other bits nearby hold the harddrives_orig value .

 

Wonko

No

The BIOS data area only holds the number of drives as enumerated on boot up by the BIOS - normally nothing should change this.

grub4dos can alter this number and map in extra drives.

So grub4dos stores the original value of 0x475 somewhere on loading and obviously never modifies this 'internal' value.

The BIOS will always refer to 0x475 to get the number of drives

e.g. If you try to make a BIOS call to drive 0x85 and the drive count is only 3, then the BIOS call will check it and immediately return a 'bad parameter' error.

Your "No" seemingly means "Yes" , we are saying the same thing, (I will gladly take back BOTH the "surely" and the "nearby" replacing them with "probably somewhere" ) the 0x475 stores the "BIOS value" and it is modified/modifiable by mapping more harddrives, so it corresponds to harddrives_curr (while what I am looking for is the number of "real" BIOS drives, excluded the added ones).

If my reasoning is correct (i.e. the rotating stack should NOT include grub4dos mapped devices) and we want to simplify the batch by avoiding to parse map --status we must find where is the address *somewhere* on which the harddrives_orig  is stored, as 0x475 is correspondent to harddrives_curr and it is changed by mapping more drives or issuing the map --harddrives=n,  it is not useful for "limiting" the extents of the rotating stack, and as said you have no guarantee that an additional disk has not been mapped "out of sequence".

Otherwise one would need to get the 0x475 value, then check for consistency in the numbers assigned to mapped drives (if any), or enumerate the actual numbers assigned to ll devices and create on-the-fly a "shift list", but I will need to be convinced that grub4dos mapped devices should "com into play" in a SHIFTDSK command...

Wonko