Dual Boot / Hal.dll

Hi,

I will try to be brief, but...

I am dealing with a computer that has been working fine for quite a while.
When it was turned off last week everything was fine. When my wife turned it
on the next day it wouldn't boot stating that the hal.dll was missing or
corrupt. She turned it off and left it that way. I checked it out later and
this is what I know:

1) It's a dual boot system, XP Pro and XP Pro, I don't know why. The
installation they had been using is the one with the hal.dll boot error. The
old installation works OK.

2) When you're in the old installation Windows shows 2 hard drives. The
first is partitioned. The second is not. Therefore drive(0)= C & D,
drive(1)=E. The old XP is on C:\, the new one is on F:\. The boot files are
on C:\.

3) The boot.ini file originally used the signature() syntax. Again, I don't
know why. Maybe it's leftover from a previous Win2K intallation? Maybe
because the E: drive is fairly large? AFAIK, they are just IDE drives.

4) Recovery console finds C:\windows and D:\windows. Rebuilding the
boot.ini file produces multi() instead of signature() but it still doesn't
work. Unfortunately, I can't recall if the rebuilt lines worked for the old
installation.

5) As expected, replacing the hal.dll with one from the working installation
made no difference.

6) My wife later noticed that the second drvie was disabled in bios. She
enabled it and rebuilt boot.ini. It didn't work and she says it produced an
scsi() line instead of multi() or signature()?

I think that rebuilding the boot.ini doesn't work because XP and recovery
console don't enumerate the drives the same way. I'll try enabling the
second drive in the bios and reverting to the original boot.ini, but I don't
think that will work. I'm hoping someone here has a quick fix for this, or
advice on what not to do. Can anyone tell me why this might have happened in
the first place?

Thanks for your help. Sorry if this post seems a little long and
disorganized, I can usually find all the answers to my windows questions here
so I don't post that often.

LDB

The use of signature() in boot.ini is explained in this KB article.

http://support.microsoft.com/kb/227704


My guess would be that you received the original error because of the
drive being disabled in the ROMBIOS. This would prevent the boot
loader from accessing the OS files on that drive through the ROMBIOS
int 13h disk interface.

Now that the drive is enabled in the ROMBIOS you should be able to
manually re-create the boot.ini line using signature() with the serial
number that is displayed when doing a DIR command on the root of the
drive containing the newer OS. You will also need to restore the
original hal file that you replaced.

John Hensley
www.resqware.com


On Tue, 15 May 2007 16:12:01 -0700, Monsterdog
wrote:

Hi,

I will try to be brief, but...

I am dealing with a computer that has been working fine for quite a while.
When it was turned off last week everything was fine. When my wife turned it
on the next day it wouldn't boot stating that the hal.dll was missing or
corrupt. She turned it off and left it that way. I checked it out later and
this is what I know:

1) It's a dual boot system, XP Pro and XP Pro, I don't know why. The
installation they had been using is the one with the hal.dll boot error. The
old installation works OK.

2) When you're in the old installation Windows shows 2 hard drives. The
first is partitioned. The second is not. Therefore drive(0)= C & D,
drive(1)=E. The old XP is on C:\, the new one is on F:\. The boot files are
on C:\.

3) The boot.ini file originally used the signature() syntax. Again, I don't
know why. Maybe it's leftover from a previous Win2K intallation? Maybe
because the E: drive is fairly large? AFAIK, they are just IDE drives.

4) Recovery console finds C:\windows and D:\windows. Rebuilding the
boot.ini file produces multi() instead of signature() but it still doesn't
work. Unfortunately, I can't recall if the rebuilt lines worked for the old
installation.

5) As expected, replacing the hal.dll with one from the working installation
made no difference.

6) My wife later noticed that the second drvie was disabled in bios. She
enabled it and rebuilt boot.ini. It didn't work and she says it produced an
scsi() line instead of multi() or signature()?

I think that rebuilding the boot.ini doesn't work because XP and recovery
console don't enumerate the drives the same way. I'll try enabling the
second drive in the bios and reverting to the original boot.ini, but I don't
think that will work. I'm hoping someone here has a quick fix for this, or
advice on what not to do. Can anyone tell me why this might have happened in
the first place?

Thanks for your help. Sorry if this post seems a little long and
disorganized, I can usually find all the answers to my windows questions here
so I don't post that often.

LDB

Thanks John,

Unfortunately that wasn't the solution. Thanks for the link. I had
already been to the KB, that's why I thought it might be because of the disk
size. I had hoped that that wouldn't apply to XP, oh well. I brought the
box home with me today so I'll get to bang on it at my leisure.

I thought the signature was something more arbitrary than the serial # from
the dir command; more like a random ID generated during an install. I also
thought I had read something about fdisk /mbr being dangerous to use on a
disk that uses the signature() syntax, I'll have to look that up again. I
use that command all the time and have never had a problem with it. I
probably would have tried it already, if the older installation didn't work.
If anybody can give me any info about RC's fixboot I'd be grateful.

A little more info:

It looks like this might have been caused by a failed/interrupted Windows
Update. The log shows that some updates were downloaded on the last day this
system was working, but the installations failed for some reason. Since I
can't boot into that version of XP I can't think of any way to fix that. I'm
open to any suggestions.

The working line in the boot.ini uses multi(0), it's the older smaller disk.
The signature(xxxxxxxx) line which should point to the newer install has an
rdisk value of one, I thought rdisk should be zero almost all the time. I
replaced the non-working line with the output from the map arc command, which
used multi(0)rdisk(0). I made the signature line look more like the line
from map arc. It still won't boot. I'm starting to think the boot.ini is
OK. I also don't think XP cares if the disk is on in the bios or not, the
working install doesn't care that C & D are on the same physical hard drive
and E is the secondary hard drive; I do, but it doesn't.

