Dietmar

@LanXing Make try to disable something like "thermal zone" in Bios and try acpi.sys V4 again Dietmar PS: I just take a look into the DSDT table from my Asus ROG STRIX B450-F GAMING II board. There is no device TZ10.

@LanXing The Bsod 0x000000A5 (0x00000003, xxx, 0xC0000034, yyy) happens in acpi.sys, when ACPIBuildCompleteMustSucceed fails. We need a log file via Windbg, to find the reason for this. A first check with Ida Pro shows this error 0xC0000034 at 11 different places, always with mov ..., C0000034 Dietmar

@Andalu There is also USB debug for XP. All try to mix USB with Lan is waste of time Dietmar

@genieautravail Make try with to disable the HD3000 in Bios. BUT may be risk, if the other graphikscard does not work at all, that you dont see anything on screen from the moment(!) when you disable HD3000 in Bios Dietmar

@Mov AX, 0xDEAD Until now, I do not find a single board, where acpi.sys V4 does not work and full XP SP3 installation. But I have not tested all because of small time Dietmar

@Damnation The link for the Source file of your new acpi.sys V4 for bit64 is broken. Can you upload it on ufile.io again Dietmar

@George King @Mov AX, 0xDEAD I build acpi.sys V4 also without the _OSI modd, but now I test "full" acpi.sys V4 Dietmar PS: I think, this acpi error is different from all the others. It appears first time on all >= Skylake boards when using asl.exe for loading a DSDT table to Bios. Very easy way but this special Bsod destroys until now its possibility for to use with sense. Here is the loong output, about 1 Mbyte. I load new version up because it is better readable ottoASL5.7z

@Mov AX, 0xDEAD Just now I am prepairing the loong !amli output and hope, that it says something to you Dietmar

