Jump to content

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


Mov AX, 0xDEAD

Recommended Posts

8 hours ago, Dietmar said:

I get this Bsod also 1 time with debug acpi.sys, debug ntoskrnl and debug hal.

I think, the information is not enough, so I try the loong version also )

@Dietmar

yes, this lite log doesn't point to exact problem dsdt code:

Quote

FFFFFADCE3E8E760 5d071100 ACPIBuildProcessDevicePhasePr2: Status = 00000000
FFFFFADCE3E8E760 5d071100 ACPIBuildProcessDeviceGenericEval: Phase12 Status = 00000000
FFFFFADCE3E8E760 5d071100 (0x00000000): ACPIDeviceInternalDelayedDeviceRequest - Transition to D0
FFFFFADCE3E8E760 5d071100 ACPIBuildProcessDevicePhasePsc: Status = 00000103
FFFFFADCE3E8E470 ACPIBuildProcessDevicePhaseUid: Status = 00000103

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

Break instruction exception - code 80000003 (first chance)

need full log, but with COM speed it can be very long :)

!amli set spewon verboseon logon traceon

Link to comment
Share on other sites


@Mov AX, 0xDEAD

I am in the still running Debugger.

*.txt is now about 50 Mbyte.

Endless loop with

HAL: RTC interrupt flag is not cleared by first read.
| RTC Status Register C = 0xc0

 

Any idea what I can put in commandline of Windbg, for to check or overcome this?

Dietmar

Link to comment
Share on other sites

@Mov AX, 0xDEAD

Before Windbg reaches a Breakpoint, telling this, I think because of this endless loop

 

AMLI:| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | HAL: RTC interrupt flag is not cleared by first read.
| RTC Status Register C = 0xc0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | HAL: RTC interrupt flag is not cleared by first read.
| RTC Status Register C = 0xc0
| | | | | HAL: RTC interrupt flag is not cleared by first read.
| RTC Status Register C = 0xc0
| | | | | HAL: RTC interrupt flag is not cleared by first read.
| RTC Status Register C = 0xc0
| | | | | | | | | | HAL: RTC interrupt flag is not cleared by first read.
| RTC Status Register C = 0xc0
| | | | | HAL: RTC interrupt flag is not cleared by first read.
| RTC Status Register C = 0xc0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ValidateTarget=0 (pdataTarget=e3a32338)
=0x0000000000000014HAL: RTC interrupt flag is not cleared by first read.
)RTC Status Register C = 0xc0

fffffadce408d855: })
fffffadce408f4c0: }HAL: RTC interrupt flag is not cleared by first read.
RTC Status Register C = 0xc0
*** DPC execution time exceeds system limit
    This is NOT a break in update time
    This is a BUG in a DPC routine
    Perform a stack trace to find the culprit
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
fffff800`011a02c0 cc              int     3

 

 

 

 

Link to comment
Share on other sites

6 minutes ago, Dietmar said:

@Mov AX, 0xDEAD

Before Windbg reaches a Breakpoint, telling this, I think because of this endless loop

AMLI:| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | HAL: RTC interrupt flag is not cleared by first read.
| RTC Status Register C = 0xc0

these messages are from checked hal.dll

6 minutes ago, Dietmar said:

*** DPC execution time exceeds system limit
    This is NOT a break in update time
    This is a BUG in a DPC routine
    Perform a stack trace to find the culprit

i think this is OK because slow COM connectiuon

Link to comment
Share on other sites

I stuck with kernel debugging XP/W2003 x64 on VirtualBox, WinDBG hangs on virtual com1 port connection.

VirtualKD connection also useless because it doesnt work with VBoxHardenedLoader required for custom dsdt/ssdt tables.

QEMU also bad, it doesnt have good documentation for win32 platform,  i dont know how to enable virtual com port, there is a lot of options and nothing to works

Last hope is VMWare and VirtualPC...

Link to comment
Share on other sites

5 minutes ago, Mov AX, 0xDEAD said:

I stuck with kernel debugging XP/W2003 x64 on VirtualBox, WinDBG hangs on virtual com1 port connection.

VirtualKD connection also useless because it doesnt work with VBoxHardenedLoader required for custom dsdt/ssdt tables.

QEMU also bad, it doesnt have good documentation for win32 platform,  i dont know how to enable virtual com port, there is a lot of options and nothing to works

Last hope is VMWare and VirtualPC...

@UsefulAGKHelper You managed VirtualBox and XP x64 debugging right?

Link to comment
Share on other sites

@Mov AX, 0xDEAD

PC1: Try a virtual machine QEMU (virt-manager) on Linux e.g. Debian9 and Serial TCP net console Client Mode - set IP 192.168.0.2:4555

PC2: IP 192.168.0.2 install Fabulatech Serial Port Redirector, add virtual port COM Server eg. port TCP 4555, port COM12, speed 115200, Raw Data

Run Windbg -> Kernel Debug on COM12 115200

Edited by reboot12
Link to comment
Share on other sites

29 minutes ago, Dietmar said:

@Mov AX, 0xDEAD

is there any chance to find out with Windbg, which device it is?

I can delete it in DSDT and check then, if all works

let's try with improved debug logging:

1) back to lite debug mode ed Kd_ACPI_Mask 0xFFFFFFFF
2) patch amliapi.c to partialy enable full debug lines:

Quote

      #ifdef DEBUGGER
        if (gDebugger.dwfDebugger & DBGF_VERBOSE_ON)
        {
            PRINTF(MODNAME ": %p: AsyncEvalObject(%s)\n",
                   KeGetCurrentThread(), GetObjectPath(pns));
        }
      #endif

to:

Quote

      //#ifdef DEBUGGER
        if (1)
        {
            PRINTF(MODNAME ": %p: AsyncEvalObject(%s)\n",
                   KeGetCurrentThread(), GetObjectPath(pns));
        }
      //#endif

Now you must get many "AMLI: xxxxx: AsyncEvalObject(\_SB.PC00.MC._ADR)" in lite debuglog, probably it will point to exact dsdt place before BSOD, as i understand we look for definition with bugged/missed _UID

Edited by Mov AX, 0xDEAD
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...