I'm not really sure what to do next. I'm going to extract the appropriate
Hal from the CD, but I don't think it will be any different than the one from
the working windows. I might try the hal.dll from one of the blue
NTuninstall folders. I might remove the primary hard drive and see what
happens with fixmbr. Anyway, I'm going to go clone the drives and see if I
can come up with any good ideas while I do that. Hopefully some brilliant
person will have answered with an incredibly simple solution by then.

Thanks, Len

"John Hensley" wrote:

The use of signature() in boot.ini is explained in this KB article.

http://support.microsoft.com/kb/227704


My guess would be that you received the original error because of the
drive being disabled in the ROMBIOS. This would prevent the boot
loader from accessing the OS files on that drive through the ROMBIOS
int 13h disk interface.

Now that the drive is enabled in the ROMBIOS you should be able to
manually re-create the boot.ini line using signature() with the serial
number that is displayed when doing a DIR command on the root of the
drive containing the newer OS. You will also need to restore the
original hal file that you replaced.

John Hensley
www.resqware.com

On Wed, 16 May 2007 16:46:00 -0700, Monsterdog
wrote:

I thought the signature was something more arbitrary than the serial # from
the dir command; more like a random ID generated during an install. I also
thought I had read something about fdisk /mbr being dangerous to use on a
disk that uses the signature() syntax, I'll have to look that up again. I
use that command all the time and have never had a problem with it. I
probably would have tried it already, if the older installation didn't work.
If anybody can give me any info about RC's fixboot I'd be grateful.

You are right the signature is not just the serial number because that
would not help locate the drive. I re-read the KB article and it says
that the value is the disk signature. Fortunately the disk signature
can be found in the registry under the HKLM\System\MountedDevices key
under the value associated with the drive such as "\DosDevices\C:".

Hard drive entries should have 12 hex bytes associated with the value
and the first 4 of these bytes is the disk signature while the
remaining 8 are the offset for the starting sector of the partition.
Since the signature is an Intel DWORD value you will need to
reversion the order of the bytes to get the string to use in boot.ini
for example if the first 4 bytes are 0d 75 21 44 you would use
Signature(4421750d).


A little more info:
...snip

The working line in the boot.ini uses multi(0), it's the older smaller disk.
The signature(xxxxxxxx) line which should point to the newer install has an
rdisk value of one, I thought rdisk should be zero almost all the time.

Rdisk() specifies the physical hard disk number with rdisk(0)
representing the first hard drive seen by the ROMBIOS, 80h and
rdisk(1) representing the second hard disk seen by the ROMBIOS, 81h.
See the information about the Z parameter for information about this.

http://support.microsoft.com/kb/102873
MULTI(X) Syntax

I
replaced the non-working line with the output from the map arc command, which
used multi(0)rdisk(0). I made the signature line look more like the line
from map arc. It still won't boot. I'm starting to think the boot.ini is
OK. I also don't think XP cares if the disk is on in the bios or not, the
working install doesn't care that C & D are on the same physical hard drive
and E is the secondary hard drive; I do, but it doesn't.

XP can't boot from a drive that isn't accessible by the ROMBIOS using
a multi() boot.ini string. See:

http://support.microsoft.com/kb/102873
MULTI(X) Syntax

I'm not really sure what to do next. I'm going to extract the appropriate
Hal from the CD, but I don't think it will be any different than the one from
the working windows. I might try the hal.dll from one of the blue
NTuninstall folders. I might remove the primary hard drive and see what
happens with fixmbr. Anyway, I'm going to go clone the drives and see if I
can come up with any good ideas while I do that. Hopefully some brilliant
person will have answered with an incredibly simple solution by then.

If you are getting a message from the boot loader saying it can't find
the hal I believe it can only be related to the boot.ini processing
and must have something to do with NTLOADER not being able to get to
the hal file using the ROMBIOS int 13h interface to read from the
drive. If NTLOADER is successful loading the files via the 13h ROMBIOS
interface you would not see this message but would see the normal BSOD
with a STOP number on it.

John Hensley
www.resqware.com

John,

Thanks for the info about finding the signature. I'm basically going to
assume that the signature line is correct for now. I mistyped earlier.
Where I wrote rdisk I meant to write just disk. I also don't think it has to
do with windows update anymore.

What I meant to say:

The working line in the boot.ini uses multi(0), it's the older smaller disk.
The signature(xxxxxxxx) line which should point to the newer install has an
disk value of one, I thought disk should be zero almost all the time.

XP can't boot from a drive that isn't accessible by the ROMBIOS using
a multi() boot.ini string.

Doesn't the fact that 'map arc' gives me a multi() format line show that the
drive is accessible through the bios? I would have thought that that line
would work.

I guess the purpose of the signature syntax is to overcome bios limitations?
Is that why it uses a disk(1) when the 'map arc' produced multi line uses
disk(0)?

I don't really want to re-install over the non-working installation because
that would require re-installing programs and losing settings. If it comes
to that, I'd feel better about a clean install. It's not mine so I'll keep
trying to put it back the way it was until a clean install becomes necessary.

If it really is the boot.ini process not being able to locate hal.dll on the
big hard drive, and RC's bootcfg doesn't produce a working boot.ini, how do I
deal with this. I doubt that fixmbr or fixboot are necessary in this
situation because the old system still boots, am I wrong? I'm kind of
itching to take the small drive out and make the big drive bootable to see
what happens, but I'd like to try something potentially less destructive
first.

Thanks again, Len

"John Hensley" wrote:

On Wed, 16 May 2007 16:46:00 -0700, Monsterdog
wrote:

I thought the signature was something more arbitrary than the serial # from
the dir command; more like a random ID generated during an install. I also
thought I had read something about fdisk /mbr being dangerous to use on a
disk that uses the signature() syntax, I'll have to look that up again. I
use that command all the time and have never had a problem with it. I
probably would have tried it already, if the older installation didn't work.
If anybody can give me any info about RC's fixboot I'd be grateful.

