Acpitabl.dat once again

[StigH]

Hello,

I tried out Winxp64 a year ago which was no plesant expirence. A year has passed and i was so confident that all those initial blunders where corrected, so i went out and purchased the darn thing. After all there's no point in having a 64-bit computer if you only run it on half the cylinders.

After failing to install it "out of the box" i tripped over Fernandos excellent guide regarding nvraid drivers. This worked very well for me and i was up and running in no time. I only have one thing to complain about. It takes forever to get past the splash screen when booting. I know this is a common problem with several solutions all of which hasn't worked for me.

I have tried all availble version of the nvraid drivers. Did a totally striped down installation with PS/2 mouse, keyboard and all unneccessary mainboard features disabled. As before, it seem to hang while loading acpitabl.dat. Funny thing is that this file does not exist on my system. I have search 2 other 2003 servers and three XP64 machine for the same file. It isn't there. So im guessing it a temporary file which is created and destroyed during the boot sequence. Im not sure it has anything to do with the problem at all.

Bottom line is; im stuck.

Right now im most likely to let it go until servicepack 2 arrives (or a new set of nv-drivers).

Any ideas for me to try out before i call it quits ?

Feels like a complete waste of hardearned money.

HW

======

DFI NF4 SLI-Expert mobo

2*1024GB Corsair XMS4000

4*WD Raptor raid-0 on NV-controller

2*GF 7900GT SLI

Raidmax 650W PSU

Asetek water cooling

Edited December 28, 2006 by StigH

[leavesley]

"As before, it seem to hang while loading acpitabl.dat."

Not that it is any help to you whatsoever, but I have exactly the same problem, but worse. I just installed XP64 pro on a Dell Precision 490. I get to acpitabl.dat, and then the computer just hangs indefinitely. I left it for about an hour once, just to make sure, still nothing. Just stuck on acpitabl.dat

Let me know if you ever find a solution.......

[androidtopp]

I am also seeing this issue - Interestingly enough, my Precision 490 works fine (SAS5/iR controller) but a Precision T5400 (SAS6/iR controller) hangs at acpitabl.dat. Both are being deployed the exact same Windows XP x64 SP2 OS task sequence from SCCM. Both complete their minisetup fine (although the T5400 takes a long time to do so, I assume related to this issue) but the 490 continues to work perfectly while the T5400 never completes the post-minisetup reboot.

Anyone else see this issue?

[TranceEnergy]

Havent had such issues, but still..

Have you tried looking at your manufactures website for a so called driver boot disk for your computer?

It should have a x64 folder in it, and it should be a driver that is supposed to be integrated as a textmode stage driver.

If possible i would disable as much as possible in your computers bios for use while installing windows, to easen the troubleshooting.

[androidtopp]

TranceEnergy,

That's exactly what I've tried uysed - any number of different versions of the drivers from Dell. I have no problem with this when it comes to x86 - it's just x64 where I have issues. Interestingly enough, even after I disable the step in my task sequence where the machine being imaged contacts the SCCM server for drivers (leaving only the Windows XP build in drivers and a couple MSDs - Intel Matrix, SAS5, SAS6) I have the exact same issue.

Starting to get very frustrated...I've disabled everything I can think of, but I need NIC, SATA (for CD-ROM) and obviously the SAS to be enabled, so short of audio and USB, there's not a whole lot I can turn off.

Thanks,

Andrew

[TranceEnergy]

Did you ever find a solution? I used to be an nvidia user, and i also had some negative experience with that. Such as corrupt files when copying files across disks and such. The remedy was to not use the drivers for the onboard ide-raid devices. This was a couple of years back. I know this doesnt help, but sometimes hardware is just the suck..

Maybe you could look into my ryanvm thread and see if you find any interesting KB that might help the situation. I run a install with every one of these kb's installed and it's absolutely awesome.

[androidtopp]

Well, I did find a solution...but not a good one, in this context. I switched from injecting the x64 mass storage drivers from the sysprep.ini to injecting from driver packages in my SCCM task sequences. So that fixed the issue, but unless you have SCCM, that's not a terribly helpful suggestion.