Jump to content

Compiling ACPI v2.0 driver for Windows XP SP3 and Windows 2003 SP2 (x32/x64)


Mov AX, 0xDEAD

Recommended Posts


12 minutes ago, Dietmar said:

AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.I2C2.CAM0._HID)
AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.I2C4.CAM1._HID)
AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.I2C2.PMIC._HID)
AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.I2C0.HDAC._HID)

*** Fatal System Error: 0x000000a5
                       (0x0000000000000003,0xFFFFFADCE4CB5C30,0xFFFFFFFFC0000034,0x000000004449485F)

Break instruction exception - code 80000003 (first chance)

acpi64v22.txt without bsod:

Quote

AMLI: FFFFFADCE5564040: AsyncEvalObject(\_SB.PC00.I2C2.CAM0._HID)
="INT3471"FFFFFADCE3E8E010 ACPIBuildProcessDevicePhaseUid: Status = 00000103
AMLI: FFFFFADCE5564040: AsyncEvalObject(\_SB.PC00.I2C4.CAM1._HID)
="INT3474"FFFFFADCE3E8EDB0 ACPIBuildProcessDevicePhaseUid: Status = 00000103
AMLI: FFFFFADCE5564040: AsyncEvalObject(\_SB.PC00.I2C2.PMIC._HID)
="INT3472"FFFFFADCE3E8EA00 ACPIBuildProcessDevicePhaseUid: Status = 00000103
FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhaseAdr: Status = 00000000
FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhaseSta: Status = 00000000
FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDeviceGenericEval: Phase6 Status = 00000000
FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhaseEjd: Status = 00000000
FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDeviceGenericEval: Phase8 Status = 00000000
FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhasePrw: Status = 00000000
FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDeviceGenericEval: Phasea Status = 00000000
FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhasePr0: Status = 00000000
FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDeviceGenericEval: Phasec Status = 00000000
FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhasePr1: Status = 00000000
FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDeviceGenericEval: Phasee Status = 00000000
FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhasePr2: Status = 00000000
FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDeviceGenericEval: Phase12 Status = 00000000
FFFFFADCE3E8E3B0 5d071100 (0x00000000): ACPIDeviceInternalDelayedDeviceRequest - Transition to D0
FFFFFADCE3E8E3B0 5d071100 ACPIBuildProcessDevicePhasePsc: Status = 00000103
FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhaseAdr: Status = 00000000
FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhaseSta: Status = 00000000
FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDeviceGenericEval: Phase6 Status = 00000000
FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhaseEjd: Status = 00000000
FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDeviceGenericEval: Phase8 Status = 00000000
FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhasePrw: Status = 00000000
FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDeviceGenericEval: Phasea Status = 00000000
FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhasePr0: Status = 00000000
FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDeviceGenericEval: Phasec Status = 00000000
FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhasePr1: Status = 00000000
FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDeviceGenericEval: Phasee Status = 00000000
FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhasePr2: Status = 00000000
FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDeviceGenericEval: Phase12 Status = 00000000
FFFFFADCE3E8D010 5d071100 (0x00000000): ACPIDeviceInternalDelayedDeviceRequest - Transition to D0
FFFFFADCE3E8D010 5d071100 ACPIBuildProcessDevicePhasePsc: Status = 00000103
AMLI: FFFFFADCE5564040: AsyncEvalObject(\_SB.PC00.I2C0.HDAC._HID)="INT00000"

FFFFFADCE3E8DDB0 ACPIBuildProcessDevicePhaseUid: Status = 00000103
AMLI: FFFFFADCE5564040: AsyncEvalObject(\_SB.HIDD._STA)

AMLI: FFFFFADCE5564040: \_SB.HIDD._STA()
FFFFFADCE3E8D970 ACPI\INTC1070 ACPIBuildProcessDevicePhaseHid: Status = 00000103
AMLI: FFFFFADCE5564040: AsyncEvalObject(\_SB.PC00.THC0.TLC1._STA)

AMLI: FFFFFADCE5564040: \_SB.PC00.THC0.TLC1._STA()
FFFFFADCE3E8C010 1 ACPIBuildProcessDevicePhaseAdr: Status = 00000103
AMLI: FFFFFADCE5564040: AsyncEvalObject(\_SB.PC00.THC0.TLC2._STA)

1) if bsod occurs at random place, my patch is useless, still need finished full log

