UsefulAGKHelper

"last" Does this mean that you'll stop making new acpi.sys for Xp Sp2 64-bit? I hope not.

@Mov AX, 0xDEAD Regarding UEFI support for XP, I wonder if xp x64 ACPI.SYS can work on my ASUS x509fa, here's my DSDT: dsdt.aml

@reboot12 I have patched x64 vbemp vbe30 to fix a BSOD problem on XP x64. This particular bug no longer shows: Access violation - code c0000005 (!!! second chance !!!) vga+0x41ea: fffffadf`c8bff1ea 43c6041f3c mov byte ptr [r15+r11],3Ch Now it loads XP x64. I achieved this by editing hex "43c6041f3c" to "9090909090", and I refreshed the checksum. I haven't tested this patched vbemp driver on UEFI yet, so if you don't mind, can you please debug this on XP x64 from UEFI and send me the debug? I need to ensure that there aren't problems if used from UEFI mode (even tho 16497 winload.exe loads the display (no issues) thanks to this patched vbemp driver without guest additions). XPAMD64.zip

@Mov AX, 0xDEAD Out of curiosity, I wonder if you will implement ACPI v3.0 support for windows xp sp3 and windows server 2003 sp2 in the future (from your tool obviously, the patch files that update XP/2003's acpi source code with your patched acpi v2.0).

@mina7601 Btw, I'm partially involved in improving some of the designs made by others for the ViStart start menu designs. I'm also open for feedback regarding that btw.

File downloaded. I can only debug on virtualbox because I have one computer. If I can add my laptop's DSDT into the bios of the virtual machine then debugging acpi.sys through virtualbox should be possible.

@Mov AX, 0xDEAD Out of curiosity, I wonder if the 2.0 acpi driver compiled from your tool can run on XP on computers that lack CSM support (uefi class 3), like my computer in case: System Manufacturer: ASUSTeK COMPUTER INC. System Model: VivoBook_ASUSLaptop X509FA_X509FA System Type: x64-based PC Processor: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1992 Mhz, 4 Core(s), 8 Logical Processor(s) BIOS Version/Date: American Megatrends Inc. X509FA.306, 24.09.2021 Restart after boot crash is enabled, so if I use the 2.0 acpi.sys compiled using your tool, no crashes but xp (made using XP2ESD with latest backported drivers including nvme, custom acpi drivers and uefi support using vista beta files) still doesn't boot but the boot logo stays that way until I press power button to restart. If acpi.sys had BSODs, it would restart immediately so maybe the acpi.sys works and the problem is caused by something else that hangs at win32k session and yes I use vga emulator (FlashBootPro/UefiSeven) to provide fake int10h handler to try to boot XP on uefi-only hardware (on an older model, xp would boot even without CSM, but on an newer model it refuses to boot, keyboard unresponsive because of possible user-mode BSOD). I know I wouldn't be able to debug using a single hardware but I wonder if I can try to add my host pc's DSDT into virtualbox's bios so I can debug acpi.sys from virtualbox (I know how to start a basic windbg session using windbg preview with virtualbox's serial COM1 port to debug a windows from the virtual machine).

Using CFF explorer. To make the driver use the kernel extender, in the import section, rename ntoskrnl.exe to ntoskrn8.sys (obviously ntoskrn8.sys needs to be in the same directory as the driver so it works). If driver is designed for only windows 8 and newer os, Security_cookie (4EE640BB on 32-bit file, 32A2DF2D992B on 64-bit file) can be changed on hex editor to random value (first match only). Save the respective file, re-open the same file and refresh checksum and save again. To check the dependencies of the file, use Depedency Walker to check for missing imports. If there are problems, please post screenshots.

Windows once connected to the debugger, it relies on it to run once it's data shows on the debugger, maybe that's why it's slower. Without debugging, it's much faster because it doesn't rely on the debugger. Obviously without the "optimization", BSOD appears. Obviously, you should still debug ACPI.SYS for testing purposes (using commands to get it to boot without BSOD) but if things take too long to work, then you should also try the same without the debugger so it can show the BSOD faster.

Yes, I managed to do it using WinDBG preview, you can easily get it from Microsoft Store (for me only the version of windbg from microsoft store works to start debugger on VirtualBox, I don't know why). I got the information from this link: https://github.com/Dump-GUY/Malware-analysis-and-Reverse-engineering/blob/main/WINDBG Kernel%26User Mode Debugging/WINDBG Kernel%26User Mode Debugging.md Here's what I have done so far (serial debugging): For more advice on how to use proper commands to do the debug tests properly on VirtualBox, you can also ask @Mov AX, 0xDEAD and @Dietmar for help. Serial debugging with VirtualBox is what I am familiar. For other types of debugging, you can always ask these two or anyone else experienced with using WinDBG. If BCD is disabled, the following switches for debuging on boot.ini can be found here: https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/switch-options-for-boot-files#more-information Good luck.

By "FakeOS" you mean that the acpi files you have specify a different version of OS rather than the original version? If this solves incompatibility problems then it's great.

@Mov AX, 0xDEAD @Dietmar I am a begginer at C and I managed to compile x64 ACPI.sys 2.0 v7 without compiling errors using Mov's tool (thanks to practicing using WinDDK 7600 to compile ntoskrn8 to add functions to drivers, I even learned how to port drivers by adding blank stubs, modifying inf and changing imports using CFF explorer even tho I don't have any experience of adding code in WinDDK besides only functions that are blank stubs, this is relevant because WinDDK has made me learn how to add code in C properly). I wonder if the razzle tool from source code can compile the other files aside from acpi without problems? Because if that's the case, then I will try to compile bootvid.dll so I can try to change the resolution of the kernel vga driver from 640x480 to 1024x768 so I can try to force BSOD to show (using FlashBoot bootmgfw.efi VGA emulator on pure-uefi laptop) to show if XP crashed while booting from 16497 winload pure uefi (with only /BOOTLOGO specified in LoadString, NOGUIBOOT isn't needed), to see if the problem is caused by ACPI.SYS (for debugging purposes on only one computer because I can't afford to buy a second one). Specs: VivoBook Asus X509FA , Intel(R) Core(TM) i7-8565 CPU @ 1.80 GHZ (8 CPUS), ~2.0 Ghz, 8 GB Ram, supports Windows 11, Intel (R) UHD Graphics 620, 500GB NVME SSD (supports IaStorAC.sys/IaStorAVC.sys driver (intel premium optane rst) as mass storage controller, or generic nvme driver on ahci mode), no CSM support (UEFI Class 3), no VGA port, no Optical drive etc.

It can also be done using SVBUS driver btw.

@reboot12 Just so you know, I have created topic about XP on UEFI class 3 2017+ hardware on MDL: https://forums.mydigitallife.net/threads/unresolved-getting-windows-xp-to-boot-on-uefi-class-3-from-2017-computers-without-bsods.86331/

"12th Gen Intel(R) Core(TM) i5-12600" You managed to run Windows XP on newer processors than Coffee Lake? I am amazed!

Actually my graphics card has GOP, what it doesn't have is CSM Video / Int10h. George King managed to boot XP from pure UEFI without BSODs using the XP2ESD version 1.6.3 that he's currently working on. The XP version improved by XP2ESD includes the generic nvme, ahci drivers, acpi patches and the modified Auto-Sysprep (during setup only) etc. Regarding UEFI boot, George stated to me this: "You are trying Patched loader with patched drivers from various betas on real.. You can expect 100% functionality."

@reboot12 I know this may take a while to work on modern uefi class 3 hardware but the only way to get XP to boot on such hardware is to use WinDbg (by trying to connect lan/serial from the debugging hardware to the target modern UEFI hardware you're trying to boot XP from) with the scope of trying to spot the BSOD/problems that prevent XP from booting with UEFI on coffee lake and newer hardware. If these respective BSODs are fixed, XP + the required drivers and fixes + VGA emulator (like UefiSeven or FlashBootPro) SHOULD boot with a working display similar to legacy mode. I know you said that UefiSeven doesn't work on all hardware but we know why it sometimes doesn't work as expected. The contents from C0000 to CFFFF/DFFFF section need to be empty otherwise UefiSeven cannot unlock the C0000 segment from memory to implement the fake Int10h handler that would emulate VGA interface for GOP (VGA emulator will trick VGA drivers into seeing GOP framebuffer as a VGA device by emulating a VGA generic devices that redirects the code to GOP framebuffer, once used, before the emulated VGA code reaches GOP, the VGA emulator will convert the code's assembly language (Legacy Bios' language) to a C array (a language UEFI undestands) and then sends it to GOP framebuffer allowing it to display on the screen and I suppose this is how it works). FlashBootPro does things differently by trying to patch the kernel and all VGA drivers in memory (replacing references to VGA code and I/O ports with GOP framebuffer and forcing the VGA.SYS driver to adjust the screen resolution to 1024x768 or the native resolution supported by CPU in newer versions). While UefiSeven may emulate a VGA device that converts and sends the code to GOP framebuffer, FlashBootPro will automatically patch kernel and vga drivers in memory so they use GOP framebuffer directly allowing BSODs, win 7 bootvid and vga.sys to display on screen. While Windows 7 can work to boot from UEFI in this way, apparently this is not enough for Windows XP to boot on the newest UEFI hardware. Windows XP may boot from UEFI class 2 without CSM perfectly fine but refuses to work on Uefi class 3. Maybe UEFI class 3 lacks some code that Uefi class 2 still preserves (even with CSM disabled) that makes XP prompt BSODs that prevent XP from booting. When I try to open freshly made XP2ESD XP installation using DevManView, I noticed that the device manager drivers aren't even installed. If that's the case, maybe I'm getting 7B BSOD because the latest patched ACPI file from @George King is present in the system so it's not A5 BSOD. DevManView has the option of modifiying device managers that are located in folders inside Enum folder from registry or from another offline installation by specifying path with driver and with a specific controlset. DevManView works similar to device manager but it's also for modifying offline installation since it modified the contents from Enum if changes are made. On DevManView, the option to install drivers on offline OS is grayed out, preserved for active OS only. Just like ServiWin allows system services and drivers to be edited from registry or from offline OS. DevManView does the same, but for drivers from device manager from Enum folder from registry or from offline OS. DevManView: https://www.nirsoft.net/utils/device_manager_view.html ServiWin: https://www.nirsoft.net/utils/serviwin.html#Feedback I think these two tools from the above links are made by the same creator, that's why they look and work similar. These tools remind me of BootIce. Anyway, if nothing works to get XP to boot, then the only way is to borrow and backport more critical safe-mode files .sys drivers from Windows 7 to Windows XP with the hopes of achieving Windows 7's UEFI support that would allow XP to boot from UEFI without BSOD.

@reboot12 If you have seen the specs of my laptop that I sent on .txt file, the graphics card of my laptop is Intel UHD Graphics 620. If vbemp works with an Intel laptop with Intel graphics card then I should try to boot from the OS. I installed XP on virtualbox from George King's XP2ESD ISO because it's drivers may allow the OS to boot with display. And then I will copy the installation on the laptop's real HDD partition so I can boot XP from pure UEFI with FlashBoot bootmgfw.efi (laptop doesn't support legacy boot).

@reboot12 I found something bizzare when running modified XP installation from XP2ESD-based iso on pure uefi with FlashBootPro on real hardware. On serviwin I have noticed that a lot of critical drivers were enabled and disabled while XP was booting with the freezing screen. The Auto-Sysprep software from XP2ESD has managed to change the service drivers even tho there's no display. Because of XP2ESD ported generic drivers, the OS may be able to boot but even with UefiSeven/Flashboot present, xp videoprt.sys, vga.sys and vgapnp.sys still doesn't show the screen on XP on modern hardware even while these VGA emulators are used. If the problem I have is the same you have (error 50) then maybe I should try to use vbemp files by renaming vga files to see if vbemp really works on 8th gen hardware (and higher) on UEFI class 3 along with FlashBoot bootmgfw.efi.

@reboot12 Welp, I have one computer so idk how to make XP x64 run on my Coffee Lake laptop. Perhaps backporting system-type device generic drivers from Windows 7 and 8 (using NTOSKRNL EMU extender from github) that XP lacks may allow XP x64 to depend less on CSM just like windows 7 and Windows 8, perhaps maybe even allowing XP to run on new hardware with 8th core processors and beyond. If this doesn't work, then still I wouldn't be able to explain which specific drivers cause Windows 7 x64 to boot from Uefi Class 3 on modern hardware that would allow XP x64 to also work. For more information about my hardware, here are the specs (maybe from the hardware IDs, we can backport the system-type generic drivers that would allow to run XP on my hardware etc): DxDiag.txt

@reboot12 Ok I get now. Anyway, i think something should be done to 16497 winload.efi so that at least we can see the BSOD when trying to boot XP from pure UEFI (with the scope of making those errors visible so that we can know how to solve them more easily). On windows 7/vista with pure uefi, BSOD can be seen while using FlashBootPro bootmgfw.efi on pure UEFI so maybe there's some hex code in 16497 kernel that allows bootvid to display. If we can find that necessary code, then maybe bootivid and kernel dependencies from 16497 winload.efi can be removed using hex editor or disassembler to allow XP bootvid to display in order for the XP kernel to work properly on UEFI BCD.

@reboot12 Well George King has managed to implement your advice on a test iso (which you probably received already) by adding comamnds inside XP2ESD iso (inside boot.wim on setup.cmd to remove vgapnp.sys/vga.sys services (including display.inf) while using vga.sys/vgapnp.sys files are still intact and present in system32/drivers because if the drivers are not listed in services, windows wouldn't even be able to use the vga drivers even if they are present). He has tried to backport MSBDD basicdisplay.sys drivers and said that it won't even work on Windows 7, let alone Windows XP. The mistake with the code is that vga drivers will be removed even on legacy mode so there will be added an "if" command to ensure that the code works on uefi mode only.

Without VGA emulator, GOP native driver needs to be installed, vga output should be disabled from bcd and services (vga.sys/vgapnp.sys should be disabled). With VGA emulator, this isn't the case on Windows 7 because I can run windows 7 x64 from uefi class 3 as long as I have VGA emulator enabled and vga.sys/vgapnp.sys enabled (even on safe mode). I prefer to run VGA emulator with vga output enabled In order to be able to use safe mode and see a visible BSOD in case of issues.

@reboot12 If you use VGA emulator like FlashBootPro/UefiSeven, then it's no longer required to disable VGA. In fact, windows won't even display the screen if vga.sys/vgapnp.sys are disabled even if VGA emulator is used. VGA-only drivers should be disabled only when VGA emulator is absent. I can boot xp x64 from VirtualBox EFI using FlashBoot bootmgfw.efi and xp vga.sys with GUI boot disabled as long as the VGA emulator inside bootmgfw.efi is present. UefiSeven works as well, but you can also see the BSOD on FlashBootPro bootmgfw.efi (on UefiSeven, BSOD doesn't show at all on CSM-disabled UEFI).