@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.

1 hour ago, Mov AX, 0xDEAD said:

So 8.0 usb3 driver works properly with native acpi 8.0 driver but not with WinXP/Win7 acpi driver ?

@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.