Jump to content











Photo
- - - - -

NT 5.x (BSOD Error 0x44 - Stage 2 Install)


  • Please log in to reply
29 replies to this topic

#1 genetix

genetix

    Frequent Member

  • Advanced user
  • 132 posts
  •  
    Finland

Posted 18 July 2013 - 09:48 AM

Hello, having a bit issues I cannot tracing this issue back and solve it seems from any of the already build project scripts. I have read quite a bit of topics and ignored quite a bit of websites while trying to build a bit different style my goal.

 

So, here's what I got...

 

Hardware:

* 3 PCs to boot at:

 - Pentium 4 - 775 chipset - 1GB RAM

 - Intel IB I5-3750K - Z67 chipset - 6GB RAM

 - Notebook: Acer (can't recall exact model, but Intel Dual Core, 2GB and fully USB bootable)

* USB Flash Stick USB 3.0 gen (at USB 2.0 port for compatibility)

 

OSes in testing build:

Windows XP SP3 Pro CD

Windows XP SP3 Home CD

 

-> singular ISO with modifications/root:

XP3E\<floppy>

XH3E\<floppy>

ROOT\XP3E\<CD>

ROOT\XH3E\<CD>

XP3E.DAT <cdbootsector>

XH3E.DAT <cdbootsector>

 

XP3E modifications example:

- cdbootsector: modified -> I386 = XP3E

- Floppy: modified ->

  - setupldr.bin -> I386 = XP3E

  - txtsetup.sif -> SetupSourcePath = "\ROOT\XP3E\"

- CD: Unmodifed source

- ISO Format information: ISO 9660 (no Joliet, ISO Level 2, 8dot3 naming)

 

Software/drivers:

* WinVBlock x86/x64

* Firadisk x86/x64

(Singular floppy with modified TXTSETUP.OEM)

 

Boot-up with GRUB4DOS v0.4.4 &/or GRUB4DOS 0.4.6a(mod):

1. grldr -> menu.lst

2. menu.lst content:

 

Stage 1:

title Microsoft Windows XP Professional SP3 [Retail Edition] - English
map --mem (hd0,0)/floppy/CUSTOM/gendrv.ima (fd0)
map (hd0,0)/ms/NT5.ISO (0xFF)
checkrange 0x80 read 0x8280 && map (hd0) (hd1) 
checkrange 0x80 read 0x8280 && map (hd1) (hd0)
map --hook
root (0xFF)
chainloader /XP3E/SETUPLDR.BIN
boot

* gendrv floppy image contains WinVBlock + Firadisk x86/x64.

* This works through all setups to 'stage 2' as long WinVBlock is used (real machine). At VM anything except QEMU it fails.

 

Stage 2:

title Microsoft Windows 5.xx [Stage 2]
map --mem (hd0,0)/floppy/CUSTOM/gendrv.ima (fd0)
map (hd0,0)/ms/NT5.ISO (0xFF)
checkrange 0x80 read 0x8280 && map (hd0) (hd1) 
checkrange 0x80 read 0x8280 && map (hd1) (hd0)
map --hook
chainloader (hd0)+1
boot

* Now here is where I fail to 'Error 0x44':

bsod.jpg

 

Attempted based on different info:

* Setting root instead of chainloading (hd0)+1

* Loading floppy to fd0+fd1.

* Few really odd mappings what I am not even going to mention since don't understand 1 cent about them why they should of worked in the first place.

 

Next steps under considerations:

* Move all data to NTFS partition at USB drive, direct boot it (I try'd this before at that point I couldn't get pass the stage 1, but I think with all the new information I could get to stage 2 to test).

* Build boot loader based on cd-shell/bscript project under ISO and build menus to boot the image (which doesn't affect above as that is whole another story on booting) as is the MS-DOS bootloader style floppy at CD with eltorito -> winnt.exe.

 

Few other notes of the project:

* Original CD based data \ROOT\ will not be modified, hex edited, 1st stage installed or otherwise touched ever. It is not an option and never will be an option.

* ISO can be any container. ex. VHD/IMG HD image, if needed as long above note is kept in mind.


Edited by genetix, 18 July 2013 - 10:13 AM.


#2 steve6375

steve6375

    Platinum Member

  • Developer
  • 7283 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 18 July 2013 - 10:25 AM

In stage 2, how does firadisk/winvblock it load the ISO? i.e. how does it know where the ISO is located to load it in Stage 2?

 

What might be happening is that as long as the ISO is still in memory, then Stage 2 works. If using a QEMU then the memory is not cleared on reboot, if using a different VM then memory is lost.

 

To prove this, on a real machine, run stage 1, switch off the system when it reboots, switch it on again and run Stage 2 - does it still work?

 

Now try:

map --mem (hd0,0)/ms/NT5.ISO (0xFF)


#3 genetix

genetix

    Frequent Member

  • Advanced user
  • 132 posts
  •  
    Finland

Posted 18 July 2013 - 12:22 PM

Answer to Power Off at 'System Reset' Signal:

Clean power off back on will not work, gives me same error. There shouldn't be anything in memory in the first place because when you first install the Stage 1 and MS installer gives the 'System Reset' command stage 2 boots to '/grldr' and menu.lst Stage 2 is then selected.

 

* Memory mapping will be out of the question for starters I will not even consider that option in any case. They need to be bootable in quite minimal resources as in systems with 128MB RAM.

 

Question:

Why wouldn't WinVBlock be at installation drivers when stage 2 from HD1 is started?

(Asking because: It is loaded as F6 driver just like any HD(AHCI/RAID) driver would be and system has those while booting to next stage, 'stage 2' in this case.)

 

 

Currently considered problems:

* USB flash drive - Partitioning

(Like Windows 6.x variants, as long Windows setup doesn't  understand what a device is attached to system it would fail also. Solved that problem with diskmod at NT6 variant, wonder would that work in here too or something like cfadisk for testing.)



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15339 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 July 2013 - 01:28 PM

I have the impression (forgive me if it is a "false" one) that you are attempting to do all together a number of not-so-simple or possibly not-intended-to-be-cumulative changes/tweaks/variations/whatever to a procedure that (with slightly different approaches) has been working since years (and has been continuosly "tuned" since).

 

Maybe you could take a step back and have a look at the issue from a wider perspective.

 

There are at least 4 (or more) by now "consolidated" ways/tools/methods that allow to to install an XP from USB (stick or hard disk).

 

Is this what you want to achieve, right?

 

Two or three are in the stickies here:

http://www.msfn.org/...ndows-from-usb/

There is additional the thingies by Steve6375 (two among more):

http://www.rmprepusb...-xp-from-an-iso

http://www.rmprepusb...so_imdisk_winpe

 

And Rufus:

http://rufus.akeo.ie/

 

Or both:

http://www.rmprepusb...tutorials/rufus

 

Have you already tried ALL of them?

 

What (and in which tool/method) is an issue for your goal?

 

:cheers:

Wonko



#5 steve6375

steve6375

    Platinum Member

  • Developer
  • 7283 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 18 July 2013 - 02:07 PM

Answer to Power Off at 'System Reset' Signal:

Clean power off back on will not work, gives me same error. There shouldn't be anything in memory in the first place because when you first install the Stage 1 and MS installer gives the 'System Reset' command stage 2 boots to '/grldr' and menu.lst Stage 2 is then selected.

 

* Memory mapping will be out of the question for starters I will not even consider that option in any case. They need to be bootable in quite minimal resources as in systems with 128MB RAM.

 

Question:

Why wouldn't WinVBlock be at installation drivers when stage 2 from HD1 is started?

(Asking because: It is loaded as F6 driver just like any HD(AHCI/RAID) driver would be and system has those while booting to next stage, 'stage 2' in this case.)

 

 

Currently considered problems:

* USB flash drive - Partitioning

(Like Windows 6.x variants, as long Windows setup doesn't  understand what a device is attached to system it would fail also. Solved that problem with diskmod at NT6 variant, wonder would that work in here too or something like cfadisk for testing.)

 

In Stage 1, to tell firadisk where the ISO is, we can either use a pseudo-floppy (see below) or we can use a special entry in the txtsetup.oem file

 

if not exist (fd0)/txtsetup.oem goto :fd0

#set name of ISO in txtsetup.oem for FiraDisk - otherwise BSOD 0x7B!

#chenall's ntboot http://chenall.net/post/ntboot/

set BADTXT=

set fira.opt=cdrom,vmem=find:/_ISO/Windows/XP/%ISO%;

cat --locate=###E2B### --number=1 (fd0)/TXTSETUP.OEM > nul || set BADTXT=1

set offset=%?%

write --offset=%offset% (fd0)/TXTSETUP.OEM value=Parameters,StartOptions,REG_SZ,"%fira.opt%"\r\n; > nul

cat --skip=%offset% --locate=/ --replace=\\ (fd0)/TXTSETUP.OEM > nul

 

The WinVblock/firadisk driver will load in Stage 2, but the ISO needs to be loaded as a virtual drive. So how does the winvbock driver know what the name and path of the ISO is, so it can load it?

 

Typically, for WinVBlock, in stage 2 we use a small virtual floppy drive with special contents. It is made like this for WinVBlock.

 

map --rd-size=2048 > nul

map --mem (rd)+4 (0x55) > nul

map --rehook > nul

write (0x55) #!GRUB4DOS\x00v=1\x00/ms/NT5.ISO\x00\xA0\x00 > nul

 

For Firadisk, it can find and mount the ISO that is already in memory from stage 1  (you do not need the USB flash drive connected for Stage 2 as long as you do not switch off the system). That is why it did not work when you switched off between stage 1 and stage 2. System Reset does not clear all XXGB of memory - the dynamic RAM is still refreshed and kept alive after a system reset (by design as that is how CPUs used to switch from protected mode to real mode). A cold power-off will ensure memory contents is lost however as you have just proved.

 

If using Firadisk, then you can use instead use:

write (99) [FiraDisk]\nStartOptions=cdrom,vmem=find:/ms/NT5.ISO;\n\0 > nul

to tell the driver where the ISO is, but this causes problems with WinVBlock.

 

Have a look at  Easy2Boot on my site. It can use Firadisk  for low-ram systems and auto-detects and makes the correct SRS F6 driver floppy.

 

E2B From Flash drive

================

SRS option 2=Firadisk+AHCI driver  N=don't load in RAM    + Stage 2 Low Ram   = WORKS (even if switch off after Stage 1)

SRS option 3=WinVBlock+AHCI driver N=don't load in RAM                                   Stage 1 OK, Stage 2 = BSOD 0x24

 

E2B From USB HDD

===============

SRS option 2=Firadisk+AHCI driver  N=don't load in RAM               Stage 1 = BSOD 7B

SRS option 3=WinVBlock+AHCI driver N=don't load in RAM           Stage 1 OK, Stage 2 = BSOD 0x44

 
I have not been able to install XP from ISO using WinVBlock on a low-ram system
I also have not been able to install XP from ISO using Firadisk from a USB-HDD on a low-ram system
 
Only using Firadisk from a USB Flash drive seems to work for a low-ram system...


#6 genetix

genetix

    Frequent Member

  • Advanced user
  • 132 posts
  •  
    Finland

Posted 20 July 2013 - 01:30 AM

@wonko

 

Yes, it has taken long time to build, no I have actually progressed through everything else except these specific installations or NT5 and yes I have read every single article you currently posted as link including 'Steve6375' website and as stupid as this sounds I am reading this stuff over and over and over again.... Just to try to understand what everyone means in the end. :)

 

@Steve6375

 

yeh, I actually read quite a lot from your site hell went through those section. There's few ideas I don't fully understand kinda "hebrew" to me time to time.

 

(Will look at the 'http://chenall.net/post/ntboot/' what kinda loading his ISOs does and extract them up perhaps there's some ideas.)

 

If I understood your example correctly above.. (Sorry, it's 04:20am here, trying to keep up..)

 

 

The WinVblock/firadisk driver will load in Stage 2, but the ISO needs to be loaded as a virtual drive. So how does the winvbock driver know what the name and path of the ISO is, so it can load it?

 

The ISO location never changes as it is remapped with grub4dos to 0xFF same as at Stage 1 before chainloading to hd1 to continue windows setup. So, if WinVBlock is loaded with continuing setup as a driver shouldn't that locate automatically the ISO from 0xFF ?

 

(Example. If I would boot the machine after stage 1 and direct boot to HD1(which would be of course HD0 without USB) remove USB at power down it would go through the mentioned BSOD and ask for Windows CD.)

 

I have to admit I did not entirely understand the purpose of creating ramdisk floppy for WinVBlock.

1. Do you mean, if I make the floppy in ram instead of loading to ram at stage 1 anyway from floppy image it would some way stay ther better and so it would survive the machine reset currently I am reloading fd0 to ram at stage 2[map --mem /floppy.img (fd0)] before continuing the windows setup (stage 2).

 

or

 

2. I would include the ISO path to HDx (USB-Disk), so, ISO could be located by this somehow, mapped and then try to boot directly to stage 2 HD0(Installation continuing booting drive) without 3rd party bootloaders.

 

and as for:

 

 

SRS option 3=WinVBlock+AHCI driver N=don't load in RAM           Stage 1 OK, Stage 2 = BSOD 0x44

 

You can actually bypass this as long the USB is not attached through NT5.0 boot detection phase. However, that's easier said than done and only way to go through stage 2 would actually be to have physical location of data and redirect the setup to that which is why I did consider the idea of have NTFS space at flash and load diskmod beside WinVBlock, so, I could clean dupemerge the NTFS, the see the USB partition and direct the install to that (now referring using no ISOs in progress at all).

 

I left the project standing since 2 days ago sorry about slow response.

(had to rebuild some of my machine since had some new hardware inc. had to make sure they won't error on me when I need them to do correct calculation, boots etc).


Edited by genetix, 20 July 2013 - 01:53 AM.


#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15339 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 July 2013 - 10:32 AM

@genetix

What I meant (and completely failed to convey properly :unsure:) in a nutshell is the following:

  • over the years several (many) slightly different methods to install XP from USB have been developed, troubleshot and tested successfully
  • they DO WORK (in some cases one is preferable to the other, or one is more suited than another)
  • the advised (by me) procedure to develop/test a "new" way is to first try (test) the solution(s) already available WITHOUT introducing ANY variation then once having had success with the non-modified approach, start introducing the changes you *need* or wish for (and possibly do so one at the time)

If you take one of the methods (anyone) and start modifying it without having verified it works on your particular setup it is more likely that you will spend countless sleepless night chasing wild gooses :ph34r:.

 

If you prefer, the wheel and hot water have both been invented, the residual *needs* may be for rounder wheels or for hotter water :w00t:, and:

http://reboot.pro/to...re/#entry136216

 

As a side note, I tend to use a convention along which sentences that end with a little hook sign (which is called "question mark") are "questions" ;) and they are posted in the hope that an answer to them is provided:

 

 

 

Have you already tried ALL of them?

 

What (and in which tool/method) is an issue for your goal?

 

:cheers:

 

Wonko



#8 genetix

genetix

    Frequent Member

  • Advanced user
  • 132 posts
  •  
    Finland

Posted 20 July 2013 - 03:00 PM

 

What I meant (and completely failed to convey properly :unsure:) in a nutshell is the following:

  • over the years several (many) slightly different methods to install XP from USB have been developed, troubleshot and tested successfully
  • they DO WORK (in some cases one is preferable to the other, or one is more suited than another)
  • the advised (by me) procedure to develop/test a "new" way is to first try (test) the solution(s) already available WITHOUT introducing ANY variation then once having had success with the non-modified approach, start introducing the changes you *need* or wish for (and possibly do so one at the time)

 

I have built multiple styles available at forums. I have tested multiple ways introduced by Steve website and as of yet I have not found a way to boot up mentioned Stage 2 at clean source. I am not trying to reinvent the wheel I am trying to find solution to improve the existing solutions over years. I do have I would say almost a small laboratory for specific scenario testing.

 

I do understand multiple ways has been developed including preinstalled OS, hell some even build an full installation dump without going through any os own installers which was damn impressive and most of already existing methods include high level of OS modification, some are better than others by modifying secondary source of data on fly after the actual data dump by OS installer and some uses general memory to go through the unfunctional passes which otherwise would fail which in my case is unacceptable as I have explained at first post in this forum thread, if I have to I will explain to you every single link you posted including the forum posts how those methods are build and how they work from top to bottom, but you will still not find in any of those methods a way to keep clean source. Worst case scenario like NT3 you would actually have to reconstruct the whole installation from W2K/XP just to make a CD bootable, although, have to admit that was impressive build here at forums never the less.

 

Rest of what you wrote are asking me simply 'Have I looked else where?' and then 'Even if so, why try to reinvent the wheel?'. I have specified the concept I am building, one of the most intelligent persons I've ever seen building OS starters responded that he has not been able to go through the installations of either direct mapping ways and you are asking me 'why, am I asking on really hard boot scenario here in forums with bunch of intelligent persons' all I am asking is 'How it might be possible to overcome the obstacle?' and to be totally honest I don't see any issues asking that as it's more complex concept than most people in this planet would understand in a life time without even lying.

 

So, I ask you why are you asking me this?

 

@Steve6375

 

Yeah, started testing the ramdisk styles, took a look at the chenall. Looks like the Firadisk method would be successful at ISO container at RAM style. I have to research the idea of WinVBlock more because I think if I manage to include drivers, bootloader and swap drives and give OS drivers to USB partitioning + ISO location it might be possible to overcome the 0x44 error message.

 

Needs several hours of testing, but will see what happens when I get it together today and booted up on real box.


Edited by genetix, 20 July 2013 - 03:16 PM.


#9 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15339 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 July 2013 - 04:12 PM

So, I ask you why are you asking me this?

I am trying to understand (in order to be able to try and help you :)) which SPECIFIC, EXACT issue you found when using WHICH SPECIFIC among the available tools/methods.
 
I will reiterate how when *something* "as is" has worked in thousands (or tens or thousands or hundred of thousands) of cases, it means that it "normally" WORKS.
 
When it does not, it means that *something* is DIFFERENT (either in the source or in the method used not exactly as it was tested or in the hardware or *whatever*).
 
If it would be clarified how a chosen "standard" method (working for the majority of people) behaves, it would be IMHO easier to then add to it the changes you *need* or wish for and identify more precisely the culprit (and hopefully find an appropriate solution or workaround for the issue).
 
JFYI, this is somehow "coded" in the "Common Sense Advice", here, particularly points #f.:
http://reboot.pro/to...ead-this-first/
which of course you are perfectly free to ignore.
 

...  if I have to I will explain to you every single link you posted including the forum posts how those methods are build and how they work from top to bottom, but

That would be very kind of you :), but having contributed directly or indirectly to most of them, I will decline your offer, pretending that I need not your explanations on how they work.

In my ignorance, I thought that these ones:
http://www.msfn.org/...rom-a-iso-file/
http://www.msfn.org/...aded-iso-image/
needed only a "clean source", but evidently I am mistaken :ph34r:.
 
:cheers:
Wonko



#10 steve6375

steve6375

    Platinum Member

  • Developer
  • 7283 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 20 July 2013 - 05:54 PM

E2B From Flash drive

================

SRS option 2=Firadisk+AHCI driver  N=don't load in RAM    + Stage 2 Low Ram   = WORKS (even if switch off after Stage 1)

 

 

As I already posted, this works for low ram systems...????



#11 genetix

genetix

    Frequent Member

  • Advanced user
  • 132 posts
  •  
    Finland

Posted 21 July 2013 - 05:18 PM


In my ignorance, I thought that these ones:
http://www.msfn.org/...rom-a-iso-file/
http://www.msfn.org/...aded-iso-image/
needed only a "clean source", but evidently I am mistaken :ph34r:.
 
:cheers:
Wonko

 

 

Indeed these 2 posts are correct concept what I am building. What is the problem here is to get them working on my end. I have 3 different boot scenarios and as of yet I have not had success of booting those. The first post drives back to memory ISO every post if you read them starts to mount the actual container(ISO) to memory and no one has successfully booted the actual direct mapped ISO.

 

The second post requires usage of RAM for whole container (which is also how most in 'install XP from ISO file' troubleshooted and actually got it working. which as I have said on first post even is unacceptable.

 

 

As I already posted, this works for low ram systems...????

 

Don't know anything about that 'option 2' there. I was all the time referring the WinVBlock methods/options you mentioned, sorry, most of gotten confused somewhere by the 'error 44' at Firadisk as I am getting that error with WinVBlock.



#12 steve6375

steve6375

    Platinum Member

  • Developer
  • 7283 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 21 July 2013 - 07:21 PM

SRS option 2  means that E2B will use fd1=SRS driver and fd0=firadisk driver,

option 3 means E2B will use fd1=SRS driver and  fd0=WinVBlock driver.

 

error 44 I get with WinVblock.

 

So for a working low-ram solution, use firadisk as used by E2B.

 

Why not try E2B and see if it works for you?



#13 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15339 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 July 2013 - 07:36 PM

Well, in my limited experience with these matters, when cdob :worship: writes something, it is accurate (it may be not the clearest/most easily followable method, but it is accurate).

 

BOTH methods did/do work and have worked for a number of people, but of course your mileage may vary, both connected to the hardware you have and to *any* change, even minimal, that you make (or made) to them, or maybe you are using a different (older or newer) version of WinVblock :unsure:.

Wimb also confirmed the working of the method (as later modified):

http://www.msfn.org/...-file/?p=956987

 

AFAIK/AFAICR:

  1. First one uses NOT a Ramdisk for the .iso (but it may use/need a very small one for the "driver floppy").
  2. Second one does.

 

:cheers:

Wonko



#14 genetix

genetix

    Frequent Member

  • Advanced user
  • 132 posts
  •  
    Finland

Posted 21 July 2013 - 10:16 PM

@Steve6374

 

yeh, I am testing it, but currently I simply want to understand why doesn't this build work which I was originally working with it is ideantical to cdob boot scenario and I am still getting the 0x44 error, atm, I am tested few ideas I had still to test it (as for NTFS style mentioned, that will not work no matter what I try, heh, so gonna leave that idea on it's own for good).

 

@Wonko

 

Yeah, cdob has some really good methods posted and Wimb.. Sometimes I have to admit it's just damn hard to understand since there is so much stuff to read on their builds and beside that understand how their solutions actually worked in the end from few hundred compressed utilities, well, it simply takes the brains out. ;)


Edited by genetix, 21 July 2013 - 10:18 PM.


#15 genetix

genetix

    Frequent Member

  • Advanced user
  • 132 posts
  •  
    Finland

Posted 22 July 2013 - 01:28 AM

Yeh, looks like I have to close this topic as I cannot get it to work. Probably, I am too stupid, but I cannot get rid of the 0x44 error no matter what I do.

 

Tested Clean USB and clean windows disk with nothing else than 1 clean HD on box.:

I tested Firadisk identical to instruction to Steve site = 0x44

I tested WinVBlock identical to instruction to Steve sire = 0x44

(http://www.rmprepusb...-xp-from-an-iso)

 

I just cannot get rid of this damn BSOD.

 

Firadisk 2/18/2011 v0.0.1.30

WinVBlock tested the one on Steve site and v0.0.1.8

 

I mean I booted over 100 times with different setups including those above and hell every single boot ended up to Stage 2 -> BSOD 0x44. Honestly speaking I think it's just not possible the way I am trying to boot it. I have no clue why I am seeing this as I see the same result in 3 different machines from 2 different USBs.

 

Funny part here is I still do not see a single wrong line at my post #1 at this topic all in all that should work clean up, heh.


Edited by genetix, 22 July 2013 - 01:38 AM.


#16 genetix

genetix

    Frequent Member

  • Advanced user
  • 132 posts
  •  
    Finland

Posted 22 July 2013 - 04:10 AM

Spoke too early, looks like this post did the trick..

 

http://reboot.pro/to...stage/?p=151433

 

^ Thanks for this one AnotherUser, with modification to this with modified floppy boot/redirect inside ISO and removing the 'newinstallcode1' leaving 'upgradecode' at '1' firadisk and WinVBlock seems load clean up from text part of setup and GUI doesn't BSOD with the lines Steve6375 gave me added to stage 2 ISO loaded at (0xA0):

 

 

map --rd-size=2048

map --mem (rd)+4 (0x55)

map --rehook

write (0x55) #!GRUB4DOS\x00v=1\x00/ms/NT5.ISO\x00\xA0\x00

 

Seems, now the BSOD is gone and don't even need floppies with grub4dos.


Edited by genetix, 22 July 2013 - 04:12 AM.


#17 wimb

wimb

    Platinum Member

  • Developer
  • 2846 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 22 July 2013 - 06:02 AM

Spoke too early, looks like this post did the trick..

 

http://reboot.pro/to...stage/?p=151433

 

But that is not according to your goal of using an unmodified source .....

 

Few other notes of the project:

* Original CD based data \ROOT\ will not be modified, hex edited, 1st stage installed or otherwise touched ever. It is not an option and never will be an option.

 



#18 wimb

wimb

    Platinum Member

  • Developer
  • 2846 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 22 July 2013 - 06:25 AM

In your grub4dos menu given in post #1 you have only one virtual floppy (fd0)

whereas cdob and I use always two virtual floppy drives (fd0) and (fd1) loaded into RAM

 

In GUI stage then a lot is changing in device numbering as devices are installed

and it might be needed to have two virtual floppy drives to get the process running.

 

The following approach anyway is working OK and is using quite a different Grub4dos Menu.

 

Install XP in VHD using XP Setup ISO file and WinVBlock driver
 
VHD_XP_Create.exe - Make VHD file and make Grub4dos Boot Menu on USB
for Install of XP in VHD by using XP Setup ISO file and WinVBlock driver
 
Scenario used:
- Boot with Grub4dos Menu on NTFS USB-Stick for Install of XP in VHD located on NTFS Drive of Internal Harddisk
- XP Setup ISO file is located on USB-Stick and is NOT loaded into RAM

XP-2.vhd has already NTFS compressed format, so you should NOT format at Setup, just keep settings

 

ListDosDevices during XP Setup GUI-mode (Stage 2) - recorded by using Shift F10 and using ListDosDevices_To_Notepad

Virtual CD is here drive S: and there are 2 Virtual Floppy Drives A: and B:

USB-Stick is drive J: and Install of XP in VHD drive C:

 

Notice the changes in Floppy and CD device numbering due to Install of Devices during XP Setup.

 

GUI-mode Just Before Install of Devices
 
Drv Type       DosDeviceName
 
A:  REMOVABLE  \Device\Floppy0
B:  REMOVABLE  \Device\Floppy1
C:  FIXED      \Device\HarddiskVolume9
D:  FIXED      \Device\HarddiskVolume1
E:  FIXED      \Device\HarddiskVolume5
F:  FIXED      \Device\HarddiskVolume3
G:  FIXED      \Device\HarddiskVolume4
H:  FIXED      \Device\HarddiskVolume7
I:  FIXED      \Device\HarddiskVolume8
J:  REMOVABLE  \Device\Harddisk3\DP(1)0-0+11
K:  REMOVABLE  \Device\Harddisk4\DP(1)0-0+12
L:  REMOVABLE  \Device\Harddisk5\DP(1)0-0+13
M:  REMOVABLE  \Device\Harddisk6\DP(1)0-0+14
N:  REMOVABLE  \Device\Harddisk7\DP(1)0-0+15
O:  FIXED      \Device\HarddiskVolume2
P:  FIXED      \Device\HarddiskVolume6
Q:  CDROM      \Device\CdRom0
R:  CDROM      \Device\CdRom1
S:  CDROM      \Device\CdRom2
T:  ----
U:  ----
V:  ----
W:  ----
X:  ----
Y:  ----
Z:  ----
 
 
GUI-mode After Install of Devices
 
Drv Type       DosDeviceName
 
A:  REMOVABLE  \Device\Floppy2
B:  REMOVABLE  \Device\Floppy1
C:  FIXED      \Device\HarddiskVolume9
D:  FIXED      \Device\HarddiskVolume1
E:  FIXED      \Device\HarddiskVolume5
F:  FIXED      \Device\HarddiskVolume3
G:  FIXED      \Device\HarddiskVolume4
H:  FIXED      \Device\HarddiskVolume7
I:  FIXED      \Device\HarddiskVolume8
J:  REMOVABLE  \Device\Harddisk3\DP(1)0-0+11
K:  REMOVABLE  \Device\Harddisk4\DP(1)0-0+23
L:  REMOVABLE  \Device\Harddisk5\DP(1)0-0+21
M:  REMOVABLE  \Device\Harddisk6\DP(1)0-0+25
N:  REMOVABLE  \Device\Harddisk7\DP(1)0-0+1f
O:  FIXED      \Device\HarddiskVolume2
P:  FIXED      \Device\HarddiskVolume6
Q:  CDROM      \Device\CdRom0
R:  CDROM      \Device\CdRom5
S:  CDROM      \Device\CdRom3
T:  ----
U:  ----
V:  ----
W:  ----
X:  ----
Y:  ----
Z:  ----
 

 

 

XP-2-VHD-Setup.png

 
Grub4dos Menu on USB-Stick

title Continue GUI-mode XP Setup on XP-2.vhd - WinVBlock driver - 2000 MB
find --set-root --ignore-floppies /XP3_1210XV.iso
map /XP3_1210XV.iso (0xff)
find --set-root --ignore-floppies /XP-2.vhd
map --mem /winvblock.ima (fd1)
map --mem /winvblock.ima (fd0)
map /XP-2.vhd (hd0)
map --hook
root (hd0,0)
chainloader /ntldr
 
title Start -  TXT-mode XP Setup on XP-2.vhd - WinVBlock driver - 2000 MB
find --set-root --ignore-floppies /XP3_1210XV.iso
map /XP3_1210XV.iso (0xff)
find --set-root --ignore-floppies /XP-2.vhd
map --mem /winvblock.ima (fd1)
map --mem /winvblock.ima (fd0)
map /XP-2.vhd (hd0)
map --hook
chainloader (0xff)
 
title Boot  Windows XP from Image - XP-2.vhd - WinVBlock driver - 2000 MB
find --set-root --ignore-floppies /XP-2.vhd
map /XP-2.vhd (hd0)
map --hook
root (hd0,0)
chainloader /ntldr
 

 

 

:cheers:



#19 wimb

wimb

    Platinum Member

  • Developer
  • 2846 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 22 July 2013 - 09:00 AM

On Intel i5 Quad core I have repeated the test and then I get BSOD 44 at reboot for GUI-mode when ISO is not loaded into RAM,

but I can easily solve the issue by using in VHD_XP_Create.exe the Default option e.g.  Load XP Setup ISO in RAM - use mem Option.

 

XP-3-VHD_Intel-5.png

 

:cheers:



#20 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15339 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 July 2013 - 09:03 AM

@Wonko
 
Yeah, cdob has some really good methods posted and Wimb.. Sometimes I have to admit it's just damn hard to understand since there is so much stuff to read on their builds and beside that understand how their solutions actually worked in the end from few hundred compressed utilities, well, it simply takes the brains out. ;)

I guess it has been a wise choice to decline your offer to explain me how those methods work ;). :whistling:
 
http://www.imdb.com/...?item=qt0357926

But choose wisely, for while the true Grail will bring you life, the false Grail will take it from you.


Anyway, it seems that everything is back to "cool" level, and somehow there is another happy bunny around. :)

@wimb, but then you would be using a biggish Ramdisk :w00t:, that doesn't count as "solution"!

:cheers:
Wonko

#21 wimb

wimb

    Platinum Member

  • Developer
  • 2846 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 22 July 2013 - 09:09 AM

@wimb, but then you would be using a biggish Ramdisk :w00t:, that doesn't count as "solution"!

 

 

I need to load the 700 MB ISO as virtual CD into RAM only in case of Intel i5 in order to prevent BSOD 44

but in case of AMD Dual core machine then loading into RAM is NOT necessary :)

 

Loading the ISO into RAM is on the Intel i5 machine no problem at all,

since the machine is very fast and has 4 GB RAM

 

Loading the ISO into RAM for some cases is may be more a "solution" then modifying the ISO

or modifying cdbootsector and setupldr.bin and txtsetup.sif as proposed in post #1 ...... :w00t:

 

:cheers:



#22 wimb

wimb

    Platinum Member

  • Developer
  • 2846 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 22 July 2013 - 10:47 AM

This Grub4dos Menu for Install of XP in VHD without loading ISO into RAM is working OK on Intel i5   :)

