Jump to content

Mov AX, 0xDEAD

  • Posts

  • Joined

  • Last visited

  • Days Won

  • Donations

    0.00 USD 
  • Country


Mov AX, 0xDEAD last won the day on May 9 2022

Mov AX, 0xDEAD had the most liked content!


About Mov AX, 0xDEAD

Profile Information

  • OS
    Windows 7 x64

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Mov AX, 0xDEAD's Achievements



  1. 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
  2. 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
  3. 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
  4. 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 ?
  5. 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
  6. Don't mislead, Is it not better, it is more compatible with XP SP3 binaries, than W2003 RTM sources with W2003 SP2 binaries
  7. @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
  8. @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
  9. @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)
  10. 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
  11. 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
  12. 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
  13. 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:
  14. 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

  • Create New...