Jump to content

Updated drivers for Windows XP SP3 and Windows 2003 SP2 (x32/x64) for modern hardware


Recommended Posts

Posted

@reboot12

Write to me here exact what you did in an kd64.txt file, tell which files you use, what is your compile environment.

Just ALL informations. All together, all files and kd64.txt put into a kd64.zip.

Doublecheck, that you dont miss any information.

I ask ChatGPT, where the error comes from

Dietmar


Posted
53 minutes ago, Dietmar said:

I already succeed to build an 9560.sys, which  send packages via Wlan 9560 TX for both different divices

64-bit please :)

Posted

@Dietmar

regarding reworking Mov Ax DEAD's KDNET to compile for x64, do you think the following would work?

replacing

__declspec(naked)

void

KdShutdownController ()

{

__asm jmp dword ptr [KdShutdownController_tramp];

}

with

__declspec(noinline)

void

KdShutdownController(void)

{

KdShutdownController_tramp(); // tail call candidate

}

 

and doing this for all the functions that use x86 inline assembly?

Posted

@Damnation

This is answer from ChatGPT, because I am not good in Assembler

No — not reliably, and not as written.

The original x86 code uses __declspec(naked) plus a raw jmp [tramp], which is a true thunk: it transfers control directly to the target without creating a new call frame. Replacing that with __declspec(noinline) and a normal C call changes the semantics unless the compiler happens to emit a tail jump. But __declspec(noinline) only disables inlining; it does not guarantee a tail call. In MSVC, tail calls are an optimization, and the newer [[msvc::musttail]] is the feature that enforces one, with strict requirements.

There is also a second problem: in the KDNET repo the trampoline globals are declared as void*, and the real exported functions do not all have the signature void(void). For example, KdShutdownController is VOID (PVOID Adapter), KdGetRxPacket returns NTSTATUS and takes four parameters, and several others also have non-void returns or arguments. The naked jump works regardless of prototype because it just transfers control, but a C wrapper must use the exact function-pointer type for each stub or you risk wrong x64 argument/return handling.

So:

KdShutdownController_tramp(); is not even correct as shown, because KdShutdownController_tramp is a void*, not a callable typed function pointer.

Even after fixing the type, a normal C wrapper may compile to call ... ; ret instead of a direct jmp.

__declspec(naked) itself is unavailable on x64 MSVC, so that original pattern cannot simply be carried over.

The safe choices are:

Best: write real x64 thunks in a separate MASM .asm file.

Acceptable if an extra frame is okay: use properly typed C wrappers for each export.

Example of the C-wrapper form that is type-correct:

static KD_SHUTDOWN_CONTROLLER KdShutdownController_tramp;

VOID KdShutdownController(PVOID Adapter)
{
KdShutdownController_tramp(Adapter);
}

And for a return value:

static KD_GET_RX_PACKET KdGetRxPacket_tramp;

NTSTATUS KdGetRxPacket(PVOID Adapter, PULONG Handle, PVOID *Packet, PULONG Length)
{
return KdGetRxPacket_tramp(Adapter, Handle, Packet, Length);
}

So my verdict is: not as a blanket “do this for all inline-asm functions.”
It may work for some wrappers after fixing all types and signatures, but it is not a drop-in replacement for the original naked jump thunks. If the goal is to preserve exact thunk behavior on x64, use assembly.

 

Posted

Been meaning to make this post for a while, but when I get around to doing it, I just feel so tired, like right now. idk why I've just been feeling so tired lately, I feel like I'm doing barely anything in a day. I want to make this post now rather than later so I'm doing it now.

I finally got around to testing the drivers on my B550 Tomahawk, I wanted to test RTL8125 drivers on the well RTL8125, and the I225 drivers on my I226-V, and I figure I'd test both in the same system to make it easier. I have no custom install disk of XP x86 that will just work on Ryzen with ACPI patch and USB and such, and I do not feel like fussing with trying to make my own, so I just used the patched version of NT 5.1 XP from the Universal NT Installer project. Installed to a FAT32 partition and just used default settings and boot options. I installed some other drivers before I made the vids, but I also tested with a fresh install with no other drivers and saw the same behavior.

With the RTL8125, I initially get no connectivity for like 10 seconds or so, until I get a DRIVER_IRQL_NOT_LESS_OR_EQUAL BSOD, 0x000000D1 from NDIS.sys. After reboot the device doesn't start with a code 39.

https://awau.moe/9C7WWYd.mp4

With the I226-V, I have to manually install the driver, but it works. In this video, I install all three, however it detects a 2.5 Gbps link when it's only a gigabit link. Speeds also leave a lot to be desired, I know fast.com is not scientific, but I don't have a 2.5G link to test where this PC is and it still gives a good ballpark speed. Also installing i225IRQlaaastfree at the end results in a 0x40000080 BSOD.

https://awau.moe/6nNts9b.mp4

After reboot, if I try reinstalling the RTL8125 driver, it no longer crashes, and the error code goes away but I still have no connectivity. I also reinstall the i225IRQlaaastfree driver, and the error code also goes away, but it works here. I'm not sure if that i225IRQlaaastfree BSOD comes from switching the driver or if the first install does that though, haven't tested that specifically.

