How to switch to a different HAL.DLL?

OSR_Community_User · November 23, 2006, 8:08am

In summary, I’m looking for a way to have one image, but support 2 HALs.

We have a disk image that we want to use on two different motherboards. Because the systems are controlled by us, the disk image would be exactly the same except for a different HAL.DLL. The one motherboard uses the standard HAL.DLL, and the other uses the ACPI one HALACPI.DLL.

I know all the docs say not to do this, but…

The reason for this is that this is an embedded product and we recently moved from one motherboard to another, so we don’t want to have to have the field upgrade to a different image (which would be exactly the same except for the HAL) as they need to RMA motherboards (they’d want to keep their disks since it has their information on it). We don’t want them to have to care about the “innerds” of the system. And of course we don’t want to have to put together another nearly-identical image from scratch, which opens up the possibility of making an error, having to QA two images, stocking two images, applying fixes to two images, and so on.

There are a variety of reasons why we don’t want to use sysprep and the ilk.

Booting on the ACPI system with the standard HAL.DLL actually works pretty well – until the system goes idle for a period, and then it crashes in a freaky way (crashes inside HalBeginSystemInterrupt).

We’ve also tried setting the BIOS to disable ACPI, but that crashes as well, so I suspect that Windows is ignoring the BIOS setting and re-enabling.

And of course we tried just replacing HAL.DLL with the right one (while the disk was off-line). (Surprisingly, the file wasn’t in the DLLCACHE.) But then it crashed with a 0x7B. That implies that there’s more to change than just the HAL.DLL. That begs the question of what else changes other than HAL.DLL?

What surprised me is that throughout all the testing, I never saw the HAL_MISMATCH bluescreen. If not for this, then what is the purpose of that stop code?

It seems to be there has to be a way that we can just swap HALs semi-easily.

Help?

(Thanks.)

OSR_Community_User · November 24, 2006, 6:37pm

This may be obvious, but have you tried the /KERNEL and /HAL options in BOOT.INI, rather than replacing the disk file? You can find a list of all of the BOOT.INI options at:

http://www.microsoft.com/technet/sysinternals/information/bootini.mspx

You could try doing a clean OS install on both systems, and then recording exactly which kernel and HAL are being loaded, and then use /KERNEL and /HAL in BOOT.INI to override those values when you switch system boards.

– arlie

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of Taed Wynnell [xxxxx@vertical.com]
Sent: Thursday, November 23, 2006 5:07 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] How to switch to a different HAL.DLL?

In summary, I’m looking for a way to have one image, but support 2 HALs.

We have a disk image that we want to use on two different motherboards. Because the systems are controlled by us, the disk image would be exactly the same except for a different HAL.DLL. The one motherboard uses the standard HAL.DLL, and the other uses the ACPI one HALACPI.DLL.

I know all the docs say not to do this, but…

The reason for this is that this is an embedded product and we recently moved from one motherboard to another, so we don’t want to have to have the field upgrade to a different image (which would be exactly the same except for the HAL) as they need to RMA motherboards (they’d want to keep their disks since it has their information on it). We don’t want them to have to care about the “innerds” of the system. And of course we don’t want to have to put together another nearly-identical image from scratch, which opens up the possibility of making an error, having to QA two images, stocking two images, applying fixes to two images, and so on.

There are a variety of reasons why we don’t want to use sysprep and the ilk.

Booting on the ACPI system with the standard HAL.DLL actually works pretty well – until the system goes idle for a period, and then it crashes in a freaky way (crashes inside HalBeginSystemInterrupt).

We’ve also tried setting the BIOS to disable ACPI, but that crashes as well, so I suspect that Windows is ignoring the BIOS setting and re-enabling.

And of course we tried just replacing HAL.DLL with the right one (while the disk was off-line). (Surprisingly, the file wasn’t in the DLLCACHE.) But then it crashed with a 0x7B. That implies that there’s more to change than just the HAL.DLL. That begs the question of what else changes other than HAL.DLL?

What surprised me is that throughout all the testing, I never saw the HAL_MISMATCH bluescreen. If not for this, then what is the purpose of that stop code?

It seems to be there has to be a way that we can just swap HALs semi-easily.