2) if bsod occurs always at same place, problem is SB.PC00.I2C0.HDAC._HID or next thing _SB.HIDD._STA or some between FFFFFADCE3E8DDB0 ACPIBuildProcessDevicePhaseUid: Status = 00000103
 

Link to comment
Share on other sites

@Mov AX, 0xDEAD

The problem is, that with the debug acpi.sys and windbg connected,

no Bsod happens.

The only thing is a breakpoint, where you can hit "i" a single time

and then XP bit64 boots fast to desktop with all processors,

with sound Realtek,

full functional.

This message

The DEBUG acpi.sys connected to Windbg hits Breakpoint 0x7E (0x80000003, xxx, yyy) .

*** Assertion failed: The BIOS has reported inconsistent resources (_CRS).  Please upgrade your BIOS.NT_SUCCESS(status)
***   Source File: c:\win2k3\nt\base\busdrv\acpi\driver\nt\bus.c, line 2802

When you hit "i", it boots to desktop, no other message at all.

Edited by Dietmar
Link to comment
Share on other sites

10 minutes ago, Dietmar said:

@Mov AX, 0xDEAD

The problem is, that with the debug acpi.sys and windbg connected,

no Bsod happens.

we can add debug output where a5, (0x3,,C0000034) is used to checked build to see parent device

tomorrow i will write what to add if you still want to play with it :)

EDIT: please send me original DSDT in binary form

Edited by Mov AX, 0xDEAD
Link to comment
Share on other sites

@Mov AX, 0xDEAD

Here is raw DSDT from Bios file F22 for the Gigabyte UD z690 DDR4 board.

https://ufile.io/ad54jinp

Interesting is, that on really ALL z690 boards this Bsod happens.

But I also think, that their DSDT's are not so much different, all Intel

Dietmar

 

PS: Here is the binary DSDT,

fresh read out from running XP 64bit SP2 on this Gigabyte board via ReadwriteEverything 1.7 bit64.

https://ufile.io/qe7thwyc

Edited by Dietmar
Link to comment
Share on other sites

On 1/1/2023 at 1:40 PM, George King said:

@UsefulAGKHelper You managed VirtualBox and XP x64 debugging right?

Yes, I managed to do it using WinDBG preview, you can easily get it from Microsoft Store (for me only the version of windbg from microsoft store works to start debugger on VirtualBox, I don't know why).

I got the information from this link: https://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/WINDBG Kernel%26User Mode Debugging/WINDBG Kernel%26User Mode Debugging.md

Here's what I have done so far (serial debugging):

Quote

Settings for exercise:

Kernel debugging with Windbg Preview in Host -> debugging Guest VM:

Guest VM:

CMD as administrator:

bcdedit /debug on
bcdedit /dbgsettings serial debugport:1 baudrate:115200 (assuming the port is COM1)
shut down the VM

Go into the settings for our Virtualbox Windows VM:
Serial Ports -> Port1 -> Enable serial port
Port number COM1
Port Mode -> Host Pipe
Uncheck “Connect to existing pipe/socket”
Path/Address -> \\.\pipe\MalDBG
Start VM

HOST:

Install Windbg Preview
Go to File -> "Start Debugging” and select “Attach to Kernel”
Go to COM tab -> Check Pipe and Reconnect
Resets 0
Baud Rate 115200
Port \\.\pipe\MalDBG
Uncheck Break on connection
Click OK - To attach to kernel of our VM

For more advice on how to use proper commands to do the debug tests properly on VirtualBox, you can also ask @Mov AX, 0xDEAD and @Dietmar for help.

Serial debugging with VirtualBox is what I am familiar. For other types of debugging, you can always ask these two or anyone else experienced with using WinDBG.

If BCD is disabled, the following switches for debuging on boot.ini can be found here: https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/switch-options-for-boot-files#more-information

Good luck.

Edited by UsefulAGKHelper
Link to comment
Share on other sites

@UsefulAGKHelper

Thanks a lot!

I am running Windbg on a checked acpi.sys with guest XP 64 bit, for to solve the crazy Bsod A5 (0x03,..).

Over serial cable it is slow. My Log file is now bigger than 40 MB and XP 64 still not booted to desktop, but without(!) error now for 10 hours.

I use free ntoskrnl, free hal and DEBUG acpi.sys.

But where is problem ): To boot XP SP1 to full desktop using Qemu, on the very first Raspi Pi, needs 24 hours^^.

