Custom Partitioning Causes Windows "hal.dll missing" Error

[Elemecca]

I am trying to create a triple-boot scheme on my MacBook: Mac OS 10.5 (Leopard), Windows XP Professional, and Gentoo Linux. In addition to one partition for each OS, I created an NTFS shared data partition. This means I can't use Disk Utility to partition the drive, since it only supports having three partitions in hybrid GPT/MBR mode.

This three-partition limit is because an MBR (Master Boot Record) table has support for only four partitions, one of which is used by the EFI system partition on a Mac. If you want more partitions than that you use an extended partition, which has another partition table in its VBR (Volume Boot Record). A GPT (GUID Partition Table), on the other hand, supports up to 128 partitions and doesn't support extended partitions. In order to get around this, I partitioned the disk using GNU sfdisk (an MBR table editor) and then manually duplicated the table into the GPT with GNU parted. I was careful to preserve the OS X and EFI partitons.

With this new partition scheme in place, OS X, the Gentoo live CD, and the Windows install CD can see all four (actually five) partitions. Gentoo and OS X appear to work as normal, but when I try to boot into the graphical portion of the Windows XP setup, I get the familiar "hal.dll missing or corrupt" error message.

I am using rEFIt (http://refit.sourceforge.net) as my boot loader instead of the built in one because the built in one doesn't have support for more than two OSes.

Before I started this triple-boot fiasco, I had Windows running fine. I decided to reinstall it when I could find no freeware system to resize its partition (the GParted live CD is broken on recent Mac hardware). I had started the install with the Boot Camp Assistant and reformatted the partition labeled "BOOT CAMP" as specified in the Boot Camp Guide. However, the Boot Camp Assistant doesn't understand my new partition scheme and refuses to start the installation. I tried just booting the Windows install CD from rEFIt and installing, but when it rebooted in the middle of setup I got the "hal.dll missing" error.

I suspect that the Boot Camp Assistant did something special to the partition tables and/or the Windows partition which was reversed by my fiddling with the tables.

I have used the Recovery Console on the Windows install CD to run `fixmbr`, `fixboot` and `bootcfg /rebuild`. I have verified that the boot.ini file is correct. Just in case, I copied the hal.dll from a working copy of WinXP Pro SP2, which didn't fix it either.

The strangest thing about this whole situation is that I can boot the Windows partition just fine in VMWare Fusion under OS X.

EDIT: The attached zip file (dump_tables.zip) contains binary images of the various partition tables: the GPT, the MBR, both EBRs, and the Windows VBR.

 

[LimitlessEarth]

I am having a similar problem. After hours of running through windows I can't solve this delema. I had wanted more space for windows on my HD so I created another partition in FAT. I turned it off once and got the "Hal.dll" message. I really don't want to reformat, as I have lots of valuables saved to my first partition. Help would be much appreciated.

 

[Elemecca]

It's the MBR

These are my partitions in order:
EFI System (FAT 32)
Mac OS X (HFS+)
Windows XP (NTFS)
Gentoo Linux (ReiserFS)
Shared Data (NTFS)

In the MBR table, the Gentoo and Shared partitions are in an extended partition.

I removed the Gentoo and Shared partitions from the tables and re-installed Windows with the BootCamp Assistant, and Windows booted correctly. I used dd to take images of the MBR and GPT while everything was working, then added the Gentoo and Shared partitions to the tables. When I rebooted after changing the tables, Windows was back to the familiar hal.dll error. I used dd to clone the image of the working MBR back on to the drive, and Windows worked fine again. Thus, I thought that whatever the problem is, it must be in the MBR.

I compared the working MBR to the new one using Araxis Merge and discovered that they vary only in the fourth entry in the partition table. In the working MBR, the fourth partition entry is empty, and in the new MBR it points to the extended partition containing the Gentoo and Shared partitions.

With the working MBR in place, Windows boots fine but can't access the shared data partition. Anything that can use the GPT (i.e. Mac OS X, Linux) can see all the partitions. This arrangement is an improvement, but not a solution.