Dietmar

@Andalu This is the normal break of windbg, for to have a fixed start point. Now you only need to hit "g" in commandline. Later, may be you have to hit "i" again and again, this means nothing. Then you should come to desktop. After this, install without windbg (just use 1. setting in boot,ini) the Nvidia driver. And then use windbg again. Windbg should show to you, which device makes the 7F Bsod Dietmar EDIT: I think, that the command ed Kd_ACPI_Mask 0x7FFFFFFF works only with the debug version of acpi.sys. At the moment, use the normal free acpi.sys because I think, that the error is not acpi related. And that there is no aquivalent for nvme.

@Andalu Use the original ISO XP and set up there ntos3.exe and hal3.dll for a debug session. Check, if windbg runs without problem. Then install the graphikdriver and run windbg for to fetch the 7F Bsod Dietmar

@Andalu Make sure, that you use the latest acpi.sys Dietmar acpi.sys free and debug laast V7 with OSfake https://ufile.io/trphcl2x

@Andalu I have this crazy Bsod with 7F also sometimes after installing the nvidia graphikcard. May be, that there is an ressources conflict. For to check this, set up a minimal XP SP3, only with the drivers which you want to test. Disable everything other in Bios and in Device Manager. And then hit just "g" after breakpoint for to see, which driver gives this Bsod Dietmar

@Andalu Set up all new. Take my files (Symbols, ntos3, hal3), which I send. They work Dietmar

@Andalu And here are all the needed files for DEBUG via an Realtek Lan-card Dietmar https://ufile.io/jcyqmz5p

@Andalu May be, that you have installed a wrong version for the Symbols. Then, ntkrpamp of course will never been found. You can use both, free and debug Symbols, in different folders. XP SP3 takes then always the correct one. I think, I am right. You use the free Symbols as I can see at your log. But you need the Debug Symbols. "Windows XP Kernel Version 2600 (Service Pack 3) MP (4 procs) Free x86 compatible" Dietmar Here are my working Symbols for ntos3.exe https://ufile.io/fu5zpo53

@Andalu I just test the idea from @Mov AX, 0xDEAD for to find the path, where windbg is looking for ntkrpamp. For this, I run a windbg session with Host and Guest via Lan and stop at the first breakpoint. The last version of Process Monitor, that runs under XP is 3.61 Dietmar

@Andalu I would set up everything with windbg brandnew Dietmar

@Andalu You have to jump at the driverentry of this driver, exact as for acpi.sys. Then you can trace this driver with hitting t again and again. Also you can check via analyze -v after crash Dietmar EDIT: Sometimes, windbg does not stop at driverentry, even you set a breakpoint there. Then you can use the trick from @Mov AX, 0xDEAD : Change first 2 Bytes in "your driver" at adress driverentry to EB FE via Ida Pro and Winhex. This gives an endless loop. When you hit then "break" in windbg, the compi stops exact at this driverentry. In memory you have to change then back the EB FE to its original values from this driver and hit t again and again.

@George King Yepp, this is the original OS fake for xp SP3 from @daniel_k, integrated in new acpi.sys via Source code Dietmar

@Mov AX, 0xDEAD @Damnation @PPeti66x Here is the original and the modded Source file type2op.c for to fake OS from @daniel_k . May be, that this is a little bit too much Dietmar https://ufile.io/2bynpi8j

@Damnation @PPeti66x Here is the fresh compiled free version of last acpi.sys v7 from @Mov AX, 0xDEAD, compiled with the OS fakes from @daniel_k good luck Dietmar https://ufile.io/e6559bso @Dave-H make try with this acpi.sys on the Flex10.

@Mov AX, 0xDEAD Waaooh , power consumption with 0% load goes down to 1.4 Watt with the new acpi.sys v7 on the 12900k cpu Dietmar EDIT: I test this on the Gigabyte Z690 UD DDR4 with 12900k cpu and 32 Gb ram. With its new Bios version F22 this is a very nice board for XP SP3.

@Mov AX, 0xDEAD For me, the new acpi.sys v7 works on z690 boards Dietmar

@Mov AX, 0xDEAD @Damnation Here is the fresh compiled free acpi.sys v7 for XP SP3 Dietmar https://ufile.io/dhg4dbtj and here is the Debug version of acpi.sys v7 for XP SP3 https://ufile.io/arco37sf

@Mov AX, 0xDEAD I change in acpi only the files in driver from the original acpi XP SP1 Source files against yours. This seems to work Dietmar https://ufile.io/gluf73e7 EDIT: @Damnation tells me, that it gives the same Bsod A5 (0x11,0x08,..) as the acpi.sys before. Because I set back in Source files all to the acpi.sys version before, let only the new 0007 definition, the double name in DSDT, SSDT1 of processor may be the reason on AMD boards. On all of my z690 boards also my acpi.sys creation above works. I noticed, that I get the same Bsod, when I modd my DSDT on any z690 board to the old processor definition together with the new acpi.sys. This is true for any of the new 0007 acpi.sys.

@Andalu Why you make yourself such a lot of stress: Rescue old acpi.sys and old acpi.pdb. And then, just put new debug acpi.sys and its acpi.pdb at its place Dietmar

@Andalu So just change the debug acpi.sys and debug acpi.pdb at the place on the host system, where it works last time Dietmar

@Andalu The only idea that I have, is to put the debug acpi.sys and its debug acpi.pdb in W:\Symbols2 also Dietmar EDIT: And delete my path (whole folder) C:\NT\base..

@Mov AX, 0xDEAD Before, I always updated my acpi files by hand. This time for the first I use your patch. I noticed, that in bus.c you changed in status = PnpBiosResourcesToNtResources( ASSERT(NT_SUCCESS(status)); ==> //ASSERT(NT_SUCCESS(status)); Dietmar

@Andalu Put the new debug acpi.sys and its acpi.pdb into your folder W:\Symbols4 . This is my way Dietmar

@Andalu I think, that the problem is the double definition of a lot of devices in DSDT as @canonkong noticed. So, win7 gives the same Bsod. We can write a hack for this but better solution is a debug LOG, what is exact going on Dietmar

@Damnation Here is the fresh from @Mov AX, 0xDEAD via Patch compiled by me, acpi.sys v6 and its acpi.pdb for XP SP3 Dietmar https://ufile.io/6iesmav8 and here its Debug version https://ufile.io/7kciqjd2

@un user I have a german SP1 XP CD Pro. This CD I updated with the Service Packs to SP3. During such a lot of tests I noticed, that any XP build with this CD is more stable than with its german original XP SP3 CD Dietmar