Now I think about the possibility of the build command using razzle . There is an no_opts switch and maybe it works for us,

the free acpi.sys comes then without binary "optimization" which propability gives this Bsod

Dietmar

Link to comment
Share on other sites

37 minutes ago, Dietmar said:

@UsefulAGKHelper

Thanks a lot!

I am running Windbg on a checked acpi.sys with guest XP 64 bit, for to solve the crazy Bsod A5 (0x03,..).

Over serial cable it is slow. My Log file is now bigger than 40 MB and XP 64 still not booted to desktop, but without(!) error now for 10 hours.

I use free ntoskrnl, free hal and DEBUG acpi.sys.

But where is problem ): To boot XP SP1 to full desktop using Qemu, on the very first Raspi Pi, needs 24 hours^^.

Now I think about the possibility of the build command using razzle . There is an no_opts switch and maybe it works for us,

the free acpi.sys comes then without binary "optimization" which propability gives this Bsod

Dietmar

Windows once connected to the debugger, it relies on it to run once it's data shows on the debugger, maybe that's why it's slower.

Without debugging, it's much faster because it doesn't rely on the debugger.

Obviously without the "optimization", BSOD appears.

Obviously, you should still debug ACPI.SYS for testing purposes (using commands to get it to boot without BSOD) but if things take too long to work, then you should also try the same without the debugger so it can show the BSOD faster.

Edited by UsefulAGKHelper
Link to comment
Share on other sites

Hi, anybody here, who knows, how to recover a *.txt file under XP SP3,

wish is overwritten from crazy windbg with the same name

Dietmar

PS: I make a try with Header Signature EF BB BF for *.txt files,

put this in Winhex File Type Signatures.txt as Fake for Windows Password pwl , but much too much results.

But it works. Get never seen *.txt documents on my compi :thumbup .

So it is only a 12 hours time loss, brr..

Edited by Dietmar
Link to comment
Share on other sites

@Mov AX, 0xDEAD

Here are the 2 Log files.

The free acpi.sys which makes the loong Logfile boots XP SP2 64 bit

for the very first time as a free acpi.sys to full desktop, but only with connected Windbg, without same Bsod.

The acpi.sys with the short Log file gives this Bsod A5 (0x03, xxx, 0xc00000034,yyy) always.

May be, that it is a time problem.

At once then I understand, why the debug version of acpi.sys always works: It has all time,

means 12 hours for to boot x64.

And not a single Bsod happens for the Debug acpi.sys with connected windbg

Dietmar

Log files

https://ufile.io/0r3bmck4

 

Edited by Dietmar
Link to comment
Share on other sites

@Mov AX, 0xDEAD

May be GSA1 Bsod, because ObjPath=TZ10,Scope=\_TZ, psz=TZ10 is listed in acpi Log,

but TZ10 does not exist in DSDT of the Gigabyte z690 UD 400 DDR4 .

I test tomorrow

Dietmar

EDIT: I delete whole GSA1 in Bios and flash.

XP SP3 boots normal, but same Bsod A5 (0x03,..) in XP SP2 bit 64.

So, GSA1 does not make this Bsod.

Edited by Dietmar
Link to comment
Share on other sites

15 hours ago, Dietmar said:

@Mov AX, 0xDEAD

Here are the 2 Log files.

The free acpi.sys which makes the loong Logfile boots XP SP2 64 bit

for the very first time as a free acpi.sys to full desktop, but only with connected Windbg, without same Bsod.

The acpi.sys with the short Log file gives this Bsod A5 (0x03, xxx, 0xc00000034,yyy) always.

May be, that it is a time problem.

@Dietmar

I think this is multiple threads race condition problem

If you filter acpic034mehrtext.txt and keep only c00034 lines, then compare with short bsod log, i will see difference in order

it matches at begin, but later difference is random

Quote

C0000034 #15
C0000034 #8
C0000034 #8
C0000034 #15
C0000034 #8
C0000034 #14
C0000034 #8

 vs

Quote

C0000034 #15
C0000034 #8
C0000034 #8
C0000034 #15
C0000034 #14
C0000034 #8
C0000034 #15

This mean apci is most async, it call other driver and kernel with callbacks, get answer "postponed", after some time event triggered and callback called, so every boot order of execution is not same

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...