Help?

(Thanks.)

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · November 25, 2006, 7:16am

Where I used to work we have taken that step even a little further by appending new choices for all possible combinations of HAL/NTOSKRNL and got a fairly generic image from that. However, there is another issue here:
you need to ensure that the generic drivers for the IDE controllers are all installed. When changing the HDD controller (which is usually on-board) Windows gets picky sometimes (unless, of course, the controller happens to be the same).

Oliver

-------- Original-Nachricht --------
Datum: Fri, 24 Nov 2006 15:33:32 -0800
Von: Arlie Davis
An: “Windows System Software Devs Interest List”
Betreff: RE:[ntdev] How to switch to a different HAL.DLL?

> This may be obvious, but have you tried the /KERNEL and /HAL options in
> BOOT.INI, rather than replacing the disk file? You can find a list of all of
> the BOOT.INI options at:
>
> http://www.microsoft.com/technet/sysinternals/information/bootini.mspx
>
> You could try doing a clean OS install on both systems, and then recording
> exactly which kernel and HAL are being loaded, and then use /KERNEL and
> /HAL in BOOT.INI to override those values when you switch system boards.
>
> – arlie
>
>
> --------------------
> From: xxxxx@lists.osr.com
> [xxxxx@lists.osr.com] On Behalf Of Taed Wynnell [xxxxx@vertical.com]
> Sent: Thursday, November 23, 2006 5:07 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] How to switch to a different HAL.DLL?
>
>
> In summary, I’m looking for a way to have one image, but support 2 HALs.
>
> We have a disk image that we want to use on two different motherboards.
> Because the systems are controlled by us, the disk image would be exactly
> the same except for a different HAL.DLL. The one motherboard uses the
> standard HAL.DLL, and the other uses the ACPI one HALACPI.DLL.
>
> I know all the docs say not to do this, but…
>
> The reason for this is that this is an embedded product and we recently
> moved from one motherboard to another, so we don’t want to have to have the
> field upgrade to a different image (which would be exactly the same except
> for the HAL) as they need to RMA motherboards (they’d want to keep their
> disks since it has their information on it). We don’t want them to have to
> care about the “innerds” of the system. And of course we don’t want to have
> to put together another nearly-identical image from scratch, which opens up
> the possibility of making an error, having to QA two images, stocking two
> images, applying fixes to two images, and so on.
>
> There are a variety of reasons why we don’t want to use sysprep and the
> ilk.
>
> Booting on the ACPI system with the standard HAL.DLL actually works pretty
> well – until the system goes idle for a period, and then it crashes in a
> freaky way (crashes inside HalBeginSystemInterrupt).
>
> We’ve also tried setting the BIOS to disable ACPI, but that crashes as
> well, so I suspect that Windows is ignoring the BIOS setting and re-enabling.
>
> And of course we tried just replacing HAL.DLL with the right one (while
> the disk was off-line). (Surprisingly, the file wasn’t in the DLLCACHE.)
> But then it crashed with a 0x7B. That implies that there’s more to change
> than just the HAL.DLL. That begs the question of what else changes other
> than HAL.DLL?
>
> What surprised me is that throughout all the testing, I never saw the
> HAL_MISMATCH bluescreen. If not for this, then what is the purpose of that
> stop code?
>
> It seems to be there has to be a way that we can just swap HALs
> semi-easily.
>
> Help?
>
> (Thanks.)
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer

–
---------------------------------------------------
May the source be with you, stranger

ICQ: #281645
URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info

OSR_Community_User · November 26, 2006, 10:35pm

“Arlie Davis” wrote in message news:xxxxx@ntdev…
> This may be obvious, but have you tried the /KERNEL and /HAL options in
BOOT.INI, rather than replacing the disk file?

It wasn’t too obvious (I didn’t think of it until recently), but yes, I
have. I get the same almost-immediate STOP 0x0000007B as I did when I
replaced the HAL.DLL. Thanks for the point, though!

I might have to install on both motherboards and then look for Registry
differences…

OSR_Community_User · November 26, 2006, 10:42pm

