infuscomus

@Mov AX, 0xDEAD With help from @skulltrail I've gotten the ntoskrnl source code to boot in vanilla SP3 XP. However as soon as I try to use your ntoskrnl extender I get BSODs First 0xDEADBEEF which I bypassed, but now I get BSOD 50 and 8E any help to get your extender working with this?

@canonkong I'm actually not sure which USB ports are connected to 148C, whenever I tested and checked through device manager which controller handled the device it was always 149C. I'll have to find which ones are connected to 148C.

@canonkong For A5 BSODs I asked @Dietmarfor help, he provided the patched windows 8.0 ACPI driver to me that help me get past the A5 BSOD there. My system that has the 149C controller is a GIGABYTE TRX40 DESIGNARE and a 3960x - so it's not related to the ASUS bug and must be something else.

@canonkong The windows 8.0 ACPI driver maybe? - vanilla versions gives A5 BSOD, but after patching it boots and the 149C controller works there properly at boot time.. It'd be one hell of a job to port it to XP though. We'd first need to prove that it can work for the Vista RTM ACPI driver before we can even think of trying to port the Windows 8.0 version.

@Mov AX, 0xDEAD Windows 8.0 boot with patched XP outerspace acpi.sys - BSOD ATTEMPTED_EXECUTE_NOEXECUTE_MEMORY Windows 8.0 boot with patched 7 acpi.sys - BSOD ACPI_BIOS_ERROR Unfortunately it wouldn't show useful information like it usually does, just the title of the error, but nothing about where it occured.

@Mov AX, 0xDEAD I made a typo there - only Windows 8.1 worked without patching. Windows 8.0 gave an A5 BSOD, after an acpi.sys patch from @Dietmar it was able to boot and USB 3.0 worked correctly. I had not considered booting Windows 8.0 with XP and 7 acpi.sys - I will test this and report my findings back to you.

@Mov AX, 0xDEAD Over at the MDL forums another user has reported problems, this time now with an Intel USB controller. I don't suppose you have any motivation to try and port over the 8.1 version of the USB 3.0 driver?

A reminder for myself - DSDT GUID is: C118F50D-391D-45F4-B3D3-11BC931AA56D

@Dietmar In DSDT it may have a different name - To determine BIOS name under windows 10 device manager, select USB controller, go to details tab, select BIOS device name. eg. - it could be something like \_SB.PCI0.GPP2.PTXH I'm skeptical that a DSDT modification will work, windows 7 has the same problem with the 149C controller, but something in the windows 8.0 ACPI driver makes it work at boot. Nonetheless I can try DSDT modification anyway thanks to grub2 if I need to.

@ExtremeGrief No fix is available yet unfortunately. @Mov AX, 0xDEAD I'll give KeStallExecutionProcessor() a try anyway since I know the driver works for this controller in XP by disabling and re-enabling it, it's just something peculiar at boot time that is making it not work. To use KeStallExecutionProcessor() would putting this in DriverEntry of ntoskrn8.sys work? OldTime.QuadPart = Int32x32To64(1, -(10 * 1000 * 1000)); Status = KeStallExecutionProcessor( ); Windows 8.0 LiveCD - unmodded gives A5 BSOD - with patched acpi.sys it boots - 149C controller starts correctly. Windows 8.0 LiveCD - no A5 BSOD - 149C controller starts correctly.

@Dietmar@George King Do either of you know how to tell a driver to look for a specific device ID in C code?

@Mov AX, 0xDEAD What would be the best way to tell ntoskrnl extender to wait a few seconds in C code? I want to see if waiting a few seconds might help the problematic 149C USB controller to start correctly. like have an if statement at the start checking if PCI\VEN_1022&DEV_149C is present then wait 5 seconds else continue as normal.