daniel_k

I mean that we could add support to all ACPI 2.0+ opcodes and treat them as NoOp (does nothing), if this makes any sense at all.

You're obviously correct. Yes, because the device still exists physically and is treated as a PCI device, the GPIO entries in DSDT do not cause the crash. Thanks for doing the tests, Dietmar!

For now, this is the best workaround for non-PCI devices. Thanks to @Mov AX, 0xDEAD Please do a further research before trying to patch randomly the driver. Don't expect to get something to work reliably this way. I've just disassembled acpi.sys from Vista / Win7 and indeed, there is a PcisuppIsPciDevice function called before any calls to LinkNodeCrackPrt. PcisuppIsPciDevice does further validation of PCI devices. On XP, AcpiArbCrackPRT is called from AcpiArbFindSuitableRange and AcpiArbAddAllocation, Returning STATUS_NOT_FOUND for a non-PCI device is definitively the best approach and doesn't break the code that supports ISA devices.

@Mov AX, 0xDEAD I see that there is a NoOp (No Operation) operator. Still don't know how the built in AML interpreter in ACPI.SYS works, but what if we create a generic function based on the NoOp and use it for all unsupported opcodes, so the DSDT is properly loaded?

@Dietmar If it doesn't bother you, please do one last test. I've removed GPIO and eMMC devices, which use Interrupt Resource Descriptor Macro. See if XP boots with the ACPI with CreateQWordField fix only. DSDTAB350k4_NO_GPIO.7z

@Dietmar Does the board crash Windows 7 or 8.0?

Thanks, so this means that the issue is probably related to resource assignments. Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, ) The code above is used by the GPIO device only and ACPI "dies" after processing the device.

Sure, here it is. It's just not properly formated (indented). Make sure you're replacing the correct table. There are at least 4 DSDT tables inside the BIOS. DSDTAB350k4ORI_MOD.7z

@Dietmar Please do the following test, without the last ACPI patches (only QwordField fix): - put Device (GPIO) inside Device (PCI0) - search for _SB.GPIO and replace it with _SB.PCI0.GPIO So we will know for sure if the issue is the improper location of the GPIO device or the device itself.

@Dietmar That GPIO code from AMD AB350 k4, is it inside _SB.PCI0? AMD boards usually expose the GPIO controller, Intel either hides or disables it. Notebooks are a different story, though.

@Dietmar See if any of your AMD or Intel boards/notebooks have a GPIO controller and don't crash XP. Check the DSDT table and see where the GPIO is located (inside or outside the PCI0 scope).

Hmm, probably is not disabled, C3 works properly on Vista.

Will take note of it. Yes, probably a bug, because the DSDT table looks about the same on my Gigabyte Z370 and doesn't crash XP with that emulation enabled. Luckily it can be disabled.

@Mov AX, 0xDEAD I have a Gigabyte H310 board that crashes XP if Port 60/64 emulation is enabled, so add another problematic device to the list.

@Mov AX, 0xDEAD With my patched DSDT table, XP runs with original files, but cannot get C3 working. Somehow intelppm.sys or acpi.sys goes crazy. Managed to get C1E working by "skipping" some code. Can I use debugging to help me to fix the DSDT table?

It seems that ACPI goes nuts after processing this device (AMD GPIO controller)? ACPI 5.0 introduced special handling of GPIO controllers. Could it be the issue here? http://www.uefi.org/sites/default/files/resources/ACPI_5_0_Errata_B.pdf

Just finished testing my fully updated install of Vista Ultimate x64, including build 6003 updates from Aug 2020: It seems that Microsoft fixed the timer issue, as seen above. Unfortunately, there are still random issues, specially with UAC prompts: permissions are not properly granted. Even so, it's clearly much more stable.

For Starter, some updates won't install, as some features are not supported, such as Dreamscene and other Ultimate extras.

You need to do some tests. I'm not sure if that DLL is also used for connection purposes or local encryption only. In the mean time, I would search for any other registry setting that changes DLL search path.

Did you restart Windows?

@Dylan Cruz Pretty sure you have a CWDIllegalInDllSearch registry entry. http://web.archive.org/web/20141212220002/support.microsoft.com/kb/2264107 Probably it was added to SP4, as it isn't enabled by default.

@Dylan Cruz I have no idea what is going wrong on your system. I've just copied dssenh.dll to the Office folder. That's all.

Yes, it works. For me, it's easier to get it working on a fully patched (POSReady) XP than a clean install. @Dave-H, one last try: - stop the Automatic updates service - delete C:\WINDOWS\SoftwareDistribution\ScanFile and rename C:\WINDOWS\SoftwareDistribution\DataStore and C:\WINDOWS\SoftwareDistribution\Download - restart the Automatic updates service - run the MS script

Actually, it shouldn't be installed. You are just "providing" an older and working copy of the DLL for Office to work with.