Mov AX, 0xDEAD

@George King This way you'l get another v6666 from 2018....

storpor8.sys is emulator of some new functions for win7's storport.sys I have experimental ported win8.0 storport.sys, it has many manual injected calls to PoStartNextPowerIrp(), perfectly works with win8's storahci Me and Daniel chose win7's storport.sys as base for ported storage drivers because it was last version who stills call PoStartNextPowerIrp() at proper places

I don't have NVMe hardware and it is very bad emulated by vmware/virtualbox, all my attemps to make working NVMe under VM was failed. My answer - yes, Daniel made many storage drivers for x86 and x64.

I didn't ported any Win8.1 NVMe drivers

start with saving crashdumps to disk, it can show stacktrace before crash

IDA debugger has same GUI, as standalone Disassembler i dont have pre-install environment experience, debug config stored in BCD

Remote debug with IDA, first learn when AMLILoadDDB(check subprocedures) may produce error, set breakpoints. There is internal "acpi debugger", but i dont know how to use it at boot time

I would like to remind that "mindless" turn off checks in acpi.sys (v6666/v5048) can lead to the fact that part of the AML code will never be executed. Remember skipping error of AMLILoadDDB() or ValidateArgTypes() ? Once you took this short way....

USB\RESET_FAILURE - what is it ?

No, PDB not published for early vista betas, PDB exist since v5342, maybe earlier, but i not tested

You are very far to booting XP texmode."Setup is Starting Windows" means all drivers loaded as files to ram. Next stage is code execution, but it stops there (surprise)...

Question is - how many people using WinXP x64 on UEFI x64 with original ACPI 1.0 driver on modern PC? Answer - about zero, only few new motherboards has special acpi1.0 legacy support for WinXP. Of couse you can make heavy patch of your DSDT to isolate all acpi2.0 syntax and run with ACPI 1.0 driver. Or use acpi x64 driver from longhorn 5048 beta

No, i can't. it's your idea and only you must handle it

For export/use already existing funcs in kernel. Not best solution, but it works on standart MS kernels. Modders, just comment all KeBugCheckEx(0xDEADBEEFL, 5, 0, 0, XX) lines

1) You cannot PoSetPowerState without device_object, device_object will be created usb3 driver to present usb3 controller abstraction to Windows 2) PoSetPowerState used to inform windows about current power state, what you do next after windows marked device as D0 ? 3) Better reverse ms usb3 8.0 driver(use win10 usb3 sources as base), find place where controller is resetted, change wait time or inject your additional code 4) Think about why are some additional delays/power states - solution to the problem ? I have repeatedly written that the driver will reset the controller, you will reset it second time(or you - first, driver - second), and what will it give ?

Do it yourself, reseting controller is complicated task, first you need take ownership from bios(for on-board controller). hal source show how to get ownership. Also explore leaked windows10 usb3 driver to see how to reset controller. And again, MS USB3 driver do these jobs itself. "system has just been booted" - i dont know what you mean, running ntldr(DOS-part) or running win32k.sys from user-mode process is same "windows are booting". Emu_Extender run when windows load any first driver linked with ntoskrn8.sys, it can be usb3 or storage driver, so DllInitialize will be runed before main win8 usb3 controller code (USBXHCI.SYS) in any case

of course, you used "// Dummy entry" use "DllInitialize ( // Main" because emu_extender is Export Driver, not a usual Driver

driver fails (error code) or hardware fails to detect ports/hub ?

Let see what hack do: HalpStopOhciInterrupt check who is current owner of usb controller: 1) if BIOS, hal request changing ownership from bios to hal 2) if controller has no owner, no actions with ownership. At end HalpStopOhciInterrupt disable interrupts by writing to controller. Why HAL need this hack ? i guess to avoid unexpected interrupts when no driver loaded for some device. But we have proper usb3 driver and usb controller cannot works without interrupts, so usb3 driver will enable interrupts anyway(maybe with other pci routing, i dont know), also MS USB3 driver recheck ownership of controller and gain it if controller is under BIOS control I think these hacks are useless because usb3 driver do opposing job. Can you remind me, what is wrong with amd controller and MS USB3 8.0 driver ?

We already have compiled sp3 kernel from MS, so No. If you have custom kernel, you need all related files compiled from same source - hal, acpi, win32k(?), pci(?) ...

I dont know, MS usb3 driver is very complex due "usb stack", maybe it require specific acpi functionality. Or maybe bios uses specific registers of amd usb controller to reprogram it to custom mode so DSDT is only way to control this "custom" mode.

I can explain only 0xDEADBEEF bsod, because this is extender's internal assertion checks 0xDEADBEEF, 0x3 - bug in PsSetCreateProcessNotifyRoutineEx_k8, overflowed list or some similar 0xDEADBEEF, 0x5 - not found signature of existing but not exported functions in ntoskrnl.exe, just comment KeBugCheckEx() 50 or 8E - can't help with this, when you mix parts of different OS - you get mess

Code 10 is common error - unsupported hardware, unsupported OS, failed internal driver checks, etc... Driver code starts, but windows receive some error from driver, you can't fix it with patching .inf And don't forget to remove initial security cookie check, this check, will fail on pre-Win8 OSes

OK, original 8.0 usb3 driver works with 0x149c controller under Win8.0 environment (+ patched acpi), so problem is deeper and 8.1 driver in different OS may have same issue. The first thing that comes to mind - DSDT, but on Linux open source usb3 driver (by Intel) uses acpi functions only in two cases - workaround for fewer Intel chipsets (Skylake and other), linux driver call special DSM methods to power up something in hardware, see xhci_pme_acpi_rtd3_enable() second is powering ports(?) usb_acpi_set_power_state(), many subcalls.

iyut, thanks a lot !