Dietmar Posted March 15 Posted March 15 @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
reboot12 Posted March 15 Posted March 15 @Dietmar I use GUI FASM only. I also ask GPT https://www.elektroda.pl/rtvforum/topic4168197.html
reboot12 Posted March 15 Posted March 15 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
Dietmar Posted March 15 Posted March 15 @reboot12 Please put all information in a kd64.zip for ChatGPT Dietmar
Damnation Posted March 15 Posted March 15 @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?
Dietmar Posted March 15 Posted March 15 @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.
Damnation Posted March 15 Posted March 15 @Dietmar @reboot12 I successfully build an x64 kdstub.dll Though in kdstub.c there is a warning I disabled #pragma warning (disable : 4717) // kdstub.c(188) : warning C4717: '_KdInitializeLibrary' : recursive on all control paths, function will cause runtime stack overflow I wasn't sure how to resolve that. https://buzzheavier.com/risw492dkhzy
Dietmar Posted March 15 Posted March 15 @Damnation Have you tested it on XP 64bit, if it works for lan debug Dietmar
Damnation Posted March 15 Posted March 15 @Dietmar I don't have XP x64 installed. I just wanted to get it compiling for you.
reboot12 Posted March 15 Posted March 15 1 hour ago, Damnation said: https://buzzheavier.com/risw492dkhzy I can't download it. Upload it to a normal server, e.g. https://www.upload.ee/
Damnation Posted March 15 Posted March 15 @reboot12 https://www.upload.ee/files/19163520/KDNET-master-x64-16MAR2026.7z.html
K4sum1 Posted March 15 Posted March 15 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.
reboot12 Posted March 16 Posted March 16 (edited) 12 hours ago, Damnation said: https://www.upload.ee/files/19163520/KDNET-master-x64-16MAR2026.7z.html You compiled only 64-bit kdstub.dll for kernel 6.1 (Win7): 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 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 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 March 16 by reboot12
Dietmar Posted March 16 Posted March 16 @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
reboot12 Posted March 16 Posted March 16 (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 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 March 16 by reboot12
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now