Writng the XP Setup ISO filename into the phony RAM disk is solving indeed the problem and there is no need to modify anything else ....

 

http://reboot.pro/to...-10#entry101891

 

 

title Continue GUI-mode XP Setup on XP-4.vhd - WinVBlock driver - 2000 MB
find --set-root --ignore-floppies /XP3_1210XV.iso
map /XP3_1210XV.iso (0xA0)
map --rd-size=2048
map --mem (rd)+4 (0x55)
map --hook
write (0x55) #!GRUB4DOS\x00v=1\x00/XP3_1210XV.iso\x00\xA0\x00
find --set-root --ignore-floppies /XP-4.vhd
map --mem /winvblock.ima (fd1)
map --mem /winvblock.ima (fd0)
map /XP-4.vhd (hd0)
map --rehook
root (hd0,0)
chainloader /ntldr
 
title Start -  TXT-mode XP Setup on XP-4.vhd - WinVBlock driver - 2000 MB
find --set-root --ignore-floppies /XP3_1210XV.iso
map /XP3_1210XV.iso (0xA0)
map --rd-size=2048
map --mem (rd)+4 (0x55)
map --hook
write (0x55) #!GRUB4DOS\x00v=1\x00/XP3_1210XV.iso\x00\xA0\x00
find --set-root --ignore-floppies /XP-4.vhd
map --mem /winvblock.ima (fd1)
map --mem /winvblock.ima (fd0)
map /XP-4.vhd (hd0)
map --rehook
chainloader (0xA0)
 
