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...@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...@discussions.microsoft.com> wrote in
> > > >>news:
C02C3B7C-B613-4357-AFE4-0B9F22563F9C@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).
> .
>