You are right the signature is not just the serial number because that
would not help locate the drive. I re-read the KB article and it says
that the value is the disk signature. Fortunately the disk signature
can be found in the registry under the HKLM\System\MountedDevices key
under the value associated with the drive such as "\DosDevices\C:".

Hard drive entries should have 12 hex bytes associated with the value
and the first 4 of these bytes is the disk signature while the
remaining 8 are the offset for the starting sector of the partition.
Since the signature is an Intel DWORD value you will need to
reversion the order of the bytes to get the string to use in boot.ini
for example if the first 4 bytes are 0d 75 21 44 you would use
Signature(4421750d).


A little more info:
...snip

The working line in the boot.ini uses multi(0), it's the older smaller disk.
The signature(xxxxxxxx) line which should point to the newer install has an
rdisk value of one, I thought rdisk should be zero almost all the time.

Rdisk() specifies the physical hard disk number with rdisk(0)
representing the first hard drive seen by the ROMBIOS, 80h and
rdisk(1) representing the second hard disk seen by the ROMBIOS, 81h.
See the information about the Z parameter for information about this.

http://support.microsoft.com/kb/102873
MULTI(X) Syntax

I
replaced the non-working line with the output from the map arc command, which
used multi(0)rdisk(0). I made the signature line look more like the line
from map arc. It still won't boot. I'm starting to think the boot.ini is
OK. I also don't think XP cares if the disk is on in the bios or not, the
working install doesn't care that C & D are on the same physical hard drive
and E is the secondary hard drive; I do, but it doesn't.

XP can't boot from a drive that isn't accessible by the ROMBIOS using
a multi() boot.ini string. See:

http://support.microsoft.com/kb/102873
MULTI(X) Syntax

I'm not really sure what to do next. I'm going to extract the appropriate
Hal from the CD, but I don't think it will be any different than the one from
the working windows. I might try the hal.dll from one of the blue
NTuninstall folders. I might remove the primary hard drive and see what
happens with fixmbr. Anyway, I'm going to go clone the drives and see if I
can come up with any good ideas while I do that. Hopefully some brilliant
person will have answered with an incredibly simple solution by then.

If you are getting a message from the boot loader saying it can't find
the hal I believe it can only be related to the boot.ini processing
and must have something to do with NTLOADER not being able to get to
the hal file using the ROMBIOS int 13h interface to read from the
drive. If NTLOADER is successful loading the files via the 13h ROMBIOS
interface you would not see this message but would see the normal BSOD
with a STOP number on it.

John Hensley
www.resqware.com

On Thu, 17 May 2007 12:41:01 -0700, Monsterdog
wrote:

John,

Thanks for the info about finding the signature. I'm basically going to
assume that the signature line is correct for now. I mistyped earlier.
Where I wrote rdisk I meant to write just disk. I also don't think it has to
do with windows update anymore.

What I meant to say:

The working line in the boot.ini uses multi(0), it's the older smaller disk.
The signature(xxxxxxxx) line which should point to the newer install has an
disk value of one, I thought disk should be zero almost all the time.

You are correct, the KB article says disk is always 0 for a drive
accessible via the ROMBIOS. Unfortunately it does specify what it
should when using Signature(). The example use a 1.

XP can't boot from a drive that isn't accessible by the ROMBIOS using
a multi() boot.ini string.

Doesn't the fact that 'map arc' gives me a multi() format line show that the
drive is accessible through the bios? I would have thought that that line
would work.

(This section became irrelevant after I re-read the documentation for
Signature() but I left it un because it might be interesting but don't
waste any time trying to doing any of the suggestions. The real
solution is down below)

The reason for this is that when 'map arc' runs it is going through
the normal disk driver which reads sectors from the disk directly
through the disk controller and gets the correct disk geometry
directly from the drive itself.

When NTLOADER runs it uses the ROMBIOS to read sectors and if the
ROMBIOS is not setup with the correct disk geometry everything past
the first cylinder might be useless because the disk layout is
incorrect.

If the geometry is correct but the ROMBIOS does not support 1024
cylinders and the hal happens to be located someone on the disk past
the first 1024 cylinder it won't be access able.

The only way I know to test for this would be to boot from an MS-DOS
floppy, run debug and then enter some assembly code to query the
layout of the drive and see if it matches the real drive layout.

One more thing that could be an issue is if the large drive contains
special software like OnTrack in the first track that hooks the int
13h interface to provide the correct layout for the drive or
implements the int 13h large disk extensions. You could test for this
by swapping the mapping of the drives so that the problem drive is
seen as the first drive. The ROMBIOS may support this and if not you
could simple reverse the master slave order or change the cable if
each driver is on a separate cable.

If booting from the drive this way works it would confirm that OnTrack
type of software is installed on the drive.


I guess the purpose of the signature syntax is to overcome bios limitations?
Is that why it uses a disk(1) when the 'map arc' produced multi line uses
disk(0)?

I re-read the KB article about signature() one more time and saw
something else I missed. The signature() arc name is equivalent to the
scsi() arc name which means that you need to have the driver file
located in the root directory of the boot drive. You need to copy the
Ntbootdd.sys from the second drive to the first drive and use the
signature() arc format.

I knew about this requirement when using the scsi() arc name but I had
never seen anything about signature() arc names. Your reference to it
made me curious enough to start this exchange. Now everything almost
makes sense. The documentation says that for multi() the disk(0) means
to use the bios but for scis() the disk() value specifies the scsi
unit id. I'd bet that since under multi() the disk(0) means use the
ROMBIOS under Signature() the disk(1) means don't use the ROMBIOS. The
documentation is not clear about what should be used here but I'd
first try disk(1) and if that doesn't work make sure to use the number
that matches the unit the drive is on the controller (0 for master 1
for slave).