title Boot  Windows XP from Image - XP-4.vhd - WinVBlock driver - 2000 MB
find --set-root --ignore-floppies /XP-4.vhd
map /XP-4.vhd (hd0)
map --hook
root (hd0,0)
chainloader /ntldr
 

 

:cheers:



#23 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15339 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 July 2013 - 11:01 AM

Loading the ISO into RAM for some cases is may be more a "solution" then modifying the ISO
or modifying cdbootsector and setupldr.bin and txtsetup.sif as proposed in post #1 ...... :w00t:

Sure :), but it is a solution that the OP excluded a priori . :ph34r:
 
Now if we want to debate on how much senceful is to install nowadays an "untouched" XP SP3 on *any* machine with less than 1 Gb of RAM, this would be an interesting topic.
 
The original request was AFAICU for a "one size fits all" NO RAMDISK install from USB, capable of installing on machines with as low as 128 Mb of RAM, NO modifications to source (except for the ones OP anyway does/did).
 
And OP never talked (unless I am mistaken) about .vhd (or RAW image) installing of the Windows XP (but I guess that your last menu.lst can be "converted back" to "plain install" :thumbsup:).
 
 
 
 

This Grub4dos Menu for Install of XP in VHD without loading ISO into RAM is working OK on Intel i5   :)
Writng the XP Setup ISO filename into the phony RAM disk is solving indeed the problem and there is no need to modify anything else ....

