Zitat von Fernando im Beitrag #1875 It was not even necessary to disable the driver signature enforcement or to force the installation by using the "Have Disk" button.
You somehow breaked signing protection system, so anyone now can create selfsigned "ring0 viruses" for 64 Oses ) p.s. but it still need rights to import cert to root/trusted storage
p.s. Omicron is probably right, signature stored in catroot storage. if you hve free time, change some byte in any string inside *.sys, resign and check
Zitat von diderius6 im Beitrag #243 The checksum changes and all adresses. This simple means, in the fight of AcpiBios against XPAcpi, XP ignores Bios and lift all adresses. The relation between tables changes also.
I was wrong about _AMLILoadDDB, it load only one table - DSDT ! _AMLILoadDDB-> _LoadDDB-> -> _ValidateTable -> _NewObjOwner -> _PushCall -> _PushScope -> _SyncLoadDDB one of subproc probably return nonzero => _AMLILoadDDB generate 0xA5 kernelfault
0x000000A5 (0x00000011, 0x00000008, 0xB7B07200, 0x20160422) 0x20160422 - Compiler Version 0xB7B07200 - pointer to DSDT in memory
Zitat von diderius6 im Beitrag #236@Mov AX, 0xDEAD the 3. place in this BSOD is the Pointer to the table that ACPI failed to load. What does "ACPI failed to load" mean: checksum incorrect, table not at this place.. I do not find any related to the adress B7AB6200. In the e820 list this memory space is also not listet. EDIT: I found with Ida pro, that for example checksum of table from RSDT failed before BSOD A5 (0x11..).
3rd argument can point to anything in RAM, it just hint to human (or some util) who save full memory dump checksum error is a5 (0x11, 0x7), you have error with _AMLILoadDDB maybe it load table, then parse aml codes, then do some else, who knows...
Zitat von FSHEHTESI im Beitrag #1Can anybody tell me what the message "non-empty pad-file contents will be destroyed after volume modifications" means in the ubu tool ?
pad-file is region at end of uefi file (module), it need for align next file or to claim free space, pad must be filled with zeros ones regarding standart uefi layout. if you change length of some uefi file, ubu will recalculate pad-file and fill it with zeros ones ignoring previous contain.
bios vendor can do some undocumented tricks with pad-file and store some info inside it
Zitat von diderius6 im Beitrag #218Hm, may be this is important: Via this way I think, XP comes in contact with the reserved word CreateQWordField, because the if else construction is not correct in the Bios from Gigabyte and Asrock, only on Apex board:
1 2 3 4 5 6 7 8
If ((OSYS >= 0x07D6)) { If ((M64L == Zero)) { CreateQWordField (BUF0, \_SB.PCI0._Y0F._LEN, MSLN) // _LEN: Length MSLN = Zero
maybe this is problem too, on ivy this part is right:
1 2 3 4 5 6
If (((MM64 == Zero) || (OSYS <= 0x07D3))) { CreateDWordField (BUF0, \_SB.PCI0._Y0F._LEN, MSLN) // _LEN: Length MSLN = Zero }
M64L/MM64 is field meaning 64-bit OS or 64 access || - logical OR so on ivy _Y0F under xp is still qword template, but we create only DWORD field
on skylake+ under xp acpi skip declaring lengh of resource because "If ((OSYS >= 0x07D6))" skipped
Zitat von diderius6 im Beitrag #216PS: Is it possible to edit the e820 list by hand?
no, list generated by int15h handler in 16bit asm code but you can compare parsing result in xp and vista+ acpi.sys (ACPIRangeValidatePciResources) seems in xp very strict checking
Zitat von diderius6 im Beitrag #212 Small hack in acpi.sys using Ida pro looking for the string "ACPIRangeValidatePciResources" and when it is not a real conflict, then this is all
yes , it is possible, but better to step debug all ACPIRangeValidatePciResources, proc in not big hint: probably cmp al,1 - compare by resource type, 2 - irq 3 - mem 1 - i/o port
E820 is just list of mem regions free/reserved, i dont understand how this list linked to pci mem resources or acpi mem resources e820 reported by bios int15 to windows loader acpi mem resources reported by enumeratung all devices in acpi code and call "_crs" to each pci mem resources reported by enumerating all devices on pci bus (but only if driver loaded and device enabled i think)
Zitat von Fernando im Beitrag #1868The related Intel USB 3.0/3.1 drivers exist, but they do not work with Z390 Chipset systems, because the related DeviceID is blocked by Intel's code of the *.SYS file.
Hold up a minute, are you actually saying that code to handle "DEV_A36D" specifically is inside of the drivers provided by Intel? Like there is a simple switch in there blocking it inside of 5.0.4.43 in something like iusb3xhc.sys (or the hub/switch driver?)
code inside iusb3xhc.sys check for dev_id and compare with "know" codes (virtual list of usb3.0 and usb3.1 dev_ids, see .inf) if check passed, driver assign some internal "magic" type to device (dev_id 8C7F=>20, dev_id A12F=>75 and etc) and set some abilities based on type (container of bits) if check failed, driver unload wit error
Zitat von diderius6 im Beitrag #207Hi, I extracted all 23 (!) Acpi tables via rw-everything from the XP-friendly Bios from Elmor from the Asus Apex X motherboard.
I saw this bios, it is unusual, for diff OSes it create diff resource templates (XBUF vs BUF0) and rename fields, for winxp it select template without QWORDmemory region
Zitat von diderius6 im Beitrag #202Hi, I just noticed, that acpi.sys in XP posready 2009 is 5.2.3790.1830, which means win2003 version. There are big differences between XP and win2003 in Acpi, for example win2003 does not look at the registry for the Acpi tables but XP does
it is still acpi 1.1b implemenation and 32 bit integers, no big diff for me
i've played with 2nd variant, cpu and package enter more deeper states then c1: C1->C1 broken acpi C2->mwait C7s broken acpi C3->mwait C10 [[File:c7-c10.png|none|auto]] Now power states transitions look like win7+ )
Zitat von diderius6 im Beitrag #201@Mov AX, 0xDEAD I read from Acpi specification, that only C0 and C1 have to be implemented. Have you tried to change energy-options in XP and look what happens? Some time ago I hear, that when you chose there "laptop", that XP installed less devices via Acpi.
C2&C3 also implemented c1 is two cpu instructions "sti then halt", с2, с3 is external acpi controlled logic. energy options affect speedshift/c1e, so cpu will down clock or not, i dont see any other changes
p.s. again, we have broken acpi hardware/bios support in skylake+
Win-Raid Forum (Drivers - Firmware - Modding) » Search for Mov AX, 0xDEAD's content 
Sun Dec 30, 2018 5:05 pm