Let me know whether this works, which value you used for the disk()
value and whether the drive is a master or slave. This information
will most certainly be useful to me in the future.

BTW if it makes it easier you can email me directly using "john at
resqware dot com" after replacing the at and dot.

Regards,
John Hensley
www.resqware.com

John,

First of all, thanks for all the help. I really appreciate all the effort
you've put into this.

I can't believe that I missed the (1) in the signature example. I must have
read that page 10 times. I feel like an idiot.

I had thought of the ntbootdd.sys and had checked that it was there, which
it was. After your post I replaced it and was still stuck in the same
situation. Good idea, though.

I'm glad I didn't skip the 'irrelevant' section because it gave me an idea.
You mentioned the 1024 cylinder barrier and that the hal may have moved
beyond that or beyond the first int13 hook. I decided to run norton speed
disk and request that hal be moved to the beginning of the drive. It didn't
work, but it has made things much more interesting.

I don't have enough time to go into the details, but I wanted to let you
know where we're at here.

Moved hal: now the error is missing ntfs.sys. Copied ntfs.sys from CD: we
boot as far as the Windos logo then BSOD. There's something going on with
the boot.ini paths. I'll post a more detailed message later.

Thanks alot,
Len

"John Hensley" wrote:

On Thu, 17 May 2007 12:41:01 -0700, Monsterdog
wrote:

John,

Thanks for the info about finding the signature. I'm basically going to
assume that the signature line is correct for now. I mistyped earlier.
Where I wrote rdisk I meant to write just disk. I also don't think it has to
do with windows update anymore.

What I meant to say:

The working line in the boot.ini uses multi(0), it's the older smaller disk.
The signature(xxxxxxxx) line which should point to the newer install has an
disk value of one, I thought disk should be zero almost all the time.

You are correct, the KB article says disk is always 0 for a drive
accessible via the ROMBIOS. Unfortunately it does specify what it
should when using Signature(). The example use a 1.

XP can't boot from a drive that isn't accessible by the ROMBIOS using
a multi() boot.ini string.

Doesn't the fact that 'map arc' gives me a multi() format line show that the
drive is accessible through the bios? I would have thought that that line
would work.

(This section became irrelevant after I re-read the documentation for
Signature() but I left it un because it might be interesting but don't
waste any time trying to doing any of the suggestions. The real
solution is down below)

The reason for this is that when 'map arc' runs it is going through
the normal disk driver which reads sectors from the disk directly
through the disk controller and gets the correct disk geometry
directly from the drive itself.

When NTLOADER runs it uses the ROMBIOS to read sectors and if the
ROMBIOS is not setup with the correct disk geometry everything past
the first cylinder might be useless because the disk layout is
incorrect.

If the geometry is correct but the ROMBIOS does not support 1024
cylinders and the hal happens to be located someone on the disk past
the first 1024 cylinder it won't be access able.

The only way I know to test for this would be to boot from an MS-DOS
floppy, run debug and then enter some assembly code to query the
layout of the drive and see if it matches the real drive layout.

One more thing that could be an issue is if the large drive contains
special software like OnTrack in the first track that hooks the int
13h interface to provide the correct layout for the drive or
implements the int 13h large disk extensions. You could test for this
by swapping the mapping of the drives so that the problem drive is
seen as the first drive. The ROMBIOS may support this and if not you
could simple reverse the master slave order or change the cable if
each driver is on a separate cable.

If booting from the drive this way works it would confirm that OnTrack
type of software is installed on the drive.


I guess the purpose of the signature syntax is to overcome bios limitations?
Is that why it uses a disk(1) when the 'map arc' produced multi line uses
disk(0)?

I re-read the KB article about signature() one more time and saw
something else I missed. The signature() arc name is equivalent to the
scsi() arc name which means that you need to have the driver file
located in the root directory of the boot drive. You need to copy the
Ntbootdd.sys from the second drive to the first drive and use the
signature() arc format.

I knew about this requirement when using the scsi() arc name but I had
never seen anything about signature() arc names. Your reference to it
made me curious enough to start this exchange. Now everything almost
makes sense. The documentation says that for multi() the disk(0) means
to use the bios but for scis() the disk() value specifies the scsi
unit id. I'd bet that since under multi() the disk(0) means use the
ROMBIOS under Signature() the disk(1) means don't use the ROMBIOS. The
documentation is not clear about what should be used here but I'd
first try disk(1) and if that doesn't work make sure to use the number
that matches the unit the drive is on the controller (0 for master 1
for slave).

Let me know whether this works, which value you used for the disk()
value and whether the drive is a master or slave. This information
will most certainly be useful to me in the future.

BTW if it makes it easier you can email me directly using "john at
resqware dot com" after replacing the at and dot.

Regards,
John Hensley
www.resqware.com

Len,

I'm glad you are making progress. Since you are getting the BSOD
during the logo I would suggest adding /noguiboot to the end of the
line for this drive in the boot.ini. Doing this will cause the name of
each boot load driver to be printed on the display as it is pre-loaded
into memory. The last driver displayed is usually the one that is
can't be located unless something other than not being able to access
a file is causing the problem.

Also what is the STOP number and message on the BSOD?

The fact that you had to move the hal to the begriming of the disk
tells me that we are still missing something obvious but I don't know
what it could be.

If you are using the signature() format for the arc name and
ntbootdd.sys is being used to access the disk, then it just doesn't
make sense that the 1024 cylinder boundary would cause a problem
because ntbootdd.sys goes directly to the disk controller and should
be able to get to any location on the disk.

I'm wondering if somehow ntbootdd.sys is looking at something else in
addition to what the drive tells it in order to determine the real
disk layout. What happens if you disable the drive in the ROMBIOS when
using use the signature() line for this drive?

If you had a dual machine setup with a serial or 1394 connection you
could use WinDbg to catch the crash and then use the !analyze command
to determine exactly what caused the crash.

