From: John Wunderlich on
=?Utf-8?B?bW1i?= <mmb(a)discussions.microsoft.com> wrote in
news:1D20FB9B-8C4C-4F8A-88A8-45408D1D0CDA(a)microsoft.com:

> I removed the repair disk and rebooted and then got the same *&@#
> message about a corrupted hal.dll. Any further thoughts from
> anyone?
>
>

Grabbing at straws...
You say you followed the instructions in KB31477.

Did you try the suggestions in KB330184?
""Invalid Boot.ini" or "Windows could not start" error messages when
you start your computer"
<http://support.microsoft.com/kb/330184>

HTH,
John
From: Paul on
mmb wrote:
> Thanks John. I used the repair console CD and used the fixmbr command,
> ignoring the warning. I then got the message"writing new master boot record
> on physical drive\device\harddisk0\partition0" and then very quickly "The new
> master boot record has been successfully written."
>
> I removed the repair disk and rebooted and then got the same *&@# message
> about a corrupted hal.dll. Any further thoughts from anyone?
>
> Apparently all this started with a power outage while my computer was on.
> The first thing I'm gonna do when (if) I get this problem solved is to buy a
> battery backup. The laptop has the advantage of having a built-in battery
> backup but I really prefer working on a desktop. I really, really hope I
> don't have to reinstall Windows. It's SUCH a hassle to reinstall all the
> programs.
>
> Thanks for any further advice.

Well, if you look at some web pages with comments from people,
some are trying to "download hal.dll". If I use "search" on my
computer, and search by file size, I can see

hal.dll C:\WINDOWS\system32 "Internal Name" in properties = halmacpi.dll
halapic.dll C:\WINDOWS\driver cache\i386\sp3.cab
halmacpi.dll C:\WINDOWS\driver cache\i386\sp3.cab
halmps.dll C:\WINDOWS\driver cache\i386\sp3.cab

If I click on the hal.dll file, "Internal Name" in the file
properties says the file is halmacpi.dll . In other words,
the OS renames the appropriate file choice to hal.dll and
copies it into C:\WINDOWS\system32 . And that is why,
attempting to download hal.dll is doomed to fail. It
must correspond to the type of hardware abstraction
layer the computer is using at the moment (which you'd see
in Device Manager, by examining the "Computer" entry).

I have a dual core computer (a multiprocessor) and I
have ACPI for power management. Therefore, halmacpi.dll
is the right HAL to be using, for the current state
of my install.

One article suggested checking boot.ini . The Recovery
Console has an option to rebuild the boot.ini . If the ARC
path was wrong (pointing to the wrong partition), apparently
that may give the error. So it's not the file that is missing,
it is the boot process looking on the wrong partition.
(How would that get changed on a power failure ???)

My problem right now is, I can't find any reference that
says exactly when "hal.dll" is loaded. Is it the first file ?
That seems unlikely some how. What are the odds ?

(This article would suggest NTLDR is loaded before that...
This article also explains the boot.ini entries a bit.)

http://en.wikipedia.org/wiki/NTLDR

http://en.wikipedia.org/wiki/Windows_NT_startup_process

If I was working on this problem, I'd be booting my Linux
(Ubuntu or Knoppix) CD, for a look. I'd open boot.ini in a
text editor, and have a look at it. Use "fdisk /dev/sda" type
command, to print the partition table. Open the partitions one
at a time, and verify which partition number is the right one.
And check to see if there actually is a HAL file in
C:\WINDOWS\system32 . There are other bootable, Windows-centric
CDs that can allow you to do that as well. Recovery Console
is fun, and may be enough to get the job done, but I like
a "second opinion".

*******

When I was experimenting the other day, with some P2V software
(for transferring a real disk, for usage inside VirtualPC 2007),
I happened to look inside the boot.ini on the resulting virtual
machine. This is the entry that was in there.

multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Disk2vhd Microsoft
Windows XP Professional" /noexecute=optin /fastdetect
/KERNEL=ntkrpuni.exe /HAL=halacpi.dll

