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

@Mov AX, 0xDEAD 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 https://ufile.io/clb68gcr

@Mov AX, 0xDEAD This is with free acpi.sys for XP bit64, free ntoskrnl.exe and free hal.dll Dietmar Windows Server 2003 Kernel Version 3790 MP (1 procs) Free x64 Built by: 3790.srv03_sp2_gdr.130306-1435 Machine Name: Kernel base = 0xfffff800`01000000 PsLoadedModuleList = 0xfffff800`011d4140 System Uptime: not available ************* Symbol Path validation summary ************** Response Time (ms) Location OK C:\symbolssss Deferred srv* ************* Symbol Path validation summary ************** Response Time (ms) Location OK C:\localsymbols ************* Symbol Path validation summary ************** Response Time (ms) Location Deferred srv* *** Fatal System Error: 0x000000a5 (0x0000000000000003,0xFFFFFADCE4CB9C30,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 03:07:08.453 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, fffffadce4cb9c30, 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: fffffadce4cb9c30, 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: fffffadce4cb9c30 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`e4cb9c30 : nt!KiBugCheckDebugBreak+0x1e fffffadc`c400e530 fffff800`0102e994 : 00000000`c0000034 fffffadc`e3d63000 00000000`00000000 fffffadc`c3562d2d : nt!KeBugCheck2+0x640 fffffadc`c400eb70 fffffadc`c35480f9 : 00000000`000000a5 00000000`00000003 fffffadc`e4cb9c30 ffffffff`c0000034 : nt!KeBugCheckEx+0x104 fffffadc`c400ebb0 fffffadc`c3555ecd : 00000000`c0000034 fffffadc`e3d63000 fffffadc`e3d631c8 00000000`00000000 : ACPI!ACPIBuildCompleteMustSucceed+0x39 [c:\win2k3\nt\base\busdrv\acpi\driver\nt\buildsrc.c @ 422] fffffadc`c400ebf0 fffffadc`c356739f : fffffadc`e3d63000 00000000`00000000 00000000`00008004 00000000`c0000034 : ACPI!ACPIGetWorkerForString+0x29d [c:\win2k3\nt\base\busdrv\acpi\driver\nt\get.c @ 5806] fffffadc`c400ec40 fffffadc`c3565e77 : fffffadc`e3d63000 00000000`00000000 00000000`00008004 00000000`c0000034 : ACPI!AsyncCallBack+0x7f [c:\win2k3\nt\base\busdrv\acpi\driver\amlinew\sync.c @ 85] fffffadc`c400ec70 fffffadc`c3565432 : fffffadc`e3d63000 fffffadc`c357d0c0 fffffadc`c357d100 00000000`00000000 : ACPI!RunContext+0x147 [c:\win2k3\nt\base\busdrv\acpi\driver\amlinew\ctxt.c @ 649] fffffadc`c400eca0 fffffadc`c35654d8 : 00000000`00000000 00000000`00000000 fffffadc`e3e73240 00000000`00000000 : ACPI!InsertReadyQueue+0xd2 [c:\win2k3\nt\base\busdrv\acpi\driver\amlinew\sched.c @ 278] fffffadc`c400ecd0 fffffadc`c35609e5 : 5ab75ab7`00000002 1a761a76`1a761a76 fffffadc`00000001 fffffadc`00000000 : ACPI!RestartCtxtPassive+0x28 [c:\win2k3\nt\base\busdrv\acpi\driver\amlinew\sched.c @ 384] fffffadc`c400ed00 fffff800`0124a982 : 8a5a8a5a`8a5a8a5a fffffadc`e67e3bf0 00000000`00000080 fffffadc`e67e3bf0 : ACPI!ACPIWorker+0xe5 [c:\win2k3\nt\base\busdrv\acpi\driver\nt\worker.c @ 325] fffffadc`c400ed70 fffff800`01020226 : fffffadc`c3bbb180 fffffadc`e67e3bf0 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:\win2k3\nt\base\busdrv\acpi\driver\nt\buildsrc.c @ 422] fffffadc`c35480f9 cc int 3 FAULTING_SOURCE_LINE: c:\win2k3\nt\base\busdrv\acpi\driver\nt\buildsrc.c FAULTING_SOURCE_FILE: c:\win2k3\nt\base\busdrv\acpi\driver\nt\buildsrc.c FAULTING_SOURCE_LINE_NUMBER: 422 FAULTING_SOURCE_CODE: No source found for 'c:\win2k3\nt\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: 63adcd5b 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 --------- 22: kd> lm start end module name fffff800`00800000 fffff800`0085e000 hal (deferred) fffff800`01000000 fffff800`01498000 nt (pdb symbols) C:\Programme\Windows Kits\8.1\Debuggers\x86\sym\ntkrnlmp.pdb\7C3C62B843A04B97A1FBEBC91C88CBFF2\ntkrnlmp.pdb fffffadc`c3144000 fffffadc`c3178000 Mup (deferred) fffffadc`c3178000 fffffadc`c31de000 NDIS (deferred) fffffadc`c31de000 fffffadc`c32e3000 Ntfs (deferred) fffffadc`c32e3000 fffffadc`c3317000 KSecDD (deferred) fffffadc`c3317000 fffffadc`c333a000 sr (deferred) fffffadc`c333a000 fffffadc`c3378000 fltMgr (deferred) fffffadc`c3378000 fffffadc`c3395000 CLASSPNP (deferred) fffffadc`c3395000 fffffadc`c33aa000 disk (deferred) fffffadc`c33aa000 fffffadc`c340d000 storport (deferred) fffffadc`c340d000 fffffadc`c343a000 atapi (deferred) fffffadc`c343a000 fffffadc`c3485000 volsnap (deferred) fffffadc`c3485000 fffffadc`c34cc000 dmio (deferred) fffffadc`c34cc000 fffffadc`c350c000 ftdisk (deferred) fffffadc`c350c000 fffffadc`c3522000 MountMgr (deferred) fffffadc`c3522000 fffffadc`c3543000 pci (deferred) fffffadc`c3543000 fffffadc`c3598000 ACPI (private pdb symbols) C:\Programme\Windows Kits\8.1\Debuggers\x86\sym\acpi.pdb\32E6A6AD68BF47258C44F2A0AC4B32961\acpi.pdb fffffadc`c3598000 fffffadc`c35b6000 amdhub30 (deferred) fffffadc`c35b6000 fffffadc`c35f2000 amdxhc (deferred) fffffadc`c36f3000 fffffadc`c3704000 USBSTOR (deferred) fffffadc`c3706000 fffffadc`c3718000 storahci (deferred) fffffadc`c39fb000 fffffadc`c3a05000 kdcom (deferred) fffffadc`c3a0b000 fffffadc`c3a14000 BOOTVID (deferred) fffffadc`c3a1b000 fffffadc`c3a24000 WMILIB (deferred) fffffadc`c3a2b000 fffffadc`c3a34000 isapnp (deferred) fffffadc`c3a3b000 fffffadc`c3a4b000 PCIIDEX (deferred) fffffadc`c3a4b000 fffffadc`c3a5b000 PartMgr (deferred) fffffadc`c3a5b000 fffffadc`c3a66000 crcdisk (deferred) fffffadc`c3dfb000 fffffadc`c3e02000 pciide (deferred) fffffadc`c3e02000 fffffadc`c3e09000 dmload (deferred) fffffadc`c41a7000 fffffadc`c41a8e00 USBD (deferred)

@Mov AX, 0xDEAD I succeed to install working Windbg via COM1 on the nice Gigabyte UD z690 DDR4 board with 12900k cpu under XP 64bit SP2. Before it was not possible to start any windbg session on this board, but with the brandnew Bios from this December suddently its integrated COM1 port works! Crash, crash, crash via 0xA5 (0x03, yyy, 0xFFFFFFFFC0000034, 0x000000004449485F) . But now comes the most crazy thing: With the DEBUG acpi.sys it does not crash at all. This makes examination much harder what is going on with the normal acpi.sys Dietmar

@Mov AX, 0xDEAD The last numbers in x64 Bsod on the Asrock z690 Extreme board I translate Hex ==> Asci 0x000000004449485F ==> _HID this is the crash maker in DSDT. But the Hex number before give no sense 0xFFFFFADCE50B4ED8 ==> ÿÿúÜå NØ ??? I think, that it is a HEX pointer. Whole Bsod in x64 is 0x000000A5 (0x0000000000000003, 0xFFFFFADCE50B4ED8, 0xFFFFFFFFC0000034, 0x000000004449485F) Dietmar EDIT: I just noticed, that this is a new acpi Bsod. Until now, we never see an acpi Bsod in XP via _HID ( 0x000000004449485F ) or ( 0x4449485F ) . Interesting, that XP SP3 gives there no Bsod, only x64. So, this critical device with _HID must be treated different under acpi in XP SP3 and x64. Here is the DSDT for this board. https://ufile.io/ijhcnlbg

@Mov AX, 0xDEAD This are the 31 places of 0xC0000034 in the x64 acpi.sys, build from your original last Sources Dietmar .text:0000000000018E9E ACPIBuildProcessorExtension mov eax, 0C0000034h .text:00000000000228FB ACPIGetConvertToDevicePresence cmp edx, 0C0000034h .text:000000000002299B ACPIGetConvertToDevicePresence cmp edx, 0C0000034h .text:000000000002320D ACPIGet mov eax, 0C0000034h .text:0000000000025EE0 AcpiArbSetLinkNodeIrqWorker mov ebx, 0C0000034h .text:0000000000026A05 AcpiArbCrackPRT cmp ebx, 0C0000034h .text:0000000000026A43 AcpiArbCrackPRT mov ebx, 0C0000034h .text:0000000000027E75 IsPciDeviceWorker cmp edi, 0C0000034h .text:0000000000028A5C IsPciBusAsyncWorker cmp edi, 0C0000034h .text:000000000002A12E ACPISystemPowerUpdateWakeCapabilitiesForFilters cmp eax, 0C0000034h .text:000000000002A163 ACPISystemPowerUpdateWakeCapabilitiesForFilters cmp r11d, 0C0000034h .text:000000000002A2A5 ACPISystemPowerUpdateWakeCapabilitiesForFilters cmp eax, 0C0000034h .text:000000000002A4EB ACPISystemPowerDetermineSupportedDeviceStates cmp eax, 0C0000034h .text:000000000002A537 ACPISystemPowerDetermineSupportedDeviceStates cmp ebp, 0C0000034h .text:000000000002AB97 ACPISystemPowerUpdateDeviceCapabilities cmp eax, 0C0000034h .text:00000000000334F8 GetNameSpaceObject mov eax, 0C0000034h .text:00000000000335A9 GetNameSpaceObject mov eax, 0C0000034h .text:0000000000033620 GetNameSpaceObject mov eax, 0C0000034h .text:000000000003370F CreateNameSpaceObject cmp eax, 0C0000034h .text:00000000000378A1 ParseAndGetNameSpaceObject cmp eax, 0C0000034h .text:000000000003B2DC Load cmp eax, 0C0000034h PAGE:000000000004FF7A ACPIBusIrpQueryId cmp eax, 0C0000034h PAGE:000000000004FFC8 ACPIBusIrpQueryId cmp eax, 0C0000034h PAGE:0000000000050DA3 ACPIDetectCouldExtensionBeInRelation mov eax, 0C0000034h PAGE:0000000000051139 ACPIDetectFilterMatch cmp eax, 0C0000034h PAGE:0000000000055AA2 OSReadAcpiConfigurationData mov eax, 0C0000034h PAGE:000000000005905E ACPISystemPowerGetSxD cmp eax, 0C0000034h PAGE:0000000000059092 ACPISystemPowerGetSxD mov eax, 0C0000034h PAGE:000000000005919A ACPISystemPowerProcessSxD cmp r11d, 0C0000034h PAGE:00000000000591CC ACPISystemPowerProcessSxD cmp eax, 0C0000034h PAGE:000000000005AA7F ACPIDockIrpEject mov ebx, 0C0000034h

@Mov AX, 0xDEAD I just test: The Bsod 0x000000A5 (0x00000003, xxx, 0xC0000034, yyy) in 64bit version of XP happens already via Source Files from June 2022, so it has nothing to do with new acpi mod for 007 cpu definition Dietmar

@canonkong As I write above. This Bsod happens somewhere before Acpimustcomplete. When we substitute each of the 31(!) different 0xC0000034 with other number, we can catch the path this Bsod takes but not exact where Dietmar PS: I compare the Source Code in "Acpi" for XP SP3 and x64. May be, that at a place is a simple error, typo, that gives the result, that only 1 cpu is allowed. I found 2 missing "&", dont know if this means anything.

@Mov AX, 0xDEAD As careful as I can, I check the Acpi Bsod A5 (0x03,..) on the x64 acpi.sys on different z690 boards. When you integrate the switch /ONECPU into boot.ini this acpi.sys, build with exact your code, works without any hack. But as soon as you use more than 2 processors (1 core and 1 thread) you get this acpi Bsod from above. Because it use the same DSDT for XP SP3 and x64, there must be something, that gives this Bsod when you use more than 1 processor. Now the processors are used as normal devices and because of this there can be an A5 (0x03,..) Bsod because of their device definition, which crashes in bit64 but not in bit32 Dietmar 0x000000A5 (0x00000003, xxx, 0xC0000034, yyy) in 64bit version

@RandyOC /numproc=2 in boot.ini works also. This is one core with 2 threads. Hope, that we get solution. I test old acpi.sys for x64 also, everytime the same Bsod, first A5 (0x03,..) and after hack 0xA Dietmar

@canonkong Now I make a try with Bios Modd, because Bsod depends on number of processors Dietmar EDIT: Bios Modd for the old processor definition and old x64 acpi.sys gives exact the same Bsod 0xA.