“Oliver Schneider” wrote in message
news:xxxxx@ntdev…
> Where I used to work we have taken that step even a little further by
appending new choices for all
> possible combinations of HAL/NTOSKRNL and got a fairly generic image from
that.

Do you recall how you did that? Are you referring to the BOOT.INI options?
I tried that, but it didn’t work; I got an immediate STOP 0x0000007B
INACCESSIBLE_BOOT_DEVICE when I force-loaded the correct HALACPI.DLL on an
image built on a standard HAL.DLL. (Surprisingly not a 0x00000079
MISMATCHED_HAL.)

> However, there is another issue here:
> you need to ensure that the generic drivers for the IDE controllers are
all installed.
> When changing the HDD controller (which is usually on-board) Windows gets
picky
> sometimes (unless, of course, the controller happens to be the same).

That I solved a few years ago when we had another motherboard (we’re on our
6th or so now, but the first with ACPI). There’s actually a KB article
describing how to fix that:
http://support.microsoft.com/kb/314082/en-us

OSR_Community_User · November 27, 2006, 3:56pm

Did you replace the kernel as well? The HAL and KERNEL must be paired.

mm

>> xxxxx@vertical.com 2006-11-26 22:35 >>>
“Arlie Davis” wrote in message
news:xxxxx@ntdev…
> This may be obvious, but have you tried the /KERNEL and /HAL options
in
BOOT.INI, rather than replacing the disk file?

It wasn’t too obvious (I didn’t think of it until recently), but yes,
I
have. I get the same almost-immediate STOP 0x0000007B as I did when I
replaced the HAL.DLL. Thanks for the point, though!

I might have to install on both motherboards and then look for
Registry
differences…

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · November 27, 2006, 5:18pm

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> Did you replace the kernel as well? The HAL and KERNEL must be paired.

Maybe I’m wrong, but I don’t think that I have to do that since both
machines are uniprocessor. I’m also not using PAE. So, the standard
ntoskrnl.exe should be fine.

Jake_Oshins · November 28, 2006, 1:24pm

I’ve been paying limited attention to this thread, so forgive me if I’ve
missed some details.

It sounds to me like your BIOS is busted. What you’re doing should work.
(I know because I’m the original author of halacpi.dll.) I’d expect a bunch
of “new hardward found” popups the first time you switched HALs. But a full
bugcheck 0x7B indicates that the boot device driver failed to load or
initialize. This would be the case if the interrupt routing or other
resource constraints weren’t described correctly by the BIOS, making it
impossible for the boot drivers to work. What is the boot device? IDE?
Something else? (IDE is more tolerant of BIOS errors, as it doesn’t use a
PCI interrupt.)

Does the system work if you clean-install with the HAL that you’re trying to
use? (Push F7 just as setup begins and you’ll switch off ACPI. Push F5 and
you’ll get a chance to install the HAL of your choice, with all the
possibility for creating a non-functioning machine.)

Jake Oshins
Windows Kernel Team

“Taed Wynnell” wrote in message news:xxxxx@ntdev…
> “Martin O’Brien” wrote in message
> news:xxxxx@ntdev…
>> Did you replace the kernel as well? The HAL and KERNEL must be paired.
>
> Maybe I’m wrong, but I don’t think that I have to do that since both
> machines are uniprocessor. I’m also not using PAE. So, the standard
> ntoskrnl.exe should be fine.
>
>
>

OSR_Community_User · November 29, 2006, 2:48pm

I’m beginning to suspect something’s broken with the BIOS as well, though I
just got a new version of the Phoenix BIOS from the motherboard manufacturer
(it was just released), and it behaves the same.

– If I do a clean install of Windows 2003 with ACPI enabled in the BIOS, it
installs as an ACPI-compatible machine with HALACPI.dll, and it will stay up
seemingly forever.

– If I disable ACPI in the BIOS, and then do a clean install of Windows
2003, it does install as a Standard PC, namely a non-ACPI HAL.dll. That’s
good so far. However, within hours, it will crash in
Hal!HalBeginSystemInterrupt with what looks like stack corruption.