https://awau.moe/9fQhjVU.mp4

Lastly, here's the I226-V on Windows 10 showing the correct 1.0 Gbps link and giving me good speeds in the test.

https://awau.moe/4sbghGp.mp4

One more thing, I noticed there also was a NT 5.2 x86 (Server 2003 x86) in the Universal NT Installer but themed to be like XP. So I tried that too, however both drivers refuse to install on it and idk why. Only "The parameter is incorrect." with nothing else to go off of.

comp1.jpg.095518106cea7d52ac5d85582060f7c2.jpg comp2.jpg.8372d71a2f9a39041bcd124d25875f68.jpg

Posted (edited)
12 hours ago, Damnation said:

You compiled only 64-bit kdstub.dll for kernel 6.1 (Win7):
kdstub61.png

I read this tutorial: https://github.com/MovAX0xDEAD/KDNET/blob/master/README.md

I want to use drivers with Win 8.1, so I want use OPTION A
Option A: Original files from Windows 8.1 (boot.wim/install.wim or KB3000850, only kdnet.dll version 6.3.9600.17276 ENGLISH supported)

What version of Win 8.1 are these files? Where to download it, because I don't have it - please give me the link. If anyone has 64-bit Win 8.1 6.3.9600.17276, please unpack these files and share:

 kdnet.dll
 kd_02_14e4.dll` - Broadcom         (v6.3.xxxx)
 kd_02_10df.dll` - Emulex           (v6.3.xxxx)
 kd_02_19a2.dll` - Emulex           (v6.3.xxxx)
 kd_02_8086.dll` - Intel            (v6.3.xxxx)
 kd_02_1969.dll` - Qualcomm Atheros (v6.3.xxxx)
 kd_02_10ec.dll` - Realtek          (v6.3.xxxx)
 kd_02_15B3.dll` - Mellanox         (v6.3.xxxx)

I searched the BetaArchive Database for 6.3.9600.17xxx and there are no such versions :crazy:
6-3-9600-17.png

According to https://betawiki.net/wiki/Windows_8.1 there was no such version:

Update 1
Available build 9600.17031.winblue_gdr.140221-1952
Update 2
Available build 9600.17238.winblue_gdr.140723-2018
Update 3
Available build 9600.17415.winblue_r4.141028-1500
Available build 9600.18009.winblue_ltsb.150810-0600

I downloaded and unpacked also 3 files from Update for Windows 8.1 for x64-based Systems (KB3000850) but no any kd*.dll files :realmad::crazy:

  • Windows8.1-KB3000850-x64.msu
  • Windows8.1-KB3003057-x64.msu
  • Windows8.1-KB3014442-x64.msu

How to create a patched 64-bit kdnet.dll file???
https://github.com/MovAX0xDEAD/KDNET/blob/master/src/fasm patch/_merge.cmd

Patch kdnet.dll 32-bit version:

chsize32.exe kdnet.dll 76432
fasm         KDNET_PATCH.ASM KDNET.BIN
copy /B /Y   kdnet.dll+KDNET.BIN+dummy kdnet.dllnew
del /Q       kdnet.dll_old
ren          kdnet.dll kdnet.dll_old
ren          kdnet.dllnew kdnet.dll
chsize32.exe kdnet.dll 77824
checksum.exe kdnet.dll
  • to what size should the original kdnet.dll 64-bit file be cropped with the chsize32 command?
  • we need 64-bit code KDNET_PATCH.ASM for make KDNET.BIN
  • dummy file for 32-bit has 688 bytes - do we use the same one or should it have a different size for 64-bit?
  • what should be the target size of the patched kdnet.dll file, which we set in the last step using chsize32 ?
Edited by reboot12
Posted

@reboot12

For XP SP3 I have a win8.1 x86 version with this files 6.3.9600.17276 (winblue_r2.140808-0433)

64 bit win8.1 I never testet.

For the 9560 Wlan card I have also a crazy problem:

All seems to be nice, I can already send packages but not get. I fetch the firmware for this card from Linux and I test,

that this correct(!) firmware for this chip is loaded to 100% correct to memory at the right place.

But I cant boot this firmware.

Now I think that maybe ME, ULP, or D3 sleep is blocking the boot of this firmware on an unauthorized driver under XP SP3.

This I will check today

Dietmar

 

Posted (edited)
1 hour ago, Dietmar said:

For XP SP3 I have a win8.1 x86 version with this files 6.3.9600.17276 (winblue_r2.140808-0433)

What version is this? Write exactly the full name of the ISO file, system name (RTM or Update), where you downloaded it - maybe there is also a link to the 64-bit version?

P.S. I don't understand why there is no such version on BetaWiki or in the BetaArchive Database :dubbio:

EDITED

I found info on https://ultradefinitive-build-list.fandom.com/wiki/OSes/Windows/8.1

winblue_r2.140808-0433 > Win8.1 Update 2 Post-RTM

What KBxxxx update are the files 17276 in this version???

Edited by reboot12

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...