Mov AX, 0xDEAD

I checked Longhorn 5048 x32 NDSI.sys vs Windows 7 drivers, missed from ndis.sys: Realtek: from kernel: on Intel i291: on Atheros: netio.sys: msrpc.sys: @Dietmar , You've wrotten v5048 has almost imports, i dont's see same

@Dietmar Thanks for info, i will check how it is stable

NDIS 6 is new framework, that's problem, if think it is not easy to make it compatible with XP kernel even all missed import will be solved. Another way is emulation NDIS6 features based on NDIS5 source code, but it requires a lot(?) of programming

1) Last fix mainly for x64, for W2003 and W2003/XP x64 we still don't have SP2 correct headers, so pre-v8 is far to be even "beta" I will update topic to include fix only for x32 XP 2) Assertion Fail on loaddsdt.c, line 488 for x64 builds (v8 update) This is x64 fix for semi-broken VirtualBox's ACPI BIOS tables, real systems don't have this problem

Fix128 and Dibya's patch enables 4gb+ ram for XP x32 kernel, but there is issue with HAL.dll (DMA stuff) As i know only "Windows XP PAE Patcher 3.x by Daniel Kawakami" has correct HAL patch

Hi @George King as i wrote before, comparing w2003 kernel headers is too boring, so pre-v8 has only multi-thread "ssdt loading" race condition workaround: worker.c: 1) 2) acpiinit.c: 1) 2) patched code uses KeGetCurrentThread()->Affinity, on x64 _KTHREAD structure has WRK(SP1) definition and ->Affinity mismatch with x64 SP2 kernels, need update header: ke.h: w2003 wrk: SP2 actual: 2) there is self-check, need comment all three lines because we don't have Win32kTable/KernelLimit/Win32kLimit on x64 SP2 anymore:

this is 28362 offset, need patch too, you can patch 155a or 1559, no matter p.s. can you share final e1d5132.sys ?

1) at offset 2137C numbers 1559 and 155A used as equation range if you have new 15B8, only patching 155A is enough, but author of patch changed both numbers, it is OK 2) i think one offset is missing: new 15A1 is not <= 0x155A, so we never reach goto type_21; line

there is many cheksum tools, i attached one checksum.exe

e1d5132.sys has more difference, DEV_ID=1559/155A(I218-V/I218-LM) replaced few times to 15A1(I218-V2) position 0x138 and 0x139 - updated e1d5132.sys checksum this hack is simple - force driver to use I218-V software code for I218-V2 hardware, sucess depends on how little hardware is different, first linux driver does same thing https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191192 e.g. no real software changes, only new DEV_ID added

ACPI tables is so smart, so can disable PCI and other type of internal devices depending on user OS, disabling USB3 hardware controller on pre-Vista OSes is this case.

@George King v8 is postponed, too boring comparing headers, sorry Anyway you can port pre-v8 from x64 patch to x32 with current headers, probably on x32 we don't have problem with headers, so can keep as is

XP kernel doesn't request acpi.sys for new features, it is useless to implement for example GPIO or _DSM() because kernel know nothing about it

@UsefulAGKHelper No, i'm not interested, cumulative src patch includes few workarounds for acpi 3.0+ new features, it mostly doesn't implement anything, instead it just skip definiton of new structures like SMBus/GpioIo/I2CSerialBusV2 to avoid bsod or AML interpreter error, if these structs used heavely later, probably BIOS with such acpi tables is not compatible with current acpi.sys and require manual table text patching Only acpi 2.0 new commands fully implemented, because used widely in modern BIOSes.

I think this is not ACPI issue because DM shows PCI-PCI Bridge<->VGA confilct including IO and MEM range PCI bridge resources are dynamic and incorporate resources from all childs, in normal system DM always show VGA resources on PCI Bridge too, but in your case this is special, windows think this is error

rus: 1) Без патча таймера таймер вообще не работает в ядре windows, последствия зависят от конретной програмы и драйвера, который его захочет использовать 2) патч intelppm дает энергосбережение когда процессору делать нечего, если стоит супер-кулер то не обязателен, но желателен, меньше греется, дольше поработает 3) В диспетчере устройств включи режим просмотра отключенных устройств, далее щелкай по всем устройствам пока не найдешь на закладке "ресурсы" упоминание о том что что эти ресурсы конфликтуют с другим устройством XXX. Если сразу есть информация что XXX конфликтует с YYY, то просто заскринь вкладку "ресурсы" eng: 1) Without a timer patch, the timer does not work at all in the windows kernel, the consequences depend on the specific program and the driver that wants to use it 2) the intelppm patch gives energy saving when the processor has nothing to do, if there is a supercluster, it is not mandatory, but desirable, it heats up less, it will work longer 3) In the device manager, turn on the disabled devices viewing mode, then click on all devices until you find a mention on the "resources" tab that these resources conflict with another XXX device. If you immediately have information that XXX conflicts with YYY, then just close the "resources" tab

