Booting XP(E) via a USB to PCI slotcard

[Dietmar]

Hi all,

I try to describe, why until now XP cant boot or been installed and run
via a USB to PCI slotcard.
I think, that this can be overcome, but only with very very hard
work...

I hope this is the only thing, why it not works, but I believe that.

You all remember the picture from dennis123123 in post

http://www.911cd.net/forums//index.php?s=&...ndpost&p=101657

I now know the exact reason of this:
There is simple no arcpath for the USBdrive, like

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP
Professional"

I tested this with the recovery console from XP CD and type there map
arc.
No arcpath can be seen at the compi from dennis123123.
Now I tried the following: On another computer with the same USB
harddisk
after typing map arc, I saw a wonderfull arcpath

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP
Professional"

for this USB harddisk. Now it is clear for me: If the Bios does not
recognice a harddisk at boottime,
the silly XP(E) is never able to repair this error, because in the
disk.sys driver there is no implementation of IoAssignArcName(), that
translates
\Device\Harddisk0\Partition1
to
multi(0)disk(0)rdisk(0)partition(1)

What a pain for Microsoft:
I can install and boot Win98 via the USB to PCI slotcard to any USB
device using the Iomega driver.

I did another test to be sure. I installed the recovery console to a
normal IDE harddisk.
I changed in its folder (cmdcons) the ntdetect.com against the modified
one.
Then I imported to registry the hive setupreg.hiv of the
recoveryconsole.
I modified there all the USB* entries as for USB boot wished.
I copied this hive as otto back and renamed it again setupreg.hiv .

Then I openend there txtsetup.sif and did all the changes as on XP
Slipstream CD for install on USB.

Then I connected the USB harddisk via USB to PCI slotcard and booted
the modified recoveryconsole from
normal harddisk: Typing map arc there, shows me again only the
arcpathes of the normal harddrive.

And the last test: I run Winobj.exe from normal Windows XP: Voila, no
arcpath can be seen for the connected USB harddisk via USB to PCI
slotcard.

To make it clear:
I always can see the files and folders on the USB harddisk, connected
via the USB to PCI slotcard.
But there is no arcpath for that USB harddisk, I only saw always
\Device\Harddisk0\Partition1
for that USB harddisk.

Puh ...but now I see clear, what has to be done :

There is a file called arcname.c from Reactos.

This driver arcname.sys has to start direct before disk.sys starts.

It simple translates the arcpath, asking ntoskernl.exe and give the
right arcpath to the waiting disk.sys.

This file has to be compiled for XP.

Perhaps it works also compiled for NT4, as Reactos did. Compiling for
XP isnt easy, because for example
it makes use of ntoskrnl.h, that isnt in the XP library. So you also
have to build a new library, that looks like
that from Reactos. But this will work, I am sure.
Another idea, that can be tested easy: There are special disk.sys from
Microsoft ,
called sometimes scsidisk.sys. Perhaps you are able to get one, with an
inbuild IoAssignArcName() routine.

I found one, but that gives blue screen about after 12 Seconds starting
for USB boot.

I think, that here are a lot of people, who understand what I am
writing and so they can help.

Nice to hear from you
Dietmar

 

[Dietmar]

Hi all,
does anybody know,

where IoAssignArcName() stores its values (in a buffer or the pointer
to that buffer) for

\\ArcName\\multi(0)disk(0)rdisk(0)partition(1)

in Unicode this must be

\\ArcName\\multi(0)disk(0)rdisk(0)partition(1)


I have a simple idea, and that are most the best


FAKE simple the Arcpath (Arcname) with the value above for the device,
which is noted (where?!) after ntdetect.com\ntldr detection as

\\Device\\Harddisk0\\Partition1

that is in Unicode

\\Device\\Harddisk0\\Partition1


simply by writing the first Unicode String to ram.

I dont understand, where these values have to stay that are mentioned
by

http://www.osronline.com/ddkx/kmarch/k104_60c2.htm

Nice to hear from you
Dietmar

EDIT: This side put my real Unicode String back to ASCII,...grr.
so it cant be seen anymore as Unicode.

 

[Dietmar]

Hi all,

you can begin to count hours, when booting XP(E) via a USB to PCI
slotcard will work.

When formulating as good as possible my own last question about faking
IoAssignArcName() here to the forum, I suddenly found its solution. It
is sooo easy.

Here is the C-source code for my driver arcname.sys, just written in 5
minutes...
(hihi... computers are no humans, you can make them think what ever you
want )



#include <ntddk.h>

WCHAR DeviceNameBuffer[80];
UNICODE_STRING DeviceName;

WCHAR ArcNameBuffer[80];
UNICODE_STRING ArcName;


VOID
{

swprintf(ArcNameBuffer,
L"\\ArcName\\multi(0)disk(0)rdisk(0)partition(1)");


RtlInitUnicodeString (&ArcName,
ArcNameBuffer);



swprintf(DeviceNameBuffer,
L"\\Device\\Harddisk0\\Partition1");


RtlInitUnicodeString(&DeviceName,
DeviceNameBuffer);

IoAssignArcName (&ArcName,
&DeviceName);

}

Do you think this will work?

This can easiest be compiled for NT4, Win2000, Win SP1, SP2 and Windows
2003, and Vista and Embedded SP1, SP2 and Reactos.

And one problem more is gone: I thought, that it may be a problem, to
make this driver start, just before disk.sys starts, not that the silly
XP(E) noticed, that it was faked and tries to zero some values:

I found in the WinDDK the source code for disk.sys.
I only need to put the few lines of my driver direct before the source
code of disk.c and compile them together.
And there is no chance left, that after that XP(E) has a (faked
Yippiehh) arcpath for the USB harddisk,
connected via my USB to PCI slotcard. Whether the new driver disk.sys
works, can be testet at once:
Even if XP(E) starts as normal from a IDE harddisk, if there is a USB
to PCI slotcard with a USB harddisk connected, there is no Arcpath for
that USB harddisk. Klicking on Winobj.exe, shows you at once
and brutal, whether the new driver disk.sys gives this USB harddisk a
Arcpath or not.

The only thing left, that I have to solve then, is the egg-chicken
problem: One day ago I thought, that with the recovery console you cant
start any program: But then I tested the command batch .
So you can run any program via the Recovery Console, simply hided in a
batch file.

Nice to hear from you
Dietmar

PS: Now I know: The blue screen with BSOD 0x7b is in most cases,
because my arcname.sys driver isnt build in, in disk.sys. And that does
Microsoft not know???