But a quick test with Windbg and the debug version of acpi.sys V4 shows something other Dietmar Break instruction exception - code 80000003 (first chance) nt!DbgBreakPoint: 80ac37e0 cc int 3 kd> g MM: Loader/HAL memory block indicates large pages cannot be used for 80100000->8012777F MTRR feature disabled. KiInitializeMTRR: OS support for MTRRs disabled KiInitializeMTRR: OS support for MTRRs disabled KiInitializeMTRR: OS support for MTRRs disabled KiInitializeMTRR: OS support for MTRRs disabled KiInitializeMTRR: OS support for MTRRs disabled KiInitializeMTRR: OS support for MTRRs disabled KiInitializeMTRR: OS support for MTRRs disabled KiInitializeMTRR: OS support for MTRRs disabled KiInitializeMTRR: OS support for MTRRs disabled KiInitializeMTRR: OS support for MTRRs disabled KiInitializeMTRR: OS support for MTRRs disabled KiInitializeMTRR: OS support for MTRRs disabled *** Assertion failed: (Pfn1->u3.e2.ReferenceCount != 0) || ((Pfn1->u3.e1.Rom == 1) && (CacheType == MmCached)) *** Source File: d:\xpsp\base\ntos\mm\iosup.c, line 6745 Break repeatedly, break Once, Ignore, terminate Process, or terminate Thread (boipt)? i i *** Assertion failed: (Pfn1->u4.PteFrame == MI_MAGIC_AWE_PTEFRAME) || (Pfn1->PteAddress == (PVOID) (ULONG_PTR)(X64K | 0x1)) || (Pfn1->u4.PteFrame == MI_MAGIC_4GB_RECLAIM) *** Source File: d:\xpsp\base\ntos\mm\iosup.c, line 6810 Break repeatedly, break Once, Ignore, terminate Process, or terminate Thread (boipt)? i i *** Fatal System Error: 0x000000a5 (0x00000003,0x314C5054,0xC0140004,0x494E495F) 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 XP 2600 x86 compatible target at (Sun Apr 24 23:33:12.187 2022 (UTC + 2:00)), ptr64 FALSE Loading Kernel Symbols ................................................ Loading User Symbols ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck A5, {3, 314c5054, c0140004, 494e495f} Probably caused by : ACPI.sys ( ACPI!ACPIBuildCompleteMustSucceed+43 ) Followup: MachineOwner --------- nt!RtlpBreakWithStatusInstruction: 80ac37ec cc int 3 2: 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: 00000003, 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: 314c5054, The ACPI Object that was being run Arg3: c0140004, return value from the interpreter Arg4: 494e495f, Name of the control method (in ULONG format) Debugging Details: ------------------ ACPI_OBJECT: 314c5054 DEFAULT_BUCKET_ID: DRIVER_FAULT BUGCHECK_STR: 0xA5 PROCESS_NAME: System ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) x86fre LAST_CONTROL_TRANSFER: from 80a30d7b to 80ac37ec STACK_TEXT: b8583858 80a30d7b 00000003 b8583bb4 00000000 nt!RtlpBreakWithStatusInstruction b85838a4 80a319e6 00000003 8b15c888 8b113000 nt!KiBugCheckDebugBreak+0x19 b8583c84 80a31f77 000000a5 00000003 314c5054 nt!KeBugCheck2+0x574 b8583ca4 b7e3f953 000000a5 00000003 314c5054 nt!KeBugCheckEx+0x1b b8583cc0 b7e65fdd 8b1bba20 c0140004 00000000 ACPI!ACPIBuildCompleteMustSucceed+0x43 [c:\nt\base\busdrv\acpi\driver\nt\buildsrc.c @ 433] b8583cf8 b7e63e3d b7e3f910 c0140004 00000000 ACPI!AsyncCallBack+0xe5 [c:\nt\base\busdrv\acpi\driver\amlinew\sync.c @ 82] b8583d1c b7e66dbb c0140004 4556414c 8b113000 ACPI!RunContext+0x1f5 [c:\nt\base\busdrv\acpi\driver\amlinew\ctxt.c @ 649] b8583d44 b7e66ee7 8b113000 00000000 b7e85408 ACPI!InsertReadyQueue+0x15a [c:\nt\base\busdrv\acpi\driver\amlinew\sched.c @ 275] b8583d64 b7e57fdf 8b15b468 00000000 8b272020 ACPI!RestartCtxtPassive+0x54 [c:\nt\base\busdrv\acpi\driver\amlinew\sched.c @ 384] b8583dac 80bd81ac 00000000 00000000 00000000 ACPI!ACPIWorker+0xbf [c:\nt\base\busdrv\acpi\driver\nt\worker.c @ 302] b8583ddc 80ae4212 b7e57f20 00000000 00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16 STACK_COMMAND: kb FOLLOWUP_IP: ACPI!ACPIBuildCompleteMustSucceed+43 [c:\nt\base\busdrv\acpi\driver\nt\buildsrc.c @ 433] b7e3f953 c7401802000000 mov dword ptr [eax+18h],2 FAULTING_SOURCE_LINE: c:\nt\base\busdrv\acpi\driver\nt\buildsrc.c FAULTING_SOURCE_FILE: c:\nt\base\busdrv\acpi\driver\nt\buildsrc.c FAULTING_SOURCE_LINE_NUMBER: 433 FAULTING_SOURCE_CODE: 429: // Note: we don't have a race condition here because only one 430: // routine can be processing a request at any given time. Thus it 431: // is safe for us to specify a new next phase 432: // > 433: buildRequest->NextWorkDone = WORK_DONE_FAILURE; 434: 435: // 436: // Transition to the next stage 437: // 438: ACPIBuildCompleteCommon( SYMBOL_STACK_INDEX: 4 SYMBOL_NAME: ACPI!ACPIBuildCompleteMustSucceed+43 FOLLOWUP_NAME: MachineOwner MODULE_NAME: ACPI IMAGE_NAME: ACPI.sys DEBUG_FLR_IMAGE_TIMESTAMP: 626570df IMAGE_VERSION: 5.1.2600.7777 FAILURE_BUCKET_ID: 0xA5_ACPI!ACPIBuildCompleteMustSucceed+43 BUCKET_ID: 0xA5_ACPI!ACPIBuildCompleteMustSucceed+43 ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:0xa5_acpi!acpibuildcompletemustsucceed+43 FAILURE_ID_HASH: {5ff4cd30-9433-c4e0-8096-0615b3b5c98a} Followup: MachineOwner ---------