I'm going to do a little more research on using singature() and will
let you know if I run across anything that might shed some addional
light on this. Please keep me posted on anything new you find out.

Regards,
John Hensley
www.resqware.com



On Fri, 18 May 2007 12:31:00 -0700, Monsterdog
wrote:

John,

First of all, thanks for all the help. I really appreciate all the effort
you've put into this.

I can't believe that I missed the (1) in the signature example. I must have
read that page 10 times. I feel like an idiot.

I had thought of the ntbootdd.sys and had checked that it was there, which
it was. After your post I replaced it and was still stuck in the same
situation. Good idea, though.

I'm glad I didn't skip the 'irrelevant' section because it gave me an idea.
You mentioned the 1024 cylinder barrier and that the hal may have moved
beyond that or beyond the first int13 hook. I decided to run norton speed
disk and request that hal be moved to the beginning of the drive. It didn't
work, but it has made things much more interesting.

I don't have enough time to go into the details, but I wanted to let you
know where we're at here.

Moved hal: now the error is missing ntfs.sys. Copied ntfs.sys from CD: we
boot as far as the Windos logo then BSOD. There's something going on with
the boot.ini paths. I'll post a more detailed message later.

Thanks alot,
Len

John,

I was actually working on a reply when yours came in.

Here's the meat though:

boot.ini:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="WORKI NG R(0) P(1)" /fastdetect
/NoExecute=OptIn

multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="MULTI D(0) R(1) P(1)" /fastdetect

signature(a22d0f55)disk(1)rdisk(1)partition(0)\WIN DOWS="SIG D(1) P(0)
ORIGINAL" /fastdetect

signature(a22d0f55)disk(1)rdisk(1)partition(1)\WIN DOWS="SIG D(1) P(1)
LYNDAS" /fastdetect

***
OK- These 4 entries a
1) Working-obviously the old c:\windows install
2) The multi line produced by boot.cfg for d:\windows
3) The original line from the first boot.ini file for d:\windows
4) The line my wife says is "obviously right!"

2-4 all produced the hal error from the beginning. The multi line was much
faster(no driver to load).

After moving hal with speed disk:
2 and 4 produce ntfs error, 3 the original boot.ini line continues showing
the hal error.

After copying over ntfs.sys:
2 and 4 get to the windows splash screen then BSOD and reboot, 3 still gets
hal.

I wouldn't have even kept testing the 4 option since it produced the same
error as the others at first, but my wife made me. Although I do believe the
multi line will work in the long run. Anything stranger than that in the ini
and we get the "hardware configuration" error.

I turned the drive off in the bios. It made no difference. I'll try
/noguiboot.

Unfortunately, the box reboots so I can't read the screen. Maybe the switch
will provide the info though.

I was trying to keep this short! I'll post anything else I think of when I
post the /noguiboot results.

I hope this isn't totally driving you crazy.

Thanks again,
Len


"John Hensley" wrote:

Len,

I'm glad you are making progress. Since you are getting the BSOD
during the logo I would suggest adding /noguiboot to the end of the
line for this drive in the boot.ini. Doing this will cause the name of
each boot load driver to be printed on the display as it is pre-loaded
into memory. The last driver displayed is usually the one that is
can't be located unless something other than not being able to access
a file is causing the problem.

Also what is the STOP number and message on the BSOD?

The fact that you had to move the hal to the begriming of the disk
tells me that we are still missing something obvious but I don't know
what it could be.

If you are using the signature() format for the arc name and
ntbootdd.sys is being used to access the disk, then it just doesn't
make sense that the 1024 cylinder boundary would cause a problem
because ntbootdd.sys goes directly to the disk controller and should
be able to get to any location on the disk.

I'm wondering if somehow ntbootdd.sys is looking at something else in
addition to what the drive tells it in order to determine the real
disk layout. What happens if you disable the drive in the ROMBIOS when
using use the signature() line for this drive?

If you had a dual machine setup with a serial or 1394 connection you
could use WinDbg to catch the crash and then use the !analyze command
to determine exactly what caused the crash.

I'm going to do a little more research on using singature() and will
let you know if I run across anything that might shed some addional
light on this. Please keep me posted on anything new you find out.

Regards,
John Hensley
www.resqware.com



On Fri, 18 May 2007 12:31:00 -0700, Monsterdog
wrote:

John,

First of all, thanks for all the help. I really appreciate all the effort
you've put into this.

I can't believe that I missed the (1) in the signature example. I must have
read that page 10 times. I feel like an idiot.

I had thought of the ntbootdd.sys and had checked that it was there, which
it was. After your post I replaced it and was still stuck in the same
situation. Good idea, though.

I'm glad I didn't skip the 'irrelevant' section because it gave me an idea.
You mentioned the 1024 cylinder barrier and that the hal may have moved
beyond that or beyond the first int13 hook. I decided to run norton speed
disk and request that hal be moved to the beginning of the drive. It didn't
work, but it has made things much more interesting.

I don't have enough time to go into the details, but I wanted to let you
know where we're at here.

Moved hal: now the error is missing ntfs.sys. Copied ntfs.sys from CD: we
boot as far as the Windos logo then BSOD. There's something going on with
the boot.ini paths. I'll post a more detailed message later.

Thanks alot,
Len

Hi again,

Sorry I didn't respond sooner. I was busy hating the person who thought of
that stupid reboot after failure thing. The people who work for MS are
supposed to be smart.

RECAP:
Dell 4300: working fine, shutdown, reboot to hal error.
The usual solutions didn't make a difference.
Norton Speed Disk to move hal to the beginning of the disk - ntfs.sys error.
Moved the whole system32 dir to the beginning, copied ntfs.sys from CD now
we get the splash screen and get a BSOD.
Safe Mode Command Prompt shows that AGP440.sys is where it stops. Disabling
it doesn't help. The BSOD is :
SESSION5_INITIALIZATION_FAILED
STOP: 0x00000071 the rest of it is all zeroes.
BTW, the drives are cable select.

