Run-time error '-2147221020 ( 800401e4)'

[Dietmar]

Hi Slobodan,
I took XPlite on a fresh XPPro installation and
takes simply ALL marks away. The result is 350MB.
I build an SDI image of THAT XPPro with boot and load blob and booted that
to ram, believe me or not.
Yes, now I have two ramdisks one from windows XPe (500MB) and one from
superspeed (2Gbyte) and I will try to boot in each one, but thats a hard
work.

Dietmar

 

[KM]

Slobodan,

What do you mean by that? How can you build a real XP Pro? It is either XP embedded or XPP, what is in between?

For instance, nLite (http://www.msfn.org/comments.php?shownews=11162).
However, it is hard to name it as "build".

 

[KM]

Dietmar,

I have no doubt you could RAM boot the 350Mb XP Pro "image".

But now you confused us more.. I thought you were trying to boot > 500Mb image.

 

[Slobodan Brcin \(eMVP\)]

Hi Dietmar,

I took XPlite on a fresh XPPro installation and
takes simply ALL marks away. The result is 350MB.
I build an SDI image of THAT XPPro with boot and load blob and booted that
to ram, believe me or not.

I was just curious. It is not a matter of belief.
XPlite has nothing to do with XPe and build terminology. I'm glad that we sorted that out.
350 MB is smaller than 500 MB so it is ok.
One more ingredient is missing here to make this work. What about ramdisk driver that you used with this test? Are you saying that
you just put third party driver without configuring it and it started to work?

Yes, now I have two ramdisks one from windows XPe (500MB) and one from
superspeed (2Gbyte) and I will try to boot in each one, but thats a hard
work.

ramdisk from XPe will work, that was never in question.
But I was under impression during all this time that you was able to use third-party ram disk driver.

Regards,
Slobodan

 

[Slobodan Brcin \(eMVP\)]

Hey don't post same answers before me

Slobodan

 

[KM]

Slobodan,

I probably just have a better internet connection (T1)

 

[Slobodan Brcin \(eMVP\)]

Konstantin,

And to that add few hundred milliseconds of ping time head-start that you have over us from Europe

Regards,
Slobodan

 

[Dietmar]

Hi Slobodan,
that is what I try. But I said always, that I do not succeed,for example
with syslinux.
But with syslinux I boot an image of 950MB real XPPRO (as SDI)to ram,
which doesnt boot. The image in ram is exactly the one as it was on
hardisk, not a single Bit hast changed.
I can prove that.
But is shows always the same behavior, loud beeping of the computer,
doesnt matter which size the image has.
Therefore I believe, that it might be possible, if Remi Lefevre tell us
the true. Only the bootloader doesnt found
the partition at the right place. If Remi booted an SDI image under
syslinux,I believe it could be much bigger, that ramdriver allows this.
One thing makes me astonish: The image in Ram is loaded AS HIGH AS
POSSIBLE. The NTLDR bootloader loads it as low as possible I think. But
that can be a very tricky thing, I know this from xmsdsk.exe in good old
DOS days.

Dietmar

 

[Slobodan Brcin \(eMVP\)]

Hi Dietmar,

Finally some useful info that we can discuss here. Although thus thread is pretty confusing till now. Please create new thread
regarding ONLY to third party boot of images larger than 500 MB and please do not put there your current issues with current MS way
that work.

Now to your points:

But with syslinux I boot an image of 950MB real XPPRO (as SDI)to ram,
which doesnt boot.

Actually you load disk image to memory and that do not boot. This was never in question if it is possible to be done. Question is
whether implementation in ntldr can handle such disk size. But this can be work-arounded. By careful file organization so all driver
files required for first part boot come to the beginning of that disk. And you can fake a size of disk to ntldr.

The image in ram is exactly the one as it was on
hardisk, not a single Bit hast changed.

I believe you, this also was never a problem.

But is shows always the same behavior, loud beeping of the computer,
doesnt matter which size the image has.
Therefore I believe, that it might be possible, if Remi Lefevre tell us
the true. Only the bootloader doesnt found
the partition at the right place.

Possible, but this is your problem. Also you said that you was able to do SDI RAM boot by using MS ntldr, so this mean that what
ever loader you are using you don't know how to configure it.
You can always make your own loader it is pretty simple and you have even working sources here in this NG posted by me.

If Remi booted an SDI image under
syslinux,I believe it could be much bigger, that ramdriver allows this.

Sorry could you give me a link again to article/tip that he wrote and that you are reffering to it constantly.
You are constantly mixing boot and "image load" terminology :-(

ramdriver was never preventing image load since image load happened mush before the OS start booting. This mean that there is no
ramdriver until everything is in memory.
MS RamDisk driver has limitation that is uses system address space that is very limited for its internal use. They simply did not
thought that for embedded usage someone would actually need more than 500 MB image I guess.

One thing makes me astonish: The image in Ram is loaded AS HIGH AS
POSSIBLE. The NTLDR bootloader loads it as low as possible I think. But
that can be a very tricky thing, I know this from xmsdsk.exe in good old
DOS days.

I complained on this when I lost a day fighting this. Loading image above 8MB should be ok, but the higher you go the better (to
avoid being overlapped during the initial driver load sequence).
ntoskrnl is the thing that must go low in memory and few other boot drivers everything else can go to empty memory.

Regards,
Slobodan

 

[Yann Blue]

On Tue, 28 Dec 2004 22:19:25 +0100, Slobodan Brcin (eMVP) wrote:

Hi,

Hi Dietmar,

Finally some useful info that we can discuss here. Although thus thread is pretty confusing till now. Please create new thread
regarding ONLY to third party boot of images larger than 500 MB and please do not put there your current issues with current MS way
that work.

Now to your points:

Actually you load disk image to memory and that do not boot. This was never in question if it is possible to be done. Question is
whether implementation in ntldr can handle such disk size. But this can be work-arounded. By careful file organization so all driver
files required for first part boot come to the beginning of that disk. And you can fake a size of disk to ntldr.

Slobodan is right: syslinux+SDI patch uses 32 bits addressing in
protected mode to load the SDI image in RAM, so it can load
images > 500 MB in RAM. But this
doesn't make Windows XPe able to handle it. I put a 500 MB limit on SDI
image sizes in the doc because of the default MS Ram Disk driver
limitation, however, because you could find another driver, it permits
bigger sizes.

I believe you, this also was never a problem.


Possible, but this is your problem. Also you said that you was able to do SDI RAM boot by using MS ntldr, so this mean that what
ever loader you are using you don't know how to configure it.
You can always make your own loader it is pretty simple and you have even working sources here in this NG posted by me.

Sorry could you give me a link again to article/tip that he wrote and that you are reffering to it constantly.
You are constantly mixing boot and "image load" terminology :-(

ramdriver was never preventing image load since image load happened mush before the OS start booting. This mean that there is no
ramdriver until everything is in memory.
MS RamDisk driver has limitation that is uses system address space that is very limited for its internal use. They simply did not
thought that for embedded usage someone would actually need more than 500 MB image I guess.


I complained on this when I lost a day fighting this. Loading image above 8MB should be ok, but the higher you go the better (to
avoid being overlapped during the initial driver load sequence).
ntoskrnl is the thing that must go low in memory and few other boot drivers everything else can go to empty memory.

Syslinux+SDI patch loads the image in RAM at 0x1000000h (I had issues when
loading below this limit). But as Slobodan said 'the higher you go the
better' is perhaps a better choice.

best regards,

Rémi