W2003 acpi patches include IOTR<->VGA IO space conflict workaround from first version, he didn't provided device manager detail, so it can be any issue with vga

1c семерке по барабану какое acpi, acpi нужно OS для управления процессором, в теории если весь acpi будет кривой и косой, процессор все равно будет работать, только в макс режиме по питанию и частоте. если acpi.sys не падает - работать можно p.s. это где еще семерки то стоят ? кастомная конфига ? 1c seven doesn't care what acpi is, acpi needs OS to control the processor, in theory, if the entire acpi is curved and oblique, the processor will still work, only in max mode for power and frequency. if acpi.sys does not fall - you can work p.s. where else are the sevens? custom config ?

in russian: Недавно всплыло два бага, один связан с таким-же bsod, второй связан с компиляцией исходников, на текущий момент нет 100%-но правильно скомпилированого acpi.sys для W2003 SP2/XP x64, сущ. бинарники включают режим игнорирования ошибок, какая часть таблиц acpi выполняется, а какая нет в таком режиме - никто точно не знает english(auto-translated): Two bugs have recently surfaced, one is related to the same bsod, the second is related to the compilation of sources, at the moment there is no 100% correctly compiled acpi.sys for W2003 SP2/XP x64, existed binaries include an error-ignoring mode, which part of the acpi tables is executed and which is not in this mode - no one knows for sure

Don't mislead, Is it not better, it is more compatible with XP SP3 binaries, than W2003 RTM sources with W2003 SP2 binaries

@George King v8 must be x64/x32 update to fix SSDT race condition issue on multi-core CPU, but then i found w2003 .h headers mismatch. May be XP headers also mismatch, i don't know yet. So v8 will include .h patches, but it require much more time, unfortunately BINDIFF doesn't show difference in offsets, instead needs manual comparing source .h files with MS SP2/SP3 acpi.pdb decompiled. example of headers problem: W2003 RTM(leaked files): mov ecx, [eax+04] ; 04 - offset of YYY.XXX W2003 SP1(WRK): mov ecx, [eax+06] ; 06 - offset of YYY.XXX W2003 SP2(MS binary): mov ecx, [eax+08] ; 08 - offset of YYY.XXX YYY - kernel structure, XXX - field inside structure

@UsefulAGKHelper 1) VBox officialy doesn't allow to load custom DSDT/SSDT, need use 3rd tool to disable Hardening mode 2) Due unknow bug in Windows x64 COM transport, windbg session hangs when connecting to virtual COM port 3) For x32 i use VirtualKD transport, it is most fast connection, also it works in x64. 4) VirtualKD x32/x64 stop works if Hardened Loader is active 5) Last VBox 7.x offers some internal windbg support, but i dont know how to configure it 6) Internet says about Vbox custom builds without hardening mode, i never checked it 7) Vbox before 4.3.14 doesn't have Hardening mode, probaly VirtualKD works on it Currently i have official Vbox 5.2, debugging x64 with custom acpi tables is impossible on my setup About injecting DSDT/SSDT to VBox: DSDT on modern MB have few memory region definitions, hardcoded to current bios config 0xBC8DB000 adress is random depending on BIOS setting, inserted cards and other things ACPI reads/writes OSYS, SMIF, ... fields on real memory filled by BIOS values, on VBox all these values will be empty or random Also there is many other definitions like: p.s. I think any custom table replacing will will lead to memory BSOD

@Andalu Booting OS is very complex, many drivers wait hardware response, try different storage/vga/usb3 driver or classic acpi v6666 if it possible. There is special util to measure boottime (Microsoft Bootvis), it shows kernel boot time (as i remember)

I think same as first release of SP2 x64 Small updates of ntoskrnl.exe doesn't change .h fields Fields usual changed between sevice packs, so almost files recompiled because kernel offset changes W2003 x64 rtm headers from leak are too old, we need WRK() as base and additional patches to match SP2 kernel I suprised why WRK is not same as SP2, official description: p.s. WRK is 2003 SP1 sources

@Dietmar What is KB number with this update ?