Sean,
Did you try Slobodan's suggestion?
Make sure you got these components:
Microsoft ACPI-Compliant Control Method Battery [Version 5.1.2600, R620], [Visibility=1000]
Microsoft ACPI-Compliant Embedded Controller [Version 5.1.2600, R620], [Visibility=1000]
Microsoft ACPI-Compliant System [Version 5.1.2600, R620], [Visibility=1000]
And if you have WMI Core in place:
Microsoft Windows Management Interface for ACPI [Version 5.1.2600, R620], [Visibility=1000]
Also, thy experiment (to make sure your target is ACPI compatible):
Build ACPI image, deploy, get BSOD. Shutdown the target (or reboot it in a different OS if you have a dual boot set up). Access to
the disk offline. Rename hal.dll to halacpi.dll under \windows\system32 dir. Copy hal.dll (Standard PC) to the image's
\windows\system32 directory. Change boot.ini to use /HAL option to switch between different HALs and see if you target boots fine
with halacpi.dll (ACPI) and hal.dll (Standard PC). Most likely, it will only boot with the last one.
Another high level thing to try - XPProEmulation.slx from
www.xpefiles.com. Just include your platform (ACPI imported pmq/sld) to
the configuration (it may take a time), build, deploy and see if the issue is still there. It will tell you if the problem is just
about some missing components or more low level.
If it is more low level issue, I'd suggest to switch to KD (Kernel Debugger)/WinDbg to see what exactly is happening when you boot
your target with ACPI compliant platform.
Here is the steps how to set up the WinDbg:
Just download the tool and symbol files from
http://www.microsoft.com/whdc/ddk/debugging/default.mspx.
Then follow the leads from
http://support.microsoft.com/defaul...port/kb/articles/q121/5/43.asp&NoWebContent=1 and
http://support.microsoft.com/defaul...port/kb/articles/q151/9/81.asp&NoWebContent=1 (if
you use null modem for remote debugging).
MS Debugging Tools KB is here:
http://www.microsoft.com/whdc/ddk/debugging/DBG-KB.mspx.
Hope this helps,