There is nothing new on this computer. I took out the USB/Firewire card
because that had less dust than the others. It can't really be a hardware
issue because the other installation boots and runs just fine.

My thoughts:
The new drive was installed and XP was loaded onto it without the drive
being turned on in the bios. That is why the boot.ini used signature().
That still doesn't explain why it chose partition(0), I think that still
worked because partition(0) doesn't exist.

Something happened recently that caused hal.dll to be moved to a spot where
the bootloader couldn't find it. That same something, or the messing around
trying to fix it, caused more problems.

I think the multi line for the boot.ini will work fine now that the drive is
on in the bios. I don't understand why the original signature line is still
giving the hal error when the other lines make it to the BSOD.

I don't really know what to do besides a repair install in this situation.
I doubt it has anything to do with the video as the last driver listed might
suggest. I'm not sure what the session initialization error means. My
initial searches didn't turn up much.

Thanks again John, you've been great.
Thanks to anyone else who gave this some thought, as well.

I think I will start another post if I keep trying to fix this, as the
current title doesn't seem to apply anymore.

Thanks,
Len

"Monsterdog" wrote:

John,

I was actually working on a reply when yours came in.

Here's the meat though:

boot.ini:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOW S
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="WORKI NG R(0) P(1)" /fastdetect
/NoExecute=OptIn

multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="MULTI D(0) R(1) P(1)" /fastdetect

signature(a22d0f55)disk(1)rdisk(1)partition(0)\WIN DOWS="SIG D(1) P(0)
ORIGINAL" /fastdetect

signature(a22d0f55)disk(1)rdisk(1)partition(1)\WIN DOWS="SIG D(1) P(1)
LYNDAS" /fastdetect

***
OK- These 4 entries a
1) Working-obviously the old c:\windows install
2) The multi line produced by boot.cfg for d:\windows
3) The original line from the first boot.ini file for d:\windows
4) The line my wife says is "obviously right!"

2-4 all produced the hal error from the beginning. The multi line was much
faster(no driver to load).

After moving hal with speed disk:
2 and 4 produce ntfs error, 3 the original boot.ini line continues showing
the hal error.

After copying over ntfs.sys:
2 and 4 get to the windows splash screen then BSOD and reboot, 3 still gets
hal.

I wouldn't have even kept testing the 4 option since it produced the same
error as the others at first, but my wife made me. Although I do believe the
multi line will work in the long run. Anything stranger than that in the ini
and we get the "hardware configuration" error.

I turned the drive off in the bios. It made no difference. I'll try
/noguiboot.

Unfortunately, the box reboots so I can't read the screen. Maybe the switch
will provide the info though.

I was trying to keep this short! I'll post anything else I think of when I
post the /noguiboot results.

I hope this isn't totally driving you crazy.

Thanks again,
Len


"John Hensley" wrote:

Len,

I'm glad you are making progress. Since you are getting the BSOD
during the logo I would suggest adding /noguiboot to the end of the
line for this drive in the boot.ini. Doing this will cause the name of
each boot load driver to be printed on the display as it is pre-loaded
into memory. The last driver displayed is usually the one that is
can't be located unless something other than not being able to access
a file is causing the problem.

Also what is the STOP number and message on the BSOD?

The fact that you had to move the hal to the begriming of the disk
tells me that we are still missing something obvious but I don't know
what it could be.

If you are using the signature() format for the arc name and
ntbootdd.sys is being used to access the disk, then it just doesn't
make sense that the 1024 cylinder boundary would cause a problem
because ntbootdd.sys goes directly to the disk controller and should
be able to get to any location on the disk.

I'm wondering if somehow ntbootdd.sys is looking at something else in
addition to what the drive tells it in order to determine the real
disk layout. What happens if you disable the drive in the ROMBIOS when
using use the signature() line for this drive?

If you had a dual machine setup with a serial or 1394 connection you
could use WinDbg to catch the crash and then use the !analyze command
to determine exactly what caused the crash.

I'm going to do a little more research on using singature() and will
let you know if I run across anything that might shed some addional
light on this. Please keep me posted on anything new you find out.

Regards,
John Hensley
www.resqware.com



On Fri, 18 May 2007 12:31:00 -0700, Monsterdog
wrote:

John,

First of all, thanks for all the help. I really appreciate all the effort
you've put into this.

I can't believe that I missed the (1) in the signature example. I must have
read that page 10 times. I feel like an idiot.

I had thought of the ntbootdd.sys and had checked that it was there, which
it was. After your post I replaced it and was still stuck in the same
situation. Good idea, though.

I'm glad I didn't skip the 'irrelevant' section because it gave me an idea.
You mentioned the 1024 cylinder barrier and that the hal may have moved
beyond that or beyond the first int13 hook. I decided to run norton speed
disk and request that hal be moved to the beginning of the drive. It didn't
work, but it has made things much more interesting.

I don't have enough time to go into the details, but I wanted to let you
know where we're at here.

Moved hal: now the error is missing ntfs.sys. Copied ntfs.sys from CD: we
boot as far as the Windos logo then BSOD. There's something going on with
the boot.ini paths. I'll post a more detailed message later.

Thanks alot,
Len

On Sun, 20 May 2007 12:16:00 -0700, Monsterdog
wrote:

Hi again,

Sorry I didn't respond sooner. I was busy hating the person who thought of
that stupid reboot after failure thing. The people who work for MS are
supposed to be smart.

RECAP:
Dell 4300: working fine, shutdown, reboot to hal error.
The usual solutions didn't make a difference.
Norton Speed Disk to move hal to the beginning of the disk - ntfs.sys error.
Moved the whole system32 dir to the beginning, copied ntfs.sys from CD now
we get the splash screen and get a BSOD.
Safe Mode Command Prompt shows that AGP440.sys is where it stops. Disabling

