Dietmar

@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.

@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

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 . So it is only a 12 hours time loss, brr..

@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

@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

@Mov AX, 0xDEAD Of course I want to make this work! Wish you a lot of power and good night Dietmar

@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.

@Mov AX, 0xDEAD Do you think, that the last device \_SB.PC00.I2C0.HDAC._HID makes the crash? In the Bsod you can see, that it is indeed an _HID so it may be Dietmar PS: The exact number FFFFFADCE4CB5C30 cant be found in Log file.

@Mov AX, 0xDEAD This one works, crazy. Here is LOG file Dietmar https://ufile.io/sc2amqfy AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.CLP3._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.CLP4._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.CLP5._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.LNK0._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.LNK1._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.LNK2._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.LNK3._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.LNK4._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.LNK5._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.FLM0._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.FLM1._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.FLM2._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.FLM3._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.FLM4._HID) AMLI: FFFFFADCE4E65810: AsyncEvalObject(\_SB.PC00.FLM5._HID) 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) A fatal system error has occurred. Debugger entered on first try; Bugcheck callbacks have not been invoked. A fatal system error has occurred. Connected to Windows Server 2003 3790 x64 target at (Sun Jan 1 23:46:18.078 2023 (UTC + 1:00)), ptr64 TRUE Loading Kernel Symbols ............................ Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long. Run !sym noisy before .reload to track down problems loading symbols. ... Loading User Symbols ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck A5, {3, fffffadce4cb5c30, ffffffffc0000034, 4449485f} Probably caused by : ACPI.sys ( ACPI!ACPIBuildCompleteMustSucceed+39 ) Followup: MachineOwner --------- nt!RtlpBreakWithStatusInstruction: fffff800`01026cf0 cc int 3 22: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* ACPI_BIOS_ERROR (a5) The ACPI Bios in the system is not fully compliant with the ACPI specification. The first value indicates where the incompatibility lies: This bug check covers a great variety of ACPI problems. If a kernel debugger is attached, use "!analyze -v". This command will analyze the precise problem, and display whatever information is most useful for debugging the specific error. Arguments: Arg1: 0000000000000003, ACPI_FAILED_MUST_SUCCEED_METHOD ACPI tried to run a control method while creating device extensions to represent the ACPI namespace, but this control method failed. Arg2: fffffadce4cb5c30, The ACPI Object that was being run Arg3: ffffffffc0000034, return value from the interpreter Arg4: 000000004449485f, Name of the control method (in ULONG format) Debugging Details: ------------------ ACPI_OBJECT: fffffadce4cb5c30 DEFAULT_BUCKET_ID: DRIVER_FAULT BUGCHECK_STR: 0xA5 PROCESS_NAME: System CURRENT_IRQL: 2 ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) x86fre LAST_CONTROL_TRANSFER: from fffff800010d668e to fffff80001026cf0 STACK_TEXT: fffffadc`c400e4c8 fffff800`010d668e : 00000000`00000016 00000000`00000000 00000000`00000003 fffff800`010565ce : nt!RtlpBreakWithStatusInstruction fffffadc`c400e4d0 fffff800`010d7c5e : fffff800`00000003 00000000`000000a5 00000000`00000003 fffffadc`e4cb5c30 : nt!KiBugCheckDebugBreak+0x1e fffffadc`c400e530 fffff800`0102e994 : 00000000`c0000034 fffffadc`e3d52000 00000000`00000000 fffffadc`c3562d6d : nt!KeBugCheck2+0x640 fffffadc`c400eb70 fffffadc`c3548109 : 00000000`000000a5 00000000`00000003 fffffadc`e4cb5c30 ffffffff`c0000034 : nt!KeBugCheckEx+0x104 fffffadc`c400ebb0 fffffadc`c3555f4d : 00000000`c0000034 fffffadc`e3d52000 fffffadc`e3d521c8 00000000`00000000 : ACPI!ACPIBuildCompleteMustSucceed+0x39 [c:\acpi\acpi_w2003\base\busdrv\acpi\driver\nt\buildsrc.c @ 422] fffffadc`c400ebf0 fffffadc`c35673df : fffffadc`e3d52000 00000000`00000000 00000000`00008004 00000000`c0000034 : ACPI!ACPIGetWorkerForString+0x29d [c:\acpi\acpi_w2003\base\busdrv\acpi\driver\nt\get.c @ 5806] fffffadc`c400ec40 fffffadc`c3565eb7 : fffffadc`e3d52000 00000000`00000000 00000000`00008004 00000000`c0000034 : ACPI!AsyncCallBack+0x7f [c:\acpi\acpi_w2003\base\busdrv\acpi\driver\amlinew\sync.c @ 85] fffffadc`c400ec70 fffffadc`c3565472 : fffffadc`e3d52000 fffffadc`c357d0c0 fffffadc`c357d100 00000000`00000000 : ACPI!RunContext+0x147 [c:\acpi\acpi_w2003\base\busdrv\acpi\driver\amlinew\ctxt.c @ 649] fffffadc`c400eca0 fffffadc`c3565518 : 00000000`00000000 00000000`00000000 fffffadc`e3e72170 00000000`00000000 : ACPI!InsertReadyQueue+0xd2 [c:\acpi\acpi_w2003\base\busdrv\acpi\driver\amlinew\sched.c @ 278] fffffadc`c400ecd0 fffffadc`c3560a45 : 52025202`00000002 7c0d7c0d`7c0d7c0d fffffadc`00000001 fffffadc`00000000 : ACPI!RestartCtxtPassive+0x28 [c:\acpi\acpi_w2003\base\busdrv\acpi\driver\amlinew\sched.c @ 384] fffffadc`c400ed00 fffff800`0124a982 : 58de58de`5ade58de fffffadc`e4e65810 00000000`00000080 fffffadc`e4e65810 : ACPI!ACPIWorker+0xe5 [c:\acpi\acpi_w2003\base\busdrv\acpi\driver\nt\worker.c @ 325] fffffadc`c400ed70 fffff800`01020226 : fffffadc`c3bbb180 fffffadc`e4e65810 fffffadc`c3bc3680 00000000`00000000 : nt!PspSystemThreadStartup+0x3e fffffadc`c400edd0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxStartSystemThread+0x16 STACK_COMMAND: kb FOLLOWUP_IP: ACPI!ACPIBuildCompleteMustSucceed+39 [c:\acpi\acpi_w2003\base\busdrv\acpi\driver\nt\buildsrc.c @ 422] fffffadc`c3548109 cc int 3 FAULTING_SOURCE_LINE: c:\acpi\acpi_w2003\base\busdrv\acpi\driver\nt\buildsrc.c FAULTING_SOURCE_FILE: c:\acpi\acpi_w2003\base\busdrv\acpi\driver\nt\buildsrc.c FAULTING_SOURCE_LINE_NUMBER: 422 FAULTING_SOURCE_CODE: No source found for 'c:\acpi\acpi_w2003\base\busdrv\acpi\driver\nt\buildsrc.c' SYMBOL_STACK_INDEX: 4 SYMBOL_NAME: ACPI!ACPIBuildCompleteMustSucceed+39 FOLLOWUP_NAME: MachineOwner MODULE_NAME: ACPI IMAGE_NAME: ACPI.sys DEBUG_FLR_IMAGE_TIMESTAMP: 63b1fbf8 IMAGE_VERSION: 5.2.3790.7777 FAILURE_BUCKET_ID: X64_0xA5_ACPI!ACPIBuildCompleteMustSucceed+39 BUCKET_ID: X64_0xA5_ACPI!ACPIBuildCompleteMustSucceed+39 ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:x64_0xa5_acpi!acpibuildcompletemustsucceed+39 FAILURE_ID_HASH: {fe462e3b-bd12-a13c-a95f-bb49a4eb48bc} Followup: MachineOwner ---------