Very good! :thumbup:
BTW, and for the record the "phony RAMDISK" was initially suggested by Sha0 :worship: himself on the mentioned thread:
http://www.msfn.org/...-file/?p=957760
which with some "magic" conversion of the "botched" IPB board post addressing scheme, lands (nicely :unsure:) here:
http://reboot.pro/to...-12#entry119816
 
Questions :dubbio::

  • Does the "i5" specific" menu.lst also work on non-i5 hardware?
  • Any particular reason why (0xA0) is used instead of (0xff)?

:cheers:
Wonko



#24 wimb

wimb

    Platinum Member

  • Developer
  • 2846 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 22 July 2013 - 11:28 AM

This Grub4dos Menu for Install of XP in VHD without loading ISO into RAM is working OK on Intel i5   :)

Writng the XP Setup ISO filename into the phony RAM disk is solving indeed the problem and there is no need to modify anything else ....

 

http://reboot.pro/to...-10#entry101891

 

 

The given reference corresponds to post given earlier on page-10 by Sha0  .... 

 

The menu.lst as given is not specific for i5 hardware and works as well for the AMD Dual core machine.

Also it will be possible to use similar solution for the case of Install of XP to partition.

 

I just took 0xA0 since that was used in the description by Sha0.....

 

:cheers:



#25 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15339 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 22 July 2013 - 04:57 PM

The given reference corresponds to post given earlier by Sha0  .... (whereas yours is referring to remark from karyonix as proposed solution)


Sure :), the given link is pointing to a post by karyonix :worship:, Author of Firadisk, that references a post by Sha0, which provided the method.

The thing I wanted to highlight (for the record) was that this info (though admittedly made partially invalid/difficult to follow because of the known issues created by the good IPB developers combined with our own good board experts) was that it was available on the previously referenced thread, like in "already invented wheel".

In the end, we are both getting exactly to the same place:
http://reboot.pro/to...-10#entry101891
though through different paths ;).

 

I suppose that the menu.lst as given  is also working on non-i5 hardware, but the problem to be solved occurred for me on i5 machine.
 
I just took 0xA0 since that was used in the proposal .....

Good, some tests with the "normal" (0xff) may be then needed, as there was *something* related to Winvblock using "specific" drive numbers:
http://reboot.pro/to...-12#entry119816
and cannot say if it applies to this and/or it has been changed afterwards/ever.
 
:cheers:
Wonko




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users