Mov AX, 0xDEAD
-
Posts
28 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Mov AX, 0xDEAD
-
-
6 hours ago, pappyN4 said:
catching up on TRIM in the deleted thread...
Is there a backport win8 storport? Or is it just the storpor8.sys that was being discussed? NTOSKRNL_Emu has missing dependencies with win8 storport.
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
-
11 hours ago, infuscomus said:
who made this one then? @daniel_k ?
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.
-
11 hours ago, Dietmar said:
The best nvme driver for XP is this one, ported from Win8.1 by @Mov AX, 0xDEAD
I didn't ported any Win8.1 NVMe drivers
-
start with saving crashdumps to disk, it can show stacktrace before crash
-
On 1/19/2022 at 4:31 PM, infuscomus said:
is IDA absolutely necessary? I don't have it installed, can I use windbg?
If IDA is necessary, can you help me setup windows 8.0 pre-install environment for debugging?
IDA debugger has same GUI, as standalone Disassembler
i dont have pre-install environment experience, debug config stored in BCD
-
On 1/17/2022 at 11:15 PM, infuscomus said:
Do you know of a way to properly fix AMLILoadDDB error?
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....
-
2 hours ago, infuscomus said:
can you do a hack in your USB driver to bypass USB\RESET_FAILURE for the 149C controller?
USB\RESET_FAILURE - what is it ?
-
2 hours ago, George King said:
@Mov AX, 0xDEADDo you have PDB for ACPI 5048?
No, PDB not published for early vista betas, PDB exist since v5342, maybe earlier, but i not tested
-
1 hour ago, infuscomus said:
I got very close to booting XP textmode setup with the server 2008 kernel and HAL - I got up to "Setup is Starting Windows" - no crash, but it stops there.
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)...
-
On 12/21/2021 at 1:34 AM, George King said:
Anybody tried this to boot XP in UEFI?
https://github.com/maharmstone/quibble
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
-
10 hours ago, infuscomus said:
Can you take a look at these functions in vista HAL to see if there is equivalent XP HAL code we can use to do the same thing?
No, i can't. it's your idea and only you must handle it
-
5 hours ago, infuscomus said:
what are you using this hex pattern check for?
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
-
23 hours ago, infuscomus said:
I'd like to try and use the function PoSetPowerState to set the powerstate of the 149c controller to D3 - then wait 1-2ms - then go back to D0.
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 ?
-
1 hour ago, infuscomus said:
Can you show me in C code how to check if the system has just been booted, and if so, tell the xhci controller to reset itself?
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
-
9 hours ago, infuscomus said:
I gave KeStallExecutionProccessor a try in ntoskrnl extender but without success -
No change in behaviour.
of course, you used "// Dummy entry"
use "DllInitialize ( // Main" because emu_extender is Export Driver, not a usual Driver
-
18 hours ago, infuscomus said:
It fails to start at boot every time consistently.
driver fails (error code) or hardware fails to detect ports/hub ?
-
34 minutes ago, infuscomus said:
I was looking through the XP HAL source code and saw there are USB related chipset hacks included called HalpStopohciInterrupt HalpStopUhciInterrupt etc..
I looked into the Windows 8.0 HAL and saw there is now a HalpStopXhciInterrupt included too, I know I'm just guessing here but this might be what is needed to fix problematic USB controllers.
Let see what hack do:
QuoteHalpStopOhciInterrupt(
Routine Description:
This routine shuts off the interrupt from an OHCI
USB controller. This may be necessary because
a BIOS may enable the PCI interrupt from a USB controller
in order to do "legacy USB support" where it translates
USB keyboard and mouse traffic into something that DOS
can use. (Our loader and all of Win9x approximate DOS.)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
QuoteDo you think you could try and implement this function into the XP HAL source code?
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 ?
-
14 minutes ago, infuscomus said:
I have an OEM SP3 XP ISO where I swapped out the kernel with my compiled version if you want to try it out? This version installs in a VM at least.
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(?) ...
-
21 minutes ago, infuscomus said:
So do you think the 149C controller is failing because of a missing function in our patched acpi.sys that the windows 8.0 acpi.sys has?
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.
-
3 minutes ago, infuscomus said:
First 0xDEADBEEF which I bypassed, but now I get BSOD 50 and 8E
any help to get your extender working with this?
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
-
33 minutes ago, canonkong said:
I already porting the usb driver from win8.1 and win10 1511, but they will code 10 error on win7. What I need to do with the inf file?
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
-
3 hours ago, infuscomus said:
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..
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.
-
13 hours ago, iyut said:
Hello colleagues,
here is an archive of forum's topic "Windows XP, 2003 x32 on modern hardware" (2018-2021) from win-raid.com, for the benefit of WinXP' admirers.iyut, thanks a lot !
XP/W2k3 x86 on Modern Hardware
in Microsoft Windows XP
Posted · Edited by Mov AX, 0xDEAD
@George King
This way you'l get another v6666 from 2018....