@Mov AX, 0xDEAD Can you send me an amliapi.c for XP 64bit , that works with a lot of output for free and debug acpi.sys Dietmar

@Mov AX, 0xDEAD My compi (host, where windbg runs) is XP SP3 (with 64bit acpi.sys and its acpi.pdb for windbg) The compi (guest) is the compi with crashing XP 64 SP2 (with the same acpi.sys for XP 64 as driver) Dietmar

@Mov AX, 0xDEAD I did. It is to 100% ok. Here it is https://ufile.io/kquwi940

@Mov AX, 0xDEAD Oha, I see what happens. I always write bu acpi!DriverEntry g ed Kd_ACPI_Mask 0xFFFFFFFF g But you hit only "g" after acpi driverentry, no ed KD_acpi.. at all Dietmar

@Mov AX, 0xDEAD The DEBUG acpi.sys tells this in Windbg (hits Breakpoint 0x7E (0x80000003, xxx, yyy) because of this) *** 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

I see my error in amliapi.c Dietmar EDIT: Still no output of any device as for example "AMLI: xxxxx: AsyncEvalObject(\_SB.PC00.MC._ADR)" Dietmar Here is log, same as before https://ufile.io/ygxv73fs EDIT: Even I mod amliapi.c at all 6 places (where "verbose" is), still no output of any device as "AMLI: xxxxx: AsyncEvalObject(\_SB.PC00.MC._ADR)" Dirty hack in Source Code in buildsrc.c @ 422 just change against "If (0)" (lets acpi always fullfilled) also does not help. Then comes the Bsod 0xA, as also in hack of acpi.sys direct. Because the DEBUG acpi.sys works, we only need to put away the Breakpoint for Windbg 0x7E (0x80000003, xxx, yyy) but no idea how this can be done.

@Mov AX, 0xDEADI build new acpi.sys for XP 64 DEBUG with new amliapi.c . But the result looks nearly exakt as from first acpi.sys without !amli set spewon verboseon logon traceon . Please take a look at my for the DEBUG acpi.sys modded amliapi.c vs amliapimodd.c Dietmar Here is the Log file https://ufile.io/rlym0sum and here are the amliapi https://ufile.io/aqp93q0t

@Mov AX, 0xDEAD The Bsod happens mostly with the free version of acpi.sys of XP bit64. Does it make sense, to edit amliapi.c the same way also for the free acpi.sys, or is there another way to bring the free acpi.sys to give more output Dietmar

@Mov AX, 0xDEAD Just now I make a new try: I use the free ntoskrnl, the free hal.dll but still the DEBUG acpi.sys Dietmar PS: Output is different.

@Mov AX, 0xDEAD Hihi, 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 Dietmar

@Mov AX, 0xDEAD It looks, as if the acpi debug output itself hangs Dietmar PS: Now, compi crashes. This is last output https://ufile.io/9e7q4ho9

@Mov AX, 0xDEAD I can edit the DSDT (for example kill all USB) as much as I want from this Gigabyte UD z690 DDR4 board, because it has Bios Flashback. Here is its DSDT Dietmar https://ufile.io/foslv00u

@Mov AX, 0xDEAD Here is the loong log file (until now). I am still in the running Windbg but dont know what to do. It looks, as if it hangs because of xhci (USB3) definition in DSDT Dietmar https://ufile.io/rwe6pkdz

@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

@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

@Mov AX, 0xDEAD I am still in running Windbg. There is an endless loop, any idea how I can reset this Interrupt, can this be the reason for Bsod Dietmar 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 | | | | | 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 | | | | | 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