The crash I see in that case is the same crash that I see if I take an image
created on a true non-ACPI motherboard and then boot it on my ACPI system.
Namely, after a few hours (when the system is idle), it will crash in
Hal!HalBeginSystemInterrupt with what looks like stack corruption. The
bottom addresses are slightly different every time, and often point to
illegal opcodes, hence my belief that it is due to stack corruption of some
sort.

STACK_TEXT:
8089d500 80a73788 badb0d00 80010031 f73108a3 nt!KiTrap0E+0x2a1
8089d574 8081f14b 0001000d 0000003e 8089d588
hal!HalBeginSystemInterrupt+0x10
8089d574 80a7338a 0001000d 0000003e 8089d588 nt!KiInterruptDispatch+0x1b
8089d600 80820a45 00000000 0000000e 00000000 hal!HalProcessorIdle+0x2
8089d604 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0xa

“Jake Oshins” wrote in message
news:xxxxx@ntdev…
> I’ve been paying limited attention to this thread, so forgive me if I’ve
> missed some details.
>
> It sounds to me like your BIOS is busted. What you’re doing should work.
> (I know because I’m the original author of halacpi.dll.) I’d expect a
bunch
> of “new hardward found” popups the first time you switched HALs. But a
full
> bugcheck 0x7B indicates that the boot device driver failed to load or
> initialize. This would be the case if the interrupt routing or other
> resource constraints weren’t described correctly by the BIOS, making it
> impossible for the boot drivers to work. What is the boot device? IDE?
> Something else? (IDE is more tolerant of BIOS errors, as it doesn’t use a
> PCI interrupt.)
>
> Does the system work if you clean-install with the HAL that you’re trying
to
> use? (Push F7 just as setup begins and you’ll switch off ACPI. Push F5
and
> you’ll get a chance to install the HAL of your choice, with all the
> possibility for creating a non-functioning machine.)
>
> - Jake Oshins
> Windows Kernel Team
>
>
> “Taed Wynnell” wrote in message news:xxxxx@ntdev…
> > “Martin O’Brien” wrote in message
> > news:xxxxx@ntdev…
> >> Did you replace the kernel as well? The HAL and KERNEL must be paired.
> >
> > Maybe I’m wrong, but I don’t think that I have to do that since both
> > machines are uniprocessor. I’m also not using PAE. So, the standard
> > ntoskrnl.exe should be fine.
> >
> >
> >
>
>
>

Cody_Wu · November 30, 2006, 9:45pm

Hi Taed,

The traces show the corruption process Thanks to “Inside Windows
2000”)

nt!KiIdleLoop+0xa :
This is a constantly running system thread that performs idle
processing.
hal!HalProcessorIdle+0x2
This function will always be called to do some processing based on
current processor power state in PRCB (Processor Control Block). Since
this is Hal function, my best guess is on ACPI system it will parse ACPI
CPU PM code provide by Bios. But on Non-ACPI system it may do some
native processing provided by windows. At least, APM should not be
involved as it is rather outdated. (I hope)
nt!KiInterruptDispatch+0x1b
The windows has generated a soft interrupt to handle the processor
power management.
hal!HalBeginSystemInterrupt+0x10
This function seems to be called at the beginning of each interrupt
handler including software interrupt.
nt!KiTrap0E+0x2a1
The page fault has happened during HalBeginSystemInterrupt. And
PageFault handler cannot handle it gracefully.

I think you might want to use WinDbg to disassemble the code at the
corrupting points to see what is going on there.

Also, can you provide me with your motherboard model and chipset models?
I may be able to provide some of my analysis. Hope this helps!

Best regards,
Cody

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Taed Wynnell
Sent: Thursday, November 30, 2006 3:48 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:How to switch to a different HAL.DLL?

I’m beginning to suspect something’s broken with the BIOS as well,
though I
just got a new version of the Phoenix BIOS from the motherboard
manufacturer
(it was just released), and it behaves the same.

– If I do a clean install of Windows 2003 with ACPI enabled in the
BIOS, it
installs as an ACPI-compatible machine with HALACPI.dll, and it will
stay up
seemingly forever.

– If I disable ACPI in the BIOS, and then do a clean install of Windows
2003, it does install as a Standard PC, namely a non-ACPI HAL.dll.
That’s
good so far. However, within hours, it will crash in
Hal!HalBeginSystemInterrupt with what looks like stack corruption.

