Stop Code 0x0000005c

OSR_Community_User · April 20, 2009, 7:57am

Hello all,

we are HW vendor and we are working on the BIOS for a new hardware design (x86 dual-core, ACPI).

With the new BIOS we get an instant reboot with Windows XP, but Vista throws a Blue Screen 0x0000005C (0x00003000, 0x00000001, 0x00000008, 0x00000000). Note that this happens at system initialization – long before the system is up and running, so startup/recovery configuration of the System Properties is not in effect at that time.

DDK Docs only tell us that HAL_INITIALIZATION_FAILED, howver, the 4 params are not explained. I did some investigation and got the following results (best viewed with notepad :

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

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 questions are what is going on in function hal!HalpGetApicInti and what is the meaning of DWORD value at hal!HalpPicVectorRedirect+0x20?

Can anybody tell?
Thanks for any hint!
Gernot

James_Harper · April 20, 2009, 8:16am

> Hello all,

we are HW vendor and we are working on the BIOS for a new hardware
design (x86
dual-core, ACPI).

With the new BIOS we get an instant reboot with Windows XP, but Vista
throws a
Blue Screen 0x0000005C (0x00003000, 0x00000001, 0x00000008,
0x00000000). Note
that this happens at system initialization – long before the system
is up and
running, so startup/recovery configuration of the System Properties is
not in
effect at that time.

DDK Docs only tell us that HAL_INITIALIZATION_FAILED, howver, the 4
params are
not explained. I did some investigation and got the following results
(best
viewed with notepad :

You’ll most likely get some useful replies on this list, but if it was
me I would try booting Linux. If it boots successfully then you probably
won’t learn anything new (Linux does give some detailed responses about
things like ACPI tables though), but if it doesn’t then you have a
better chance of finding out exactly where the problem lies, especially
if you can stick some extra debugging in the source code (if you can
write a BIOS then you are more than qualified to do this :).

Good luck.

James

OSR_Community_User · April 20, 2009, 9:01am

> […] if it was me I would try booting Linux.

Q_37: Check all that apply.

For BIOS development, operating system source code can only be replaced
by…
intelligent system recovery
meaningful error messages
opening a support incident with [OS vendor]
someone else solving the problem
well documented source code

SCNR!

Jake_Oshins · April 20, 2009, 1:27pm

This means that the HAL couldn’t figure out which I/O APIC RTE corresponds
to your RTC. (Had to look that one up, as the error message is clearly not
very helpful.)

–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.

wrote in message news:xxxxx@ntdev…
> Hello all,
>
> we are HW vendor and we are working on the BIOS for a new hardware design
> (x86 dual-core, ACPI).
>
> With the new BIOS we get an instant reboot with Windows XP, but Vista
> throws a Blue Screen 0x0000005C (0x00003000, 0x00000001, 0x00000008,
> 0x00000000). Note that this happens at system initialization – long
> before the system is up and running, so startup/recovery configuration of
> the System Properties is not in effect at that time.
>
> DDK Docs only tell us that HAL_INITIALIZATION_FAILED, howver, the 4 params
> are not explained. I did some investigation and got 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 questions are what is going on in function
> hal!HalpGetApicInti and what is the meaning of DWORD value at
> hal!HalpPicVectorRedirect+0x20?
>
> Can anybody tell?
> Thanks for any hint!
> Gernot
>

OSR_Community_User · April 22, 2009, 6:53am

Jake,

that helped – thank you very much!

Gernot