You said you moved all of the files in the System32 directory but did
you also move those in the System32\Drivers directory? This is
directory that contains all of the boot load drivers such as
AGP440.sys. The boot loader also needs to be able to get to the system
registry hive in SYSTEM32\config.

it doesn't help. The BSOD is :
SESSION5_INITIALIZATION_FAILED
STOP: 0x00000071 the rest of it is all zeroes.
BTW, the drives are cable select.

This message means the session manger could not be initialized and is
caused by a problem accessing a device driver which are normally
located in System32\drivers.

There is nothing new on this computer. I took out the USB/Firewire card
because that had less dust than the others. It can't really be a hardware
issue because the other installation boots and runs just fine.

My thoughts:
The new drive was installed and XP was loaded onto it without the drive
being turned on in the bios. That is why the boot.ini used signature().

That makes sense. By "loaded onto it" do you mean the Windows Setup
program installed it on this drive?

That still doesn't explain why it chose partition(0), I think that still
worked because partition(0) doesn't exist.

I found an article with additional information about using signature()
in the XP resource kit.

http://www.microsoft.com/technet/pro...c29621675.mspx

In this article it states in "Table 29-12 Signature() Parameters" for
the partition() number.

"The partition number on the physical disk with a signature matching
V. The first valid number is 1.".

This statement makes it clear that the partition should never be 0.
This table also answer the question about the rdisk() value stating
"This value is always 0 when the signature() syntax is used."


Something happened recently that caused hal.dll to be moved to a spot where
the bootloader couldn't find it. That same something, or the messing around
trying to fix it, caused more problems.

You've already proven that moving the hal to the start of the disk
allowed the bootloader to find it so we know (maybe) that your ROMBIOS
is not configured to allow reading beyond the 1024 cylinder limit.

I think the multi line for the boot.ini will work fine now that the drive is
on in the bios. I don't understand why the original signature line is still
giving the hal error when the other lines make it to the BSOD.

This is what is confusing me and making me think that we are still not
understanding how the signature() arc name should be configured. I'd
like to set up a test system and then disable the disk in ROMBIOS
after adding a signature() line to see if I can make it work.

To do this I really need to know what driver file was being used for
the Ntbootdd.sys. I am hoping you can right click on the Ntbootdd.sys
file and then select the version tab and then "Original File name" to
get the real name of the driver for me. Also the Description would be
helpful.

John Hensley
www.resqware.com

Hi John,

I guess you don't ever take a day off.

You said you moved all of the files in the System32 directory but did
you also move those in the System32\Drivers directory? This is
directory that contains all of the boot load drivers such as
AGP440.sys. The boot loader also needs to be able to get to the system
registry hive in SYSTEM32\config.