The crash I see in that case is the same crash that I see if I take an
image
created on a true non-ACPI motherboard and then boot it on my ACPI
system.
Namely, after a few hours (when the system is idle), it will crash in
Hal!HalBeginSystemInterrupt with what looks like stack corruption. The
bottom addresses are slightly different every time, and often point to
illegal opcodes, hence my belief that it is due to stack corruption of
some
sort.

STACK_TEXT:
8089d500 80a73788 badb0d00 80010031 f73108a3 nt!KiTrap0E+0x2a1
8089d574 8081f14b 0001000d 0000003e 8089d588
hal!HalBeginSystemInterrupt+0x10
8089d574 80a7338a 0001000d 0000003e 8089d588 nt!KiInterruptDispatch+0x1b
8089d600 80820a45 00000000 0000000e 00000000 hal!HalProcessorIdle+0x2
8089d604 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0xa

“Jake Oshins” wrote in message
news:xxxxx@ntdev…
> I’ve been paying limited attention to this thread, so forgive me if
I’ve
> missed some details.
>
> It sounds to me like your BIOS is busted. What you’re doing should
work.
> (I know because I’m the original author of halacpi.dll.) I’d expect a
bunch
> of “new hardward found” popups the first time you switched HALs. But
a
full
> bugcheck 0x7B indicates that the boot device driver failed to load or
> initialize. This would be the case if the interrupt routing or other
> resource constraints weren’t described correctly by the BIOS, making
it
> impossible for the boot drivers to work. What is the boot device?
IDE?
> Something else? (IDE is more tolerant of BIOS errors, as it doesn’t
use a
> PCI interrupt.)
>
> Does the system work if you clean-install with the HAL that you’re
trying
to
> use? (Push F7 just as setup begins and you’ll switch off ACPI. Push
F5
and
> you’ll get a chance to install the HAL of your choice, with all the
> possibility for creating a non-functioning machine.)
>
> - Jake Oshins
> Windows Kernel Team
>
>
> “Taed Wynnell” wrote in message
news:xxxxx@ntdev…
> > “Martin O’Brien” wrote in message
> > news:xxxxx@ntdev…
> >> Did you replace the kernel as well? The HAL and KERNEL must be
paired.
> >
> > Maybe I’m wrong, but I don’t think that I have to do that since both
> > machines are uniprocessor. I’m also not using PAE. So, the
standard
> > ntoskrnl.exe should be fine.
> >
> >
> >
>
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

OSR_Community_User · November 30, 2006, 10:59pm

Thank you for your insight!

I tried debugging the memory.dmp file, but didn’t get anywhere. The
Microsoft folks also took a look and didn’t get anywhere. Also, I can’t
catch it in the act since the crash only happens maybe once a day.

By the way, how did Inside Windows help? I have that book, and don’t see
what info you got from there; could you share sections so I could read up?

But your theory makes sense since I know that the root problem is that I’m
running the Standard PC HAL.DLL on an ACPI motherboard that should be
running HALACPI.DLL (which is what is installed when I install fresh).
That’s why I just want to change the HAL since I had moved the image from
another machine.

But I’m running a Kontron ETX-PM (an embedded motherboard,
http://us.kontron.com/index.php?id=226&cat=461&productid=4) with an Intel
Celeron M 370 (1.5 GHz), with i855GM/GME, and an 82801DB Southbridge.

By the way, I’m now also going down the path of using Acronis Tue Image with
Universal Restore, which is supposed to resolve the HAL (and mass storage)
issues with moving Windows images, but it didn’t work on the first attempt,
so Support is helping me out.

Rumor has it that Vista has something called CompletePC Backup that is
supposed to avoid / fix this sort of image-moving issue… But that doesn’t
help me; oh well…

“Wu, Cody” wrote in message news:xxxxx@ntdev…
Hi Taed,

The traces show the corruption process Thanks to “Inside Windows
2000”)

