with Windows Vista I am getting Stop code
0x0000005C (0x00003000, 0x00000001, 0x00000008, 0x00000000)
during Setup. I also tried with XP. However, XP does not throw a Blue
Screen, but reboots instantly.
The machine I am trying do do this with is a Core 2 Duo / ACPI BIOS.
Driver Kit tells me that HAL_INITIALIZATION_FAILED but the parameters
are not explained to get an idea what might go wrong.
Doing a bit of research makes me suspecting the problem is related to
ACPI APIC table on MP machines.
I found that when I switch of APIC table option in BIOS Setup, XP
installs giving me the "Advanced Configuration and Power Interface
(ACPI) PC" HAL.
Does anybody know the meaning of the params? Microsoft prints the stop
code, they should. Why don't they tell us?
Thank you!
Gernot
Because this is a very unusual code that almost never occurs. It can
happen if you take disk that was installed on one system, and try to boot
the same disk on another system. Otherwise, it usually indicates a
hardware problem.
Once you have XP installed with the ACPI HAL, are you able to do a Vista
upgrade?
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
> Because this is a very unusual code that almost never occurs. It can
> happen if you take disk that was installed on one system, and try to boot
> the same disk on another system. Otherwise, it usually indicates a
> hardware problem.
>
> Once you have XP installed with the ACPI HAL, are you able to do a Vista
> upgrade?
> --
> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.
Tim,
thanks for your answer. I know that this is a very unusual Stop Code.
We are HW vendor and get the Bug Check on a new design we are doing an
ACPI BIOS for. So it would help enormously if we knew where to start
digging in.
Trying an installation from a similar platform on the new one is a
great idea. We will give this a try and come back.
BTW. What is worth being mentioned is that Linux can live with the
BIOS.
Thanks again,
Gernot
It would help a lot if we could get a stack trace or a !analyze of
the failure. Vista more that doubled the number of places it throws that
bugcheck over XP. It is possible to change the setup parameters to attach
a debugger for setup (I have not done this on Vista, but it is supposed to
work).
As far a Linux supporting the BIOS, Linux will support almost any
BIOS including ones with literally hundreds of errors, basically saying
Linux can use the BIOS is the same as saying DOS can use it.
--
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"Gernot Buselmeier" <Gernot.B...@gefanuc.com> wrote in message
news:83aa76dc-9d7f-4b1a...@p11g2000yqe.googlegroups.com...
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 3992 (20090407) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
__________ Information from ESET NOD32 Antivirus, version of virus signature database 3992 (20090407) __________
The message was checked by ESET NOD32 Antivirus.
> It would help a lot if we could get a stack trace or a !analyze of
> the failure. Vista more that doubled the number of places it throws that
> bugcheck over XP. It is possible to change the setup parameters to attach
> a debugger for setup (I have not done this on Vista, but it is supposed to
> work).
>
Don,
thanks for your answer. I did some investigation during the last
view days and I want to share the results with you.
First, booting a Windows XP image set up on a similar machine
leads to instant reboot, no matter how startup/recovery is configured.
Obviously the problem occurs before the system boot has reached a
state in which the startup/recovery settings are in effect.
Next, debugging a Vista MP APIC HAL installation gives the
following results (best viewed with notepad ;) :
1. kd> !analyze -v
*******************************************************************************
* Bugcheck
Analysis *
*******************************************************************************
HAL_INITIALIZATION_FAILED (5c)
Arguments:
Arg1: 00003000
Arg2: 00000001
Arg3: 00000008
Arg4: 00000000
Debugging Details:
------------------
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x5C
CURRENT_IRQL: 2
LAST_CONTROL_TRANSFER: from 819112d7 to 818fc514
STACK_TEXT:
819396cc 819112d7 00000003 3ad37152 00000000 nt!
RtlpBreakWithStatusInstruction
8193971c 81911dbd 00000003 00000000 00000001 nt!KiBugCheckDebugBreak
+0x1c
81939ae8 81911163 0000005c 00003000 00000001 nt!KeBugCheck2+0x66d
81939b08 8183e044 0000005c 00003000 00000001 nt!KeBugCheckEx+0x1e
81939b30 81831df9 8197a290 827a6648 80815eac hal!HalpInitIntiInfo+0x4e
81939b58 81b906ce 00000000 80815eac 00000000 hal!HalInitSystem+0x1c5
81939cf0 81b0de73 80815eac 3ad37b72 827f3c00 nt!InitBootProcessor+0xe7
81939d3c 819307c9 81940900 81940640 8193a000 nt!KiInitializeKernel
+0x65b
00000000 f000eef3 f000e2c3 f000eef3 f000eef3 nt!KiSystemStartup+0x319
WARNING: Frame IP not in any known module. Following frames may be
wrong.
00000000 00000000 f000e2c3 f000eef3 f000eef3 0xf000eef3
STACK_COMMAND: kb
FOLLOWUP_IP:
nt!InitBootProcessor+e7
81b906ce 84c0 test al,al
SYMBOL_STACK_INDEX: 6
SYMBOL_NAME: nt!InitBootProcessor+e7
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrpamp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 47918b12
FAILURE_BUCKET_ID: 0x5C_nt!InitBootProcessor+e7
BUCKET_ID: 0x5C_nt!InitBootProcessor+e7
Followup: MachineOwner
2. Examining the stack and inspecting assembler code pointed me to the
following code sequence in function hal!HalpInitIntiInfo:
8183e025 e8be27feff call hal!HalpGetApicInti (818207e8)
8183e02a 84c0 test al,al
8183e02c 7516 jne hal!HalpInitIntiInfo+0x4e (8183e044)
8183e02e 57 push edi
8183e02f ff3528a48281 push dword ptr [hal!HalpPicVectorRedirect
+0x20 (8182a428)]
8183e035 6a01 push 1
8183e037 6800300000 push 3000h
8183e03c 6a5c push 5Ch
--> 8183e03e ff15a8228181 call dword ptr [hal!_imp__KeBugCheckEx
(818122a8)]
8183e044 0fb745fc movzx eax,word ptr [ebp-4]
...
Note that at the time of the KeBugCheckEx call the arguments on the
stack are exactly those of the Stop Code (edi==0, dword ptr [hal!
HalpPicVectorRedirect+0x20] == 0x00000008).
If the hal!HalpGetApicInti function returns with a non-zero result in
register AL, processing continues normally, otherwise the system
bugchecks. Now the question is what is going on in hal!
HalpGetApicInti?
Thanks for any hint!
Gernot
What is going on is the HAL is checking the ACPI tables for presence
of the real time clock interrupt data, and the SCI interrupt data. At this
point I recommend you go to the http://www.osronline.com NTDEV list and post
the quetion, I believe the person who wrote the code that is having the
problem can respond there.
--
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"Gernot Buselmeier" <Gernot.B...@gefanuc.com> wrote in message
news:cf204dd0-2d82-4eef...@r37g2000yqn.googlegroups.com...
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4016 (20090417) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4016 (20090417) __________
Don,
thank you for directing me to the right forum to post my question.
That was successful.
Thanks again!
Regards,
Gernot