I first added D:\WINDOWS\System32\hal.dll to Speed Disks 'files first'
section. When I added \System32\drivers\ntfs.sys to the list I also added
/System32/*.* even though I thought it was redundant. I'll try being more
specific, pehaps Speed Disk does not include subdirs when processing
wildcards.

That makes sense. By "loaded onto it" do you mean the Windows Setup
program installed it on this drive?

My best guess is that when the new HD was purchased the owner just plugged
it into a free bay, booted what is now the only working install of windows
and stuck his XP Pro upgrade disc in the CD. He didn't check the bios or
anything else because everything seemed to work. Then he performed a
parallel install to the new drive as D:\.

Thanks for the link to the boot process info. It looks promising. The
partition(0) bugs me, too. If anyone told me that their boot.ini read like
that I would just figure they got it wrong. I almost think that I must have
changed it by accident when I first checked it out. If that line gave the
hardware error instead of the hal I would be sure I did.

Ntbootdd.sys is Ver. 5.1.2600.0
original filename: ataboot.sys
ATAPI Miniport Driver for Ntbootdd.sys

I'm not sure what's going on here. I hope I get the chance to figure it out
before I actually have to fix the thing.

Hope you had a good weekend,
Len



"John Hensley" wrote:

On Sun, 20 May 2007 12:16:00 -0700, Monsterdog
wrote:

Hi again,

Sorry I didn't respond sooner. I was busy hating the person who thought of
that stupid reboot after failure thing. The people who work for MS are
supposed to be smart.

RECAP:
Dell 4300: working fine, shutdown, reboot to hal error.
The usual solutions didn't make a difference.
Norton Speed Disk to move hal to the beginning of the disk - ntfs.sys error.
Moved the whole system32 dir to the beginning, copied ntfs.sys from CD now
we get the splash screen and get a BSOD.
Safe Mode Command Prompt shows that AGP440.sys is where it stops. Disabling

You said you moved all of the files in the System32 directory but did
you also move those in the System32\Drivers directory? This is
directory that contains all of the boot load drivers such as
AGP440.sys. The boot loader also needs to be able to get to the system
registry hive in SYSTEM32\config.

it doesn't help. The BSOD is :
SESSION5_INITIALIZATION_FAILED
STOP: 0x00000071 the rest of it is all zeroes.
BTW, the drives are cable select.

This message means the session manger could not be initialized and is
caused by a problem accessing a device driver which are normally
located in System32\drivers.

There is nothing new on this computer. I took out the USB/Firewire card
because that had less dust than the others. It can't really be a hardware
issue because the other installation boots and runs just fine.

My thoughts:
The new drive was installed and XP was loaded onto it without the drive
being turned on in the bios. That is why the boot.ini used signature().

That makes sense. By "loaded onto it" do you mean the Windows Setup
program installed it on this drive?

That still doesn't explain why it chose partition(0), I think that still
worked because partition(0) doesn't exist.

I found an article with additional information about using signature()
in the XP resource kit.

http://www.microsoft.com/technet/pro...c29621675.mspx

In this article it states in "Table 29-12 Signature() Parameters" for
the partition() number.

"The partition number on the physical disk with a signature matching
V. The first valid number is 1.".

This statement makes it clear that the partition should never be 0.
This table also answer the question about the rdisk() value stating
"This value is always 0 when the signature() syntax is used."


Something happened recently that caused hal.dll to be moved to a spot where
the bootloader couldn't find it. That same something, or the messing around
trying to fix it, caused more problems.

You've already proven that moving the hal to the start of the disk
allowed the bootloader to find it so we know (maybe) that your ROMBIOS
is not configured to allow reading beyond the 1024 cylinder limit.

I think the multi line for the boot.ini will work fine now that the drive is
on in the bios. I don't understand why the original signature line is still
giving the hal error when the other lines make it to the BSOD.

This is what is confusing me and making me think that we are still not
understanding how the signature() arc name should be configured. I'd
like to set up a test system and then disable the disk in ROMBIOS
after adding a signature() line to see if I can make it work.

To do this I really need to know what driver file was being used for
the Ntbootdd.sys. I am hoping you can right click on the Ntbootdd.sys
file and then select the version tab and then "Original File name" to
get the real name of the driver for me. Also the Description would be
helpful.

John Hensley
www.resqware.com

Len,

Thanks for posting the file information from Ntbootdd.sys. I found the
ataboot.sys file on the XP Sp2 setup CD and was able to mirror an
existing XP installation onto a 2nd drive, disable the 2nd drive in
the ROMBIOS and then boot Windows on the 2nd drive by adding this line
to the boot.ini on the 1st drive.

signature(9bc029be)disk(0)rdisk(0)partition(1)\WIN DOWS="Microsoft
Windows XP Professional Drive2 Sig()" /fastdetect

I had also copied ataboot.sys to the root directory on the 1st drive
and renamed it to Ntboodd.sys. The second drive is a slave on the
first IDE controller and I got the signature value from the 2nd
drive's MountedDevices key in the registry.

To make sure absolutely sure I was really booting with the
Ntbootdd.sys driver and not the ROMBIOS, I added this line to the
boot.ini and attempted to boot with the drive still disabled in the
ROMBIOS.

multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Micro soft Windows XP
Professional Drive2" /fastdetect

Selecting this line with the drive disabled in the ROMBIOS I saw this
message:

"Windows could not start because of a computer disk hardware
configuration problem. Could not read from the selected boot disk.
Check boot path and disk hardware."

When I enabled the drive in the ROMBIOS the error disappeared and it
booted fine from the second hard disk.

I concluded from these tests that signature() requires the disk
signature from the MountedDevices key, disk() and rdisk() should be be
0 and partition() should specify as the actual 1 based partition
number. I don't see how any of this is going to help you though
because you have already tried all of this.

I'm very grateful that you've posted all of the information because my
RescueBoot software product updates the boot.ini with a new line that
allows booting Windows from a protected directory on the system drive
and I wasn't aware that I needed to worry about anything other than
multi() and scsi() arc paths. I'll use what I've learned to update the
software so that it recognizes and supports the signature() arc paths.

BTW I had a great weekend thanks, the weather was picture perfect both
days and even found time to take my wife and son to watch Shrek. I
hope you had a good one too.

Best regards.
John Hensley
www.resqware.com

John,

Thanks again and you're welcome. BTW, Shrek is definitely in my top five.

To anyone that bothered to read this far,

I don't think moving the hal.dll file towards the beginning of the disk
really made any difference. I think a chkdisk /r at the same time might have
had the same results. I don't really know.

I wound up restoring the Ghost image file that I had made after the system
had been messed up. I then used the multi syntax line in the boot.ini that I
had been debugging with to boot to safe mode command prompt and ran system
restore from there. It turns out that there had been a java update on the
last day this machine was working. I can't say that the update was at fault
for anything, but it did provide a convenient restore point. Now all is as
well as it ever was, again.

Len

"John Hensley" wrote:

Len,

Thanks for posting the file information from Ntbootdd.sys. I found the
ataboot.sys file on the XP Sp2 setup CD and was able to mirror an
existing XP installation onto a 2nd drive, disable the 2nd drive in
the ROMBIOS and then boot Windows on the 2nd drive by adding this line
to the boot.ini on the 1st drive.

signature(9bc029be)disk(0)rdisk(0)partition(1)\WIN DOWS="Microsoft
Windows XP Professional Drive2 Sig()" /fastdetect

I had also copied ataboot.sys to the root directory on the 1st drive
and renamed it to Ntboodd.sys. The second drive is a slave on the
first IDE controller and I got the signature value from the 2nd
drive's MountedDevices key in the registry.

To make sure absolutely sure I was really booting with the
Ntbootdd.sys driver and not the ROMBIOS, I added this line to the
boot.ini and attempted to boot with the drive still disabled in the
ROMBIOS.

multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Micro soft Windows XP
Professional Drive2" /fastdetect

Selecting this line with the drive disabled in the ROMBIOS I saw this
message:

"Windows could not start because of a computer disk hardware
configuration problem. Could not read from the selected boot disk.
Check boot path and disk hardware."

When I enabled the drive in the ROMBIOS the error disappeared and it
booted fine from the second hard disk.

I concluded from these tests that signature() requires the disk
signature from the MountedDevices key, disk() and rdisk() should be be
0 and partition() should specify as the actual 1 based partition
number. I don't see how any of this is going to help you though
because you have already tried all of this.

I'm very grateful that you've posted all of the information because my
RescueBoot software product updates the boot.ini with a new line that
allows booting Windows from a protected directory on the system drive
and I wasn't aware that I needed to worry about anything other than
multi() and scsi() arc paths. I'll use what I've learned to update the
software so that it recognizes and supports the signature() arc paths.

BTW I had a great weekend thanks, the weather was picture perfect both
days and even found time to take my wife and son to watch Shrek. I
hope you had a good one too.

Best regards.
John Hensley
www.resqware.com