I just make the test for the new acpi.sys V4 and asl.exe version 5. I change the DSDT table on the Asrock z370 gaming k6 board against its own(!) one. But on next reboot I got this Bsod which looks very similar to the famous 0x7E(c0000005, ...) error in AcpiArbCrackPRT() Dietmar

There is another interesting thing, what can be tested with the new acpi.sys V4. I remember, that on newer DSDT table, before with acpi.sys version 6666 I got Bsod when I load this acpi table via asl /loadtable dsdt.aml Before, the asl Tool vers 4 or vers 5 fails with BSOD 0x000000A5 (0x00000003, xxx, C0140001, yyy) after uploading a working DSDT table for Acpi. Always when you load a DSDT table via asl /loadtable from Skylake above you get this Bsod with acpi.sys 6666. When this Bsod can be solved, it will be much more easy to upload any DSDT table to XP, because XP SP3 listens to registry entry for DSDT (or FACP etc.). Winserver 2003 listens only to Bios DSDT. Dietmar

@daniel_k Can you remember, for the acpi.sys version 6666 you make different kind of Win versions hack (1, 2, 3, 4). Do you know, which was the best acpi.sys 6666 from those tests Dietmar

@daniel_k With your modd about to fake the Win version, via acpi.sys V4 now on my Asrock z370 gaming k6 is a new acpi device found, which I never saw before Dietmar PS: Its name is ACPI\INT33A1\1 which is first used in win8.1 as Intel(R) Core(TM) 4xxxU and 4xxxY Processor Line Power Engine Plug-in

@Andalu @Mov AX, 0xDEAD Here are both new acpi.sys V4 free and debug version Dietmar https://ufile.io/zd0szbk1

@Andalu Here is the fresh modded free acpi.sys V4 with patch from @Mov AX, 0xDEAD and @daniel_k this time without any binary hack ) Dietmar https://ufile.io/34t1pgp7

I just notice, that with the new Quantum browser 68.12.2b download and upload on XP SP3 are about 6% faster than with Firefox 52.9.0 . Ping is the same Dietmar

@Damnation Thanks for the tip ). Here is answer from Intel about the Intel X540-T2 10Gigabit Dietmar The X540 uses an automatic MDI/MDI-X configuration. Intel recommends using straight through cables. Where crossover cables are used, all four pairs must be crossed. Using crossover cables where only some pairs are crossed is not supported and might result in link failure or slow links.

@Mov AX, 0xDEAD How big can the parts from a real DSDT be, that you can integrate in the DSDT from Qemu, so that Qemu still works? Have you tested this? And gives Qemu the same Bsod about failed to build DDB, when you run it with a zero size buffer in its given DSDT on a XP SP3 guest (Target) Dietmar

I just ordered 2 used Intel X540-T2 10Gigabit lan cards, Dev_1528 . It has 2 RJ45 connectors each. They have driver for win2003 Bit32 and Bit64 and work with driver from 2 March 2013 under XP and ndis.sys V5 as a check with Dependency Walker tells me. Dont know, if for a short direct connection compi to compi with cable of 2m you need Cat6 cable, hope not Dietmar EDIT: The X540-T2 with Dev_1528 is also supported in Windbg Ethernet NICs for Network Kernel Debugging in Windows 8.1 . https://www.hardware-mag.de/artikel/sonstiges/asus_und_intel_10_gbits_netzwerkkarten_im_test/

@Mov AX, 0xDEAD How did you use Qemu with an outstanding DSDT? Tutorial would be soso nice Dietmar

@Damnation Yepp, about error in DDB and Variable mismatch Dietmar

@Damnation Hi, your nice acpi.sys V2 compiled from Sources for XP bit 64 works also via install on the Asrock z370 gaming k6 board under XP bit64 SP1 Dietmar

@Andalu I think, that this is not a good idea. Soon you forget, which are your newest files for Windbg Dietmar

@Andalu You have to add for your Symbol path also your old path .symfix+ W:\Symbols .reload /f and .symfix+ W:\Symbols1 .reload /f Dietmar

@Andalu Then type on running Windbg at commandline .symfix+ W:\Symbols1 .reload /f !sym noisy Dietmar PS: The "+" adds an extra path for new Symbols. If you use it without the "+", your whole path to Symbols is set new.