The KERNEL and HAL options, don't exist in a normal boot.ini .
The P2V program added them, to compensate for the fact that
VirtualPC 2007 is a uniprocessor environment (one computing core),
while my real computer is a dual core. Forcing the correct
KERNEL and HAL files, allowed the OS to boot inside VirtualPC 2007.
(That means, I'm running the same copy of Windows twice.) I did this
test, purely to see the Windows Activation message that results.

The experiment is interesting, because it shows if you needed to, you
could point to a particular HAL. That HAL file isn't on the C: file
ready to go - to get a copy, I could get it out of the SP3.cab file.
I think the P2V software, must have done the extraction to do that,
because otherwise it might not be there.

This doesn't really help you, except to point out how powerful and
critical the boot.ini is to get corrected. For example, if I was
to change the ARC to multi(0)disk(0)rdisk(0)partition(3) instead
of partition(2), the boot process would fall on its face. I happen
to know, my WinXP is the second partition on the disk, so I can
tell by looking at it, that the ARC is reasonable for the task.

"Description of the BOOTCFG Command and Its Uses"

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

Reading that description, you can see some of the silly questions
it is going to ask you, while you're in the Recovery Console.
You'd be prepared to answer those questions, if you already had
a copy of the boot.ini. Personally, I find it easier, to just
boot a Ubuntu CD, open boot.ini on that partition, and edit the
arguments that need changing. For example, if I could see

multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional"
/noexecute=optin /fastdetect

then I'd know what to type in when bootcfg prompts. The only
advantage I see, from using the command, is it is going to
figure out the ARC for you ( "multi(0)disk(0)rdisk(0)partition(2)" ).

Paul

>
> "John Wunderlich" wrote:
>
>> =?Utf-8?B?bW1i?= <mmb(a)discussions.microsoft.com> wrote in
>> news:C02C3B7C-B613-4357-AFE4-0B9F22563F9C(a)microsoft.com:
>>
>>> Okay, so I panicked for nothing, huh? I have one more question
>>> before proceeding with fixmbr. The referenced article indicates
>>> that it applies to Microsoft 2000. I have XP, sp3. Is it safe to
>>> proceed with fixmbr? Thank you so much.
>>>
>> If you're worried about that, check out the KB article:
>>
>> "Computer stops responding with a black screen when you start Windows XP"
>> <http://support.microsoft.com/kb/314503>
>>
>> .... which applies specifically to Windows XP.
>> Method 1, Step 3, tells you to use the FIXMBR command and refers
>> you back to the KB266745 article if you are concerned with the error message.
>> Therefore, I conclude that KB266745 applies equally well to Windows XP.
>> It's just that nobody has updated that article in a while.
>>
>> -- John
>> .
>>
From: mmb on
Paul, thanks for your reply and especially for the obvious thought and time
you've given to my problem. I'll look at all your references and suggestions
a little later today when I have more time, but in the meantime I'll tell you
something else that occurred when I was putzing around, which may or may not
be relevant.

Yesterday I searched for Hal.dll and verified that it was, in fact, in the
System 32 subdirectory. There was another in the cab file, among other
locations, which I extracted and copied into the System32 subdirectory,
overwriting the one that was there. When I attempted to boot I again got the
missing or corrupted Hal.dll message. Then I rebooted and used the F8 method
to select the hard drive that had previously worked. This tme it bounced me
to the safe mode but when I chose boot from last good configuration, it
wouldn't load (I can't remember what it did next other than the fact that it
wouldn't load) but the next I chose the option to boot in safe mode and again
it wouldn't load. Obviously the hal.dll I put in Syhstem 32 caused this
result. Again I used the recovery console to access my c:\ in which I had,
fortunately, saved a copy of the hal.dll before overwriting it. When I wrote
it back into System32 I again was able to boot using the F8 key to choose
hard drive that previously worked.

Thanks again, and I'll report later..

"Paul" wrote:

> mmb wrote:
> > Thanks John. I used the repair console CD and used the fixmbr command,
> > ignoring the warning. I then got the message"writing new master boot record
> > on physical drive\device\harddisk0\partition0" and then very quickly "The new
> > master boot record has been successfully written."
> >
> > I removed the repair disk and rebooted and then got the same *&@# message
> > about a corrupted hal.dll. Any further thoughts from anyone?
> >
> > Apparently all this started with a power outage while my computer was on.
> > The first thing I'm gonna do when (if) I get this problem solved is to buy a
> > battery backup. The laptop has the advantage of having a built-in battery
> > backup but I really prefer working on a desktop. I really, really hope I
> > don't have to reinstall Windows. It's SUCH a hassle to reinstall all the
> > programs.
> >
> > Thanks for any further advice.
>
> Well, if you look at some web pages with comments from people,
> some are trying to "download hal.dll". If I use "search" on my
> computer, and search by file size, I can see
>
> hal.dll C:\WINDOWS\system32 "Internal Name" in properties = halmacpi.dll
> halapic.dll C:\WINDOWS\driver cache\i386\sp3.cab
> halmacpi.dll C:\WINDOWS\driver cache\i386\sp3.cab
> halmps.dll C:\WINDOWS\driver cache\i386\sp3.cab
>
> If I click on the hal.dll file, "Internal Name" in the file
> properties says the file is halmacpi.dll . In other words,
> the OS renames the appropriate file choice to hal.dll and
> copies it into C:\WINDOWS\system32 . And that is why,
> attempting to download hal.dll is doomed to fail. It
> must correspond to the type of hardware abstraction
> layer the computer is using at the moment (which you'd see
> in Device Manager, by examining the "Computer" entry).
>
> I have a dual core computer (a multiprocessor) and I
> have ACPI for power management. Therefore, halmacpi.dll
> is the right HAL to be using, for the current state
> of my install.
>
> One article suggested checking boot.ini . The Recovery
> Console has an option to rebuild the boot.ini . If the ARC
> path was wrong (pointing to the wrong partition), apparently
> that may give the error. So it's not the file that is missing,
> it is the boot process looking on the wrong partition.
> (How would that get changed on a power failure ???)
>
> My problem right now is, I can't find any reference that
> says exactly when "hal.dll" is loaded. Is it the first file ?
> That seems unlikely some how. What are the odds ?
>
> (This article would suggest NTLDR is loaded before that...
> This article also explains the boot.ini entries a bit.)
>
> http://en.wikipedia.org/wiki/NTLDR
>
> http://en.wikipedia.org/wiki/Windows_NT_startup_process
>
> If I was working on this problem, I'd be booting my Linux
> (Ubuntu or Knoppix) CD, for a look. I'd open boot.ini in a
> text editor, and have a look at it. Use "fdisk /dev/sda" type
> command, to print the partition table. Open the partitions one
> at a time, and verify which partition number is the right one.
> And check to see if there actually is a HAL file in
> C:\WINDOWS\system32 . There are other bootable, Windows-centric
> CDs that can allow you to do that as well. Recovery Console
> is fun, and may be enough to get the job done, but I like
> a "second opinion".
>
> *******
>
> When I was experimenting the other day, with some P2V software
> (for transferring a real disk, for usage inside VirtualPC 2007),
> I happened to look inside the boot.ini on the resulting virtual
> machine. This is the entry that was in there.
>
> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Disk2vhd Microsoft
> Windows XP Professional" /noexecute=optin /fastdetect
> /KERNEL=ntkrpuni.exe /HAL=halacpi.dll
>
> The KERNEL and HAL options, don't exist in a normal boot.ini .
> The P2V program added them, to compensate for the fact that
> VirtualPC 2007 is a uniprocessor environment (one computing core),
> while my real computer is a dual core. Forcing the correct
> KERNEL and HAL files, allowed the OS to boot inside VirtualPC 2007.
> (That means, I'm running the same copy of Windows twice.) I did this
> test, purely to see the Windows Activation message that results.
>
> The experiment is interesting, because it shows if you needed to, you
> could point to a particular HAL. That HAL file isn't on the C: file
> ready to go - to get a copy, I could get it out of the SP3.cab file.
> I think the P2V software, must have done the extraction to do that,
> because otherwise it might not be there.
>
> This doesn't really help you, except to point out how powerful and
> critical the boot.ini is to get corrected. For example, if I was
> to change the ARC to multi(0)disk(0)rdisk(0)partition(3) instead
> of partition(2), the boot process would fall on its face. I happen
> to know, my WinXP is the second partition on the disk, so I can
> tell by looking at it, that the ARC is reasonable for the task.
>
> "Description of the BOOTCFG Command and Its Uses"
>
> http://support.microsoft.com/kb/317521
>
> Reading that description, you can see some of the silly questions
> it is going to ask you, while you're in the Recovery Console.
> You'd be prepared to answer those questions, if you already had
> a copy of the boot.ini. Personally, I find it easier, to just
> boot a Ubuntu CD, open boot.ini on that partition, and edit the
> arguments that need changing. For example, if I could see
>
> multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional"
> /noexecute=optin /fastdetect
>
> then I'd know what to type in when bootcfg prompts. The only
> advantage I see, from using the command, is it is going to
> figure out the ARC for you ( "multi(0)disk(0)rdisk(0)partition(2)" ).
>
> Paul
>
> >
> > "John Wunderlich" wrote:
> >
> >> =?Utf-8?B?bW1i?= <mmb(a)discussions.microsoft.com> wrote in
> >> news:C02C3B7C-B613-4357-AFE4-0B9F22563F9C(a)microsoft.com:
> >>
> >>> Okay, so I panicked for nothing, huh? I have one more question
> >>> before proceeding with fixmbr. The referenced article indicates
> >>> that it applies to Microsoft 2000. I have XP, sp3. Is it safe to
> >>> proceed with fixmbr? Thank you so much.
> >>>
> >> If you're worried about that, check out the KB article:
> >>
> >> "Computer stops responding with a black screen when you start Windows XP"
> >> <http://support.microsoft.com/kb/314503>
> >>
> >> .... which applies specifically to Windows XP.
> >> Method 1, Step 3, tells you to use the FIXMBR command and refers
> >> you back to the KB266745 article if you are concerned with the error message.
> >> Therefore, I conclude that KB266745 applies equally well to Windows XP.
> >> It's just that nobody has updated that article in a while.
> >>
> >> -- John
> >> .
> >>
> .
>
From: Jose on
On Aug 8, 2:08 pm, mmb <m...(a)discussions.microsoft.com> wrote:
> Paul, thanks for your reply and especially for the obvious thought and time
> you've given to my problem.  I'll look at all your references and suggestions
> a little later today when I have more time, but in the meantime I'll tell you
> something else that occurred when I was putzing around, which may or may not
> be relevant.
>
> Yesterday I searched for Hal.dll and verified that it was, in fact, in the
> System 32 subdirectory.  There was another in the cab file, among other
> locations, which I extracted and copied into the System32 subdirectory,
> overwriting the one that was there.  When I attempted to boot I again got the
> missing or corrupted Hal.dll message.  Then I rebooted and used the F8 method
> to select the hard drive that had previously worked.  This tme it bounced me
> to the safe mode but when I chose boot from last good configuration, it
> wouldn't load (I can't remember what it did next other than the fact that it
> wouldn't load) but the next I chose the option to boot in safe mode and again
> it wouldn't load.  Obviously the hal.dll I put in Syhstem 32 caused this
> result.  Again I used the recovery console to access my c:\ in which I had,
> fortunately, saved a copy of the hal.dll before overwriting it.  When I wrote
> it back into System32 I again was able to boot using the F8 key to choose
> hard drive that previously worked.  
>
> Thanks again, and I'll report later..
>
> "Paul" wrote:
> > mmb wrote:
> > > Thanks John.  I used the repair console CD and used the fixmbr command,
> > > ignoring the warning.  I then got the message"writing new master boot record
> > > on physical drive\device\harddisk0\partition0" and then very quickly "The new
> > > master boot record has been successfully written."
>
> > > I removed the repair disk and rebooted and then got the same *&@# message
> > > about a corrupted hal.dll.  Any further thoughts from anyone?
>
> > > Apparently all this started with a power outage while my computer was on.  
> > > The first thing I'm gonna do when (if) I get this problem solved is to buy a
> > > battery backup.  The laptop has the advantage of having a built-in battery
> > > backup but I really prefer working on a desktop.  I really, really hope I
> > > don't have to reinstall Windows.  It's SUCH a hassle to reinstall all the
> > > programs.
>
> > > Thanks for any further advice.
>
> > Well, if you look at some web pages with comments from people,
> > some are trying to "download hal.dll". If I use "search" on my
> > computer, and search by file size, I can see
>
> > hal.dll       C:\WINDOWS\system32                     "Internal Name" in properties = halmacpi.dll
> > halapic.dll   C:\WINDOWS\driver cache\i386\sp3.cab
> > halmacpi.dll  C:\WINDOWS\driver cache\i386\sp3.cab
> > halmps.dll    C:\WINDOWS\driver cache\i386\sp3.cab
>
> > If I click on the hal.dll file, "Internal Name" in the file
> > properties says the file is halmacpi.dll . In other words,
> > the OS renames the appropriate file choice to hal.dll and
> > copies it into C:\WINDOWS\system32 . And that is why,
> > attempting to download hal.dll is doomed to fail. It
> > must correspond to the type of hardware abstraction
> > layer the computer is using at the moment (which you'd see
> > in Device Manager, by examining the "Computer" entry).
>
> > I have a dual core computer (a multiprocessor) and I
> > have ACPI for power management. Therefore, halmacpi.dll
> > is the right HAL to be using, for the current state
> > of my install.
>
> > One article suggested checking boot.ini . The Recovery
> > Console has an option to rebuild the boot.ini . If the ARC
> > path was wrong (pointing to the wrong partition), apparently
> > that may give the error. So it's not the file that is missing,
> > it is the boot process looking on the wrong partition.
> > (How would that get changed on a power failure ???)
>
> > My problem right now is, I can't find any reference that
> > says exactly when "hal.dll" is loaded. Is it the first file ?
> > That seems unlikely some how. What are the odds ?
>
> > (This article would suggest NTLDR is loaded before that...
> > This article also explains the boot.ini entries a bit.)
>
> >http://en.wikipedia.org/wiki/NTLDR
>
> >http://en.wikipedia.org/wiki/Windows_NT_startup_process
>
> > If I was working on this problem, I'd be booting my Linux
> > (Ubuntu or Knoppix) CD, for a look. I'd open boot.ini in a
> > text editor, and have a look at it. Use "fdisk /dev/sda" type
> > command, to print the partition table. Open the partitions one
> > at a time, and verify which partition number is the right one.
> > And check to see if there actually is a HAL file in
> > C:\WINDOWS\system32 . There are other bootable, Windows-centric
> > CDs that can allow you to do that as well. Recovery Console
> > is fun, and may be enough to get the job done, but I like
> > a "second opinion".
>
> > *******
>
> > When I was experimenting the other day, with some P2V software
> > (for transferring a real disk, for usage inside VirtualPC 2007),
> > I happened to look inside the boot.ini on the resulting virtual
> > machine. This is the entry that was in there.
>
> >     multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Disk2vhd Microsoft
> >     Windows XP Professional" /noexecute=optin /fastdetect
> >     /KERNEL=ntkrpuni.exe /HAL=halacpi.dll
>
> > The KERNEL and HAL options, don't exist in a normal boot.ini .
> > The P2V program added them, to compensate for the fact that
> > VirtualPC 2007 is a uniprocessor environment (one computing core),
> > while my real computer is a dual core. Forcing the correct
> > KERNEL and HAL files, allowed the OS to boot inside VirtualPC 2007.
> > (That means, I'm running the same copy of Windows twice.) I did this
> > test, purely to see the Windows Activation message that results.
>
> > The experiment is interesting, because it shows if you needed to, you
> > could point to a particular HAL. That HAL file isn't on the C: file
> > ready to go - to get a copy, I could get it out of the SP3.cab file.
> > I think the P2V software, must have done the extraction to do that,
> > because otherwise it might not be there.
>
> > This doesn't really help you, except to point out how powerful and
> > critical the boot.ini is to get corrected. For example, if I was
> > to change the ARC to multi(0)disk(0)rdisk(0)partition(3) instead
> > of partition(2), the boot process would fall on its face. I happen
> > to know, my WinXP is the second partition on the disk, so I can
> > tell by looking at it, that the ARC is reasonable for the task.
>
> > "Description of the BOOTCFG Command and Its Uses"
>
> >http://support.microsoft.com/kb/317521
>
> > Reading that description, you can see some of the silly questions
> > it is going to ask you, while you're in the Recovery Console.
> > You'd be prepared to answer those questions, if you already had
> > a copy of the boot.ini. Personally, I find it easier, to just
> > boot a Ubuntu CD, open boot.ini on that partition, and edit the
> > arguments that need changing. For example, if I could see
>
> >     multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional"
> >     /noexecute=optin /fastdetect
>
> > then I'd know what to type in when bootcfg prompts. The only
> > advantage I see, from using the command, is it is going to
> > figure out the ARC for you ( "multi(0)disk(0)rdisk(0)partition(2)" ).
>
> >     Paul
>
> > > "John Wunderlich" wrote:
>
> > >> =?Utf-8?B?bW1i?= <m...(a)discussions.microsoft.com> wrote in
> > >>news:C02C3B7C-B613-4357-AFE4-0B9F22563F9C(a)microsoft.com:
>
> > >>> Okay, so I panicked for nothing, huh?  I have one more question
> > >>> before proceeding with fixmbr.  The referenced article indicates
> > >>> that it applies to Microsoft 2000.  I have XP, sp3.  Is it safe to
> > >>> proceed with fixmbr?  Thank you so much.
>
> > >> If you're worried about that, check out the KB article:
>
> > >> "Computer stops responding with a black screen when you start Windows XP"
> > >>   <http://support.microsoft.com/kb/314503>
>
> > >> .... which applies specifically to Windows XP.
> > >> Method 1, Step 3, tells you to use the FIXMBR command and refers
> > >> you back to the KB266745 article if you are concerned with the error message.
> > >> Therefore, I conclude that KB266745 applies equally well to Windows XP.
> > >> It's just that nobody has updated that article in a while.
>
> > >> -- John
> > >> .
>
> > .

You cannot usually just replace a hal.dll file and I have never had a
reason to. I don't know why it is so picked on.

When XP installs, it picks one of 7 possible hal.dlls from the
installation CD to match your hardware and THAT becomes your hal.dll.

If you start fooling around and copying in "replacements", you have a
one in seven chance of getting the right one. Are you feeling lucky?

If you understand enough about your hardware, you can determine
exactly which one of the seven is the correct one, but in my life I
have never found a need to replace it, there is always some other
simple problem that is being overlooked.

If you suspect your boot.ini, just rename it out of existence (rename
c:\boot.ini c:\boot.ini.bak).

XP will complain but still boot just fine with no boot.ini at all.

A single partition XP installation doesn't even need a boot.ini
(nonbelievers - try it).
From: mmb on
Thanks Jose. As you suggested, I renamed my boot.ini file after a search to
make sure there weren't any more. Then I rebooted, but got the same error
message about the boot.ini file and missing or corrupt hall.dll file. As
before I used F8 to choose the hard drive and it did boot, despite a brief
Missing boot.ini message. So, you're right--it boots without the boot.ini,
so obviously my problem lies elsewhere. Just wish I knew where it was
hiding. Thanks for your suggestion.

"Jose" wrote:

> On Aug 8, 2:08 pm, mmb <m...(a)discussions.microsoft.com> wrote:
> > Paul, thanks for your reply and especially for the obvious thought and time
> > you've given to my problem. I'll look at all your references and suggestions
> > a little later today when I have more time, but in the meantime I'll tell you
> > something else that occurred when I was putzing around, which may or may not
> > be relevant.
> >
> > Yesterday I searched for Hal.dll and verified that it was, in fact, in the
> > System 32 subdirectory. There was another in the cab file, among other
> > locations, which I extracted and copied into the System32 subdirectory,
> > overwriting the one that was there. When I attempted to boot I again got the
> > missing or corrupted Hal.dll message. Then I rebooted and used the F8 method
> > to select the hard drive that had previously worked. This tme it bounced me
> > to the safe mode but when I chose boot from last good configuration, it
> > wouldn't load (I can't remember what it did next other than the fact that it
> > wouldn't load) but the next I chose the option to boot in safe mode and again
> > it wouldn't load. Obviously the hal.dll I put in Syhstem 32 caused this
> > result. Again I used the recovery console to access my c:\ in which I had,
> > fortunately, saved a copy of the hal.dll before overwriting it. When I wrote
> > it back into System32 I again was able to boot using the F8 key to choose
> > hard drive that previously worked.
> >
> > Thanks again, and I'll report later..
> >
> > "Paul" wrote:
> > > mmb wrote:
> > > > Thanks John. I used the repair console CD and used the fixmbr command,
> > > > ignoring the warning. I then got the message"writing new master boot record
> > > > on physical drive\device\harddisk0\partition0" and then very quickly "The new
> > > > master boot record has been successfully written."
> >
> > > > I removed the repair disk and rebooted and then got the same *&@# message
> > > > about a corrupted hal.dll. Any further thoughts from anyone?
> >
> > > > Apparently all this started with a power outage while my computer was on.
> > > > The first thing I'm gonna do when (if) I get this problem solved is to buy a
> > > > battery backup. The laptop has the advantage of having a built-in battery
> > > > backup but I really prefer working on a desktop. I really, really hope I
> > > > don't have to reinstall Windows. It's SUCH a hassle to reinstall all the
> > > > programs.
> >
> > > > Thanks for any further advice.
> >
> > > Well, if you look at some web pages with comments from people,
> > > some are trying to "download hal.dll". If I use "search" on my
> > > computer, and search by file size, I can see
> >
> > > hal.dll C:\WINDOWS\system32 "Internal Name" in properties = halmacpi.dll
> > > halapic.dll C:\WINDOWS\driver cache\i386\sp3.cab
> > > halmacpi.dll C:\WINDOWS\driver cache\i386\sp3.cab
> > > halmps.dll C:\WINDOWS\driver cache\i386\sp3.cab
> >
> > > If I click on the hal.dll file, "Internal Name" in the file
> > > properties says the file is halmacpi.dll . In other words,
> > > the OS renames the appropriate file choice to hal.dll and
> > > copies it into C:\WINDOWS\system32 . And that is why,
> > > attempting to download hal.dll is doomed to fail. It
> > > must correspond to the type of hardware abstraction
> > > layer the computer is using at the moment (which you'd see
> > > in Device Manager, by examining the "Computer" entry).
> >
> > > I have a dual core computer (a multiprocessor) and I
> > > have ACPI for power management. Therefore, halmacpi.dll
> > > is the right HAL to be using, for the current state
> > > of my install.
> >
> > > One article suggested checking boot.ini . The Recovery
> > > Console has an option to rebuild the boot.ini . If the ARC
> > > path was wrong (pointing to the wrong partition), apparently
> > > that may give the error. So it's not the file that is missing,
> > > it is the boot process looking on the wrong partition.
> > > (How would that get changed on a power failure ???)
> >
> > > My problem right now is, I can't find any reference that
> > > says exactly when "hal.dll" is loaded. Is it the first file ?
> > > That seems unlikely some how. What are the odds ?
> >
> > > (This article would suggest NTLDR is loaded before that...
> > > This article also explains the boot.ini entries a bit.)
> >
> > >http://en.wikipedia.org/wiki/NTLDR
> >
> > >http://en.wikipedia.org/wiki/Windows_NT_startup_process
> >
> > > If I was working on this problem, I'd be booting my Linux
> > > (Ubuntu or Knoppix) CD, for a look. I'd open boot.ini in a
> > > text editor, and have a look at it. Use "fdisk /dev/sda" type
> > > command, to print the partition table. Open the partitions one
> > > at a time, and verify which partition number is the right one.
> > > And check to see if there actually is a HAL file in
> > > C:\WINDOWS\system32 . There are other bootable, Windows-centric
> > > CDs that can allow you to do that as well. Recovery Console
> > > is fun, and may be enough to get the job done, but I like
> > > a "second opinion".
> >
> > > *******
> >
> > > When I was experimenting the other day, with some P2V software
> > > (for transferring a real disk, for usage inside VirtualPC 2007),
> > > I happened to look inside the boot.ini on the resulting virtual
> > > machine. This is the entry that was in there.
> >
> > > multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Disk2vhd Microsoft
> > > Windows XP Professional" /noexecute=optin /fastdetect
> > > /KERNEL=ntkrpuni.exe /HAL=halacpi.dll
> >
> > > The KERNEL and HAL options, don't exist in a normal boot.ini .
> > > The P2V program added them, to compensate for the fact that
> > > VirtualPC 2007 is a uniprocessor environment (one computing core),
> > > while my real computer is a dual core. Forcing the correct
> > > KERNEL and HAL files, allowed the OS to boot inside VirtualPC 2007.
> > > (That means, I'm running the same copy of Windows twice.) I did this
> > > test, purely to see the Windows Activation message that results.
> >
> > > The experiment is interesting, because it shows if you needed to, you
> > > could point to a particular HAL. That HAL file isn't on the C: file
> > > ready to go - to get a copy, I could get it out of the SP3.cab file.
> > > I think the P2V software, must have done the extraction to do that,
> > > because otherwise it might not be there.
> >
> > > This doesn't really help you, except to point out how powerful and
> > > critical the boot.ini is to get corrected. For example, if I was
> > > to change the ARC to multi(0)disk(0)rdisk(0)partition(3) instead
> > > of partition(2), the boot process would fall on its face. I happen
> > > to know, my WinXP is the second partition on the disk, so I can
> > > tell by looking at it, that the ARC is reasonable for the task.
> >
> > > "Description of the BOOTCFG Command and Its Uses"
> >
> > >http://support.microsoft.com/kb/317521
> >
> > > Reading that description, you can see some of the silly questions
> > > it is going to ask you, while you're in the Recovery Console.
> > > You'd be prepared to answer those questions, if you already had
> > > a copy of the boot.ini. Personally, I find it easier, to just
> > > boot a Ubuntu CD, open boot.ini on that partition, and edit the
> > > arguments that need changing. For example, if I could see
> >
> > > multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional"
> > > /noexecute=optin /fastdetect
> >
> > > then I'd know what to type in when bootcfg prompts. The only
> > > advantage I see, from using the command, is it is going to
> > > figure out the ARC for you ( "multi(0)disk(0)rdisk(0)partition(2)" ).
> >
> > > Paul
> >
> > > > "John Wunderlich" wrote:
> >
> > > >> =?Utf-8?B?bW1i?= <m...(a)discussions.microsoft.com> wrote in
> > > >>news:C02C3B7C-B613-4357-AFE4-0B9F22563F9C(a)microsoft.com:
> >
> > > >>> Okay, so I panicked for nothing, huh? I have one more question
> > > >>> before proceeding with fixmbr. The referenced article indicates
> > > >>> that it applies to Microsoft 2000. I have XP, sp3. Is it safe to
> > > >>> proceed with fixmbr? Thank you so much.
> >
> > > >> If you're worried about that, check out the KB article:
> >
> > > >> "Computer stops responding with a black screen when you start Windows XP"
> > > >> <http://support.microsoft.com/kb/314503>
> >
> > > >> .... which applies specifically to Windows XP.
> > > >> Method 1, Step 3, tells you to use the FIXMBR command and refers
> > > >> you back to the KB266745 article if you are concerned with the error message.
> > > >> Therefore, I conclude that KB266745 applies equally well to Windows XP.
> > > >> It's just that nobody has updated that article in a while.
> >
> > > >> -- John
> > > >> .
> >
> > > .
>
> You cannot usually just replace a hal.dll file and I have never had a
> reason to. I don't know why it is so picked on.
>
> When XP installs, it picks one of 7 possible hal.dlls from the
> installation CD to match your hardware and THAT becomes your hal.dll.
>
> If you start fooling around and copying in "replacements", you have a
> one in seven chance of getting the right one. Are you feeling lucky?
>
> If you understand enough about your hardware, you can determine
> exactly which one of the seven is the correct one, but in my life I
> have never found a need to replace it, there is always some other
> simple problem that is being overlooked.
>
> If you suspect your boot.ini, just rename it out of existence (rename
> c:\boot.ini c:\boot.ini.bak).
>
> XP will complain but still boot just fine with no boot.ini at all.
>
> A single partition XP installation doesn't even need a boot.ini
> (nonbelievers - try it).
> .
>