Mov AX, 0xDEAD

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 ?

structs_acpi.txt - compiled structs (KTHREAD already reverted) structs_kernel.txt - structs from real ntkrnlmp.exe 5.2.3790.3959 most important kernel things match(TEB/PEB//ETHREAD/KTHREAD), but need to look at all structs_acpi.txt structs_kernel.txt p.s. many kernels structs missed at structs_kernel.txt(.pdb is not full), so this is not 100% way to find mismatches

XP SP1 used only for x32 XP compilation, no point compare with w2003 sorces w2003 soures used for compilation w2003 x32/w2003 x64/XP x64

This mean this acpi.sys x64 can be used only with kernel, compiled from W2003 RTM or WRK. It run with XP SP2 too, but it may read/write wrong values of kernel structs - process/thread/peb/teb/... Real x64 SP2 decompiled header, struct _KTHREAD, what KeGetCurrentThread() returns: w2003 rtm: w2003 WRK:

Hi All I found serious issue with compiled ACPI.SYS for x64 platform - mismatched kernel headers, e.g. ke.h We have two version of .h files: 1) Leaked W2003 source tree 2) W2003 Windows Research Kernel(WRK) None of these two options match official XP/W2003 x64 SP2 kernels. Issue in the fact is that acpi.sys reads incorrect fields of windows threads. For fixing this issue need to review kernel headers and change it to match MS official x64 kernels

Hi All x64 acpi.sys BSOD 0x000000a5 (..., ..., C0000034, ...) workaround is ready, not published, need more testers. Solved problem with postponed SSDT table loading

@Damnation Delays are useless until you know where to insert it. Patched x64 acpi.sys with additional delays is crap.