Mov AX, 0xDEAD

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.

With more debug output there is no problem with HIDD or I2C0, dsdt is same on ever reboot One crazy idea - emulate time delay (near DbgPrint(c000034...)) when running free build without windbg connection:

There is no way to debug such error, this can be re-entry problem at any place or some anything else It is undetectable bug in original code or my patches, i cannot fix it. I just will check again how processor opcode breakpoint triggered many times from different kernel threads

@Dietmar Did you tried v1-v6 version on this board with XP x64 ? Maybe again last processor patch is bugged ?

@Dietmar I think this is multiple threads race condition problem If you filter acpic034mehrtext.txt and keep only c00034 lines, then compare with short bsod log, i will see difference in order it matches at begin, but later difference is random vs This mean apci is most async, it call other driver and kernel with callbacks, get answer "postponed", after some time event triggered and callback called, so every boot order of execution is not same

@Dietmar Hi, Check PM for new iteration

we can add debug output where a5, (0x3,,C0000034) is used to checked build to see parent device tomorrow i will write what to add if you still want to play with it EDIT: please send me original DSDT in binary form

acpi64v22.txt without bsod: 1) if bsod occurs at random place, my patch is useless, still need finished full log 2) if bsod occurs always at same place, problem is SB.PC00.I2C0.HDAC._HID or next thing _SB.HIDD._STA or some between FFFFFADCE3E8DDB0 ACPIBuildProcessDevicePhaseUid: Status = 00000103

check PM

@Dietmar simple check - hex search acpi.sys for "AMLI: %p: AsyncEvalObject(%s)", if you no have it inside free build - patched code was skipped by compiler

on host can be any OS and probably any windbg, text output relay on DbgPrint(), we call it at line 865 on target pc, this function just send text to host's windbg without filtering (as DDK said)

OK, line is right, you keeped PRINTF macro, it works only on checked build, DbgPrint - for free too In prev full log, was many of similar, so this code was executed: if you still no have output - AMLIAsyncEvalObject() execution aborted before line 862

no matter, with or without ed Kd_ACPI_Mask 0xFFFFFFFF recheck amliapi.c

amliapi.c, line 862: I attached log from free acpi.sys free log.txt

for free i think need replace macro PRINTF() to direct

let's try with improved debug logging: 1) back to lite debug mode ed Kd_ACPI_Mask 0xFFFFFFFF 2) patch amliapi.c to partialy enable full debug lines: to: Now you must get many "AMLI: xxxxx: AsyncEvalObject(\_SB.PC00.MC._ADR)" in lite debuglog, probably it will point to exact dsdt place before BSOD, as i understand we look for definition with bugged/missed _UID

@Dietmar At least we know v6666 way to fix it - mask ACPIBuildCompleteMustSucceed of couse this way is not perfect, interpreter stopped on some dsdt code and never reach code after

I stuck with kernel debugging XP/W2003 x64 on VirtualBox, WinDBG hangs on virtual com1 port connection. VirtualKD connection also useless because it doesnt work with VBoxHardenedLoader required for custom dsdt/ssdt tables. QEMU also bad, it doesnt have good documentation for win32 platform, i dont know how to enable virtual com port, there is a lot of options and nothing to works Last hope is VMWare and VirtualPC...

these messages are from checked hal.dll i think this is OK because slow COM connectiuon

@Dietmar yes, this lite log doesn't point to exact problem dsdt code: need full log, but with COM speed it can be very long !amli set spewon verboseon logon traceon