nt!KiIdleLoop+0xa :
This is a constantly running system thread that performs idle
processing.
hal!HalProcessorIdle+0x2
This function will always be called to do some processing based on
current processor power state in PRCB (Processor Control Block). Since
this is Hal function, my best guess is on ACPI system it will parse ACPI
CPU PM code provide by Bios. But on Non-ACPI system it may do some
native processing provided by windows. At least, APM should not be
involved as it is rather outdated. (I hope)
nt!KiInterruptDispatch+0x1b
The windows has generated a soft interrupt to handle the processor
power management.
hal!HalBeginSystemInterrupt+0x10
This function seems to be called at the beginning of each interrupt
handler including software interrupt.
nt!KiTrap0E+0x2a1
The page fault has happened during HalBeginSystemInterrupt. And
PageFault handler cannot handle it gracefully.

I think you might want to use WinDbg to disassemble the code at the
corrupting points to see what is going on there.

Also, can you provide me with your motherboard model and chipset models?
I may be able to provide some of my analysis. Hope this helps!

Best regards,
Cody

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Taed Wynnell
Sent: Thursday, November 30, 2006 3:48 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:How to switch to a different HAL.DLL?

I’m beginning to suspect something’s broken with the BIOS as well,
though I
just got a new version of the Phoenix BIOS from the motherboard
manufacturer
(it was just released), and it behaves the same.

– If I do a clean install of Windows 2003 with ACPI enabled in the
BIOS, it
installs as an ACPI-compatible machine with HALACPI.dll, and it will
stay up
seemingly forever.

– If I disable ACPI in the BIOS, and then do a clean install of Windows
2003, it does install as a Standard PC, namely a non-ACPI HAL.dll.
That’s
good so far. However, within hours, it will crash in
Hal!HalBeginSystemInterrupt with what looks like stack corruption.

The crash I see in that case is the same crash that I see if I take an
image
created on a true non-ACPI motherboard and then boot it on my ACPI
system.
Namely, after a few hours (when the system is idle), it will crash in
Hal!HalBeginSystemInterrupt with what looks like stack corruption. The
bottom addresses are slightly different every time, and often point to
illegal opcodes, hence my belief that it is due to stack corruption of
some
sort.

STACK_TEXT:
8089d500 80a73788 badb0d00 80010031 f73108a3 nt!KiTrap0E+0x2a1
8089d574 8081f14b 0001000d 0000003e 8089d588
hal!HalBeginSystemInterrupt+0x10
8089d574 80a7338a 0001000d 0000003e 8089d588 nt!KiInterruptDispatch+0x1b
8089d600 80820a45 00000000 0000000e 00000000 hal!HalProcessorIdle+0x2
8089d604 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0xa

“Jake Oshins” wrote in message
news:xxxxx@ntdev…
> I’ve been paying limited attention to this thread, so forgive me if
I’ve
> missed some details.
>
> It sounds to me like your BIOS is busted. What you’re doing should
work.
> (I know because I’m the original author of halacpi.dll.) I’d expect a
bunch
> of “new hardward found” popups the first time you switched HALs. But
a
full
> bugcheck 0x7B indicates that the boot device driver failed to load or
> initialize. This would be the case if the interrupt routing or other
> resource constraints weren’t described correctly by the BIOS, making
it
> impossible for the boot drivers to work. What is the boot device?
IDE?
> Something else? (IDE is more tolerant of BIOS errors, as it doesn’t
use a
> PCI interrupt.)
>
> Does the system work if you clean-install with the HAL that you’re
trying
to
> use? (Push F7 just as setup begins and you’ll switch off ACPI. Push
F5
and
> you’ll get a chance to install the HAL of your choice, with all the
> possibility for creating a non-functioning machine.)
>
> - Jake Oshins
> Windows Kernel Team
>
>
> “Taed Wynnell” wrote in message
news:xxxxx@ntdev…
> > “Martin O’Brien” wrote in message
> > news:xxxxx@ntdev…
> >> Did you replace the kernel as well? The HAL and KERNEL must be
paired.
> >
> > Maybe I’m wrong, but I don’t think that I have to do that since both
> > machines are uniprocessor. I’m also not using PAE. So, the
standard
> > ntoskrnl.exe should be fine.
> >
> >
> >
>
>
>

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer