Windows 8/10 Client Support Fix

[Kimberly]

Anyone can release v62 localhost client for me with this fix , I've spent over 10 hours an didn't succeed on fixing this please.

I've told you many times this already, but v62 don't need a Windows 10 fix. All you need do is right click client > compatibility > Windows 98/me > apply

I have this automatically applied on my server with the installer and nobody has any issues.

 

[Isoprofit]

Thank you for this thread. I am struggling a bit with the compatibility fix for v75. The windowed fix seems to work perfectly, but I still remain to get the parameter is incorrect error no matter what I do. The dinput8.dll download link is broken, so I downloaded the one Kimberly linked in this thread. I hope that it is the correct one.

I have tried it with "Fill with NOP's" enabled and disabled, but I get "parameter is incorrect" every single time I run the client.

before

after

I have also tried Diamando's client with and without this client edit, but no luck.

The dinput9.dll thing br1337 posted about here gives me unspecified error.

I have also tried every compatibility mode.

Does anyone know what else I can try?

 

[Kyber]

@Eric: i'm using proxy dll for dinput8.dll and your method, and sometime i still get "parameter is incorrect" error. If i using only your method (not using proxy dll), yeah it worked every single time. So, is this method doesn't work with proxy dll? Have you ever try it with proxy dll?

 

[TacoBell]

I followed the guide as best as I could and even took the directions from Pipotron. "I changed JE v83client.fml.007964ED" to "JMP v83client.fml.007964ED" and the game doesn't execute. The forced window size you provided works flawlessly but changing the JE to JMP does NOT work and the client barely starts up at sometimes. Here's my file if you want to perform closer inspection. Every other step worked, changing the dinput8.dll gave me the korean error code and etc... This client just manages to crash every other time. It has a 1/3 chance of working successfully. Just to reiterate though, the forced window hack at startup works perfectly, thanks for it!!

End-note: My apologies for necro-posting.

You must be registered to see links

 

[Fenomenoide]

for v62, v75 and v83 there are clients with compatibility for windows 8/10
there are clients with compatibility for windows 8/10there are clients with compatibility for windows 8/10there are clients with compatibility for windows 8/10

 

[MechAviv]

I tried to make it work with v97 and it didn’t work..
I putted the .dll inside MS folder then I had the error message, after that I JMP’d and it bypassed this error message but nothing happening after clicking the localhost, any solution?

 

[Virtu]

<fantastic writeup>

Holy moly @Eric, that was a delightful read! This was the push I needed to go and try to fire up my old server-thing that has been collecting dust for a couple years now. So many memories crafting messy custom code for it!

Unfortunately for me, I'm not getting the incorrect parameter error... or any error message for that matter. No issues in JMPing the validation, but I don't think I'm even getting to DirectInput8Create with my client. This is a clean v111 install with the localhost from this post (thanks @sunnyboy for providing the idb!). When I place the patched dinput8.dll in the game's folder with the unmodified client I do get the korean message, but upon editing (or when the dll is not there and the game loads the system's default one) the game's process stays in the background indefinitely and requires manual termination.

I scoured each and every post in this thread and every other I could find, tried every imaginable solution with no success. Unlike the parameter error, this one isn't of the kind that eventually works if you keep trying... unless I've been terribly unlucky for the past 30+ attempts. At this point I knew I had to get off my butt and do some work to figure out what exactly is going on here.

Naturally, I tried to make some sense out of IDA's trace and debug output...

The debug output didn't look too interesting... but here it is anyways. It was fairly consistent between attempts: DEVOBJ.dll was always the last thing it successfully loaded, and from there it would start a couple threads that would live on forever.

Spoiler

400000: process D:\MapleStory\maplestory_111.1_local.exe has started (pid=1892)77CF0000: loaded ntdll.dllUnloaded Unloaded Unloaded 76610000: loaded C:\WINDOWS\SysWOW64\KERNEL32.DLL763A0000: loaded C:\WINDOWS\SysWOW64\KERNELBASE.dll73A40000: loaded C:\WINDOWS\SysWOW64\apphelp.dll72A80000: loaded C:\WINDOWS\SysWOW64\AcLayers.DLL74B80000: loaded C:\WINDOWS\SysWOW64\msvcrt.dll76760000: loaded C:\WINDOWS\SysWOW64\USER32.dll74B30000: loaded C:\WINDOWS\SysWOW64\win32u.dll77260000: loaded C:\WINDOWS\SysWOW64\GDI32.dll74730000: loaded C:\WINDOWS\SysWOW64\gdi32full.dll766E0000: loaded C:\WINDOWS\SysWOW64\msvcp_win.dll74DF0000: loaded C:\WINDOWS\SysWOW64\ucrtbase.dll75060000: loaded C:\WINDOWS\SysWOW64\SHELL32.dll76C80000: loaded C:\WINDOWS\SysWOW64\cfgmgr32.dll76580000: loaded C:\WINDOWS\SysWOW64\shcore.dll74A00000: loaded C:\WINDOWS\SysWOW64\RPCRT4.dll74710000: loaded C:\WINDOWS\SysWOW64\SspiCli.dll74700000: loaded C:\WINDOWS\SysWOW64\CRYPTBASE.dll771E0000: loaded C:\WINDOWS\SysWOW64\bcryptPrimitives.dll77290000: loaded C:\WINDOWS\SysWOW64\sechost.dll768E0000: loaded C:\WINDOWS\SysWOW64\combase.dll77710000: loaded C:\WINDOWS\SysWOW64\windows.storage.dll74890000: loaded C:\WINDOWS\SysWOW64\advapi32.dll770F0000: loaded C:\WINDOWS\SysWOW64\shlwapi.dll77CE0000: loaded C:\WINDOWS\SysWOW64\kernel.appcore.dll74DA0000: loaded C:\WINDOWS\SysWOW64\powrprof.dll76E30000: loaded C:\WINDOWS\SysWOW64\profapi.dll74910000: loaded C:\WINDOWS\SysWOW64\OLEAUT32.dll772E0000: loaded C:\WINDOWS\SysWOW64\SETUPAPI.dll73040000: loaded C:\WINDOWS\SysWOW64\MPR.dll66680000: loaded C:\WINDOWS\SysWOW64\sfc.dll73060000: loaded C:\WINDOWS\SysWOW64\WINSPOOL.DRV74010000: loaded C:\WINDOWS\SysWOW64\IPHLPAPI.DLL745D0000: loaded C:\WINDOWS\SysWOW64\bcrypt.dll72A60000: loaded C:\WINDOWS\SysWOW64\sfc_os.DLLFTH: (1892): *** Fault tolerant heap shim applied to current process. This is usually due to previous crashes. ***6EF40000: loaded C:\WINDOWS\SysWOW64\SortServer2003Compat.dll74B50000: loaded C:\WINDOWS\SysWOW64\IMM32.DLL77D23880: thread has started (tid=8908)77D23880: thread has started (tid=1212)77D23880: thread has started (tid=9652)74C40000: loaded C:\WINDOWS\SysWOW64\psapi.dll6E6E0000: loaded D:\MapleStory\nexonguard.aes74AC0000: loaded C:\WINDOWS\SysWOW64\ws2_32.dll6D3A0000: loaded C:\WINDOWS\SysWOW64\dinput8.dll70020000: loaded C:\WINDOWS\SysWOW64\netapi32.dll76E50000: loaded C:\WINDOWS\SysWOW64\ole32.dll74100000: loaded C:\WINDOWS\SysWOW64\version.dll726B0000: loaded C:\WINDOWS\SysWOW64\wininet.dll74040000: loaded C:\WINDOWS\SysWOW64\winmm.dll60000000: loaded D:\MapleStory\ijl15.dll10000000: loaded D:\MapleStory\nmcogame.dll21100000: loaded D:\MapleStory\mss32.dll73AE0000: loaded C:\WINDOWS\SysWOW64\WINMMBASE.dll1D0000: loaded C:\WINDOWS\SysWOW64\winmmbase.dllUnloaded C:\WINDOWS\SysWOW64\winmmbase.dll73160000: loaded C:\WINDOWS\SysWOW64\SHFOLDER.dll54D0000: loaded C:\WINDOWS\SysWOW64\winmmbase.dllUnloaded C:\WINDOWS\SysWOW64\winmmbase.dllPDBSRC: loading symbols for 'D:\MapleStory\maplestory_111.1_local.exe'...74680000: loaded C:\WINDOWS\SysWOW64\uxtheme.dll733A0000: loaded C:\WINDOWS\SysWOW64\dwmapi.dll5EE0000: loaded D:\MapleStory\nmconew.dllUnloaded D:\MapleStory\nmconew.dll5EE0000: loaded D:\MapleStory\nmconew.dll76F50000: loaded C:\WINDOWS\SysWOW64\NSI.dll72D10000: loaded C:\WINDOWS\SysWOW64\dhcpcsvc.DLL601C8BF: thread has started (tid=2168)601C8BF: thread has started (tid=14088)601C8BF: thread has started (tid=9692)745A0000: loaded C:\WINDOWS\SysWOW64\ntmarta.dllEnable Low Fragmentation Heap Failure(0x57)6BAE0000: loaded C:\Users\Virtu\AppData\Local\Temp\drc7207.tmp6E620000: loaded C:\Users\Virtu\AppData\Local\Temp\nst7227.tmp6D900000: loaded C:\Users\Virtu\AppData\Local\Temp\nst7238.tmp6C180000: loaded C:\Users\Virtu\AppData\Local\Temp\nst7248.tmp6C110000: loaded C:\Users\Virtu\AppData\Local\Temp\nst7269.tmp6C0A0000: loaded C:\Users\Virtu\AppData\Local\Temp\nst7279.tmp6BA00000: loaded C:\Users\Virtu\AppData\Local\Temp\nst728A.tmp6B990000: loaded C:\Users\Virtu\AppData\Local\Temp\nst729B.tmp6B920000: loaded C:\Users\Virtu\AppData\Local\Temp\nst72BB.tmp6B8B0000: loaded C:\Users\Virtu\AppData\Local\Temp\nst72CB.tmp6B730000: loaded C:\Users\Virtu\AppData\Local\Temp\nst72DC.tmp50C00000: loaded D:\MapleStory\PCOM.DLL74330000: loaded C:\WINDOWS\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.9317_none_508dca76bcbcfe81\MSVCR90.dll76B30000: loaded C:\WINDOWS\SysWOW64\MSCTF.dll729D0000: loaded C:\WINDOWS\SysWOW64\DEVOBJ.dll77D9A630: thread has started (tid=11056)

In the instruction trace, however, one can clearly pinpoint the infinite loop: it lies within C048F0 as it calls 4DA820 repeatedly as some integer v4 never becomes equal to 18. I've been staring at C048F0 for a while now and I'm at a loss, couldn't even name any of the variables yet. Has anyone had to face this bad boy already?

You must be registered to see links

.

Spoiler

I don't intend on giving up just yet, and should this end up working, I'd gladly share the resulting client for all 3 of you out there that still use v111 and are stuck with Windows 8 / 10. Literally any advice will be immensely appreciated!

 

[Eric]

@Virtu hmm, assuming it's the same process hang bug that I think it is, you may want to try finding HideDll and force return it at the functions entry point. With earlier big-bang clients at least, the issue was caused due to the *.nst temp file hiding done in CWvsApp::SetUp. Since that function is vmed to hell, you could at least access the HideDll function and return it at entry so that it doesn't affect the files.

You're probably right, you aren't getting to DirectInput8Create because you got stuck mid-way while executing CWvsApp::SetUp and are stuck. This is what used to happen for me as well and that's what I did to fix it, so I hope that helps.

 

[Virtu]

@Virtu hmm, assuming it's the same process hang bug that I think it is, you may want to try finding HideDll and force return it at the functions entry point. With earlier big-bang clients at least, the issue was caused due to the *.nst temp file hiding done in CWvsApp::SetUp. Since that function is vmed to hell, you could at least access the HideDll function and return it at entry so that it doesn't affect the files.

You're probably right, you aren't getting to DirectInput8Create because you got stuck mid-way while executing CWvsApp::SetUp and are stuck. This is what used to happen for me as well and that's what I did to fix it, so I hope that helps.

@Eric Thanks so much for the reply! Upon inspecting a little, I'm pretty confident this is the function we want:

Spoiler

I see it loads the copied dlls on return as well - so I believe we can't just force return any value and instead must load the file from the original path, is that correct?

EDIT: After some asm mumbo jumbo I got the function to look like this

Spoiler

Buuut I think I'm forgetting something important, as this modified function ends up not loading anything at all and crashing shortly after. Looking at the stack view in OllyDBG reveals that GetSystemDirectoryA does exactly as advertised, so ExistingFileName got assigned to "C:\WINDOWS\system32". Indeed I can't expect to be able to load a directory as a library.

Now to find out what sort of cryptic shenanigans are performed in the original function body to insert the filename part into the path... but gotta get some sleep first. I'll look into that soon.

I wonder why these nst files would cause so much trouble though? It seems they usually get loaded correctly in the vanilla client, and the infinite loop pops up somewhere after that. But it might just be me not seeing the big picture correctly.


EDIT2: Didn't have as much time to work on this as I wanted. I've just realized that they're just hiding away ws2_32.dll over and over with this function though. What the heck? oO

What's even more intriguing to me is that they do load the original ws2_32.dll to memory at some point before this function is called, so I shouldn't need to perform any additional loading and just force return like you said. Unfortunately it didn't behave as well as I wanted, and crashed with an invalid memory read exception on another subroutine after all the function calls were done. I'll see what I can do.


EDIT3: It's failing in somewhere related to WSAStartup, which seems to be how Windows Sockets initializes. Both the call to (what I'm assuming to be) HideDLL and the offending function are inside a long-butt subroutine that could perhaps be CWvsApp::SetUp? I don't have that one named yet. It contains the strings "Start Client Set Up.\r\n" and "\r\nClose This Window After 10Second...\r\n" near the end.

This is where they're being called:

Spoiler

And ThisCrashes doesn't look very pretty either. It's called multiple times after that one, for other libraries other than WS, I'm assuming. Here's the beginning of it.

Spoiler

 

[OnePunchMan99]

Most of the information in here is a bit above my head. I'm getting that -2xxxxxxxxxx error.

Any working fixes for this on Win10 1703?

 

[MechAviv]

I tried it on v97 in MapleShark I see getHello and crash info packets and then I am disconecting with the next error message:
java.io.IOException: An existing connection was forcibly closed by the remote host

any solution ?

 

[vTim]

Most of the information in here is a bit above my head. I'm getting that -2xxxxxxxxxx error.
Any working fixes for this on Win10 1703?

This is a WZ error. You have a corrupt WZ File.

I tried it on v97 in MapleShark I see getHello and crash info packets and then I am disconecting with the next error message:

java.io.IOException: An existing connection was forcibly closed by the remote host

any solution ?

Well I believe I had this problem occur to me on another version but I believe your .NET Framework needs to be like 4.6 another issue could be your client is receiving malicious data to the client. Also just in case you didn't, make sure your client and server have the same related connection.

PS: Personally for me I had to update my .NET Framework and I noticed my Ports were not forwarded so I then did this and everything worked​

​

 

[MechAviv]

This is a WZ error. You have a corrupt WZ File.

Well I believe I had this problem occur to me on another version but I believe your .NET Framework needs to be like 4.6 another issue could be your client is receiving malicious data to the client. Also just in case you didn't, make sure your client and server have the same related connection.

PS: Personally for me I had to update my .NET Framework and I noticed my Ports were not forwarded so I then did this and everything worked​

​

First of all thanks for your reply!

Now I doubled check my ports and they are okay,
about framework in downloaded 4.6 but still nothing.. starting the localhost and nothing happen..
picture:

You must be registered to see links

 

[vTim]

First of all thanks for your reply!

Now I doubled check my ports and they are okay,
about framework in downloaded 4.6 but still nothing.. starting the localhost and nothing happen..
picture:

You must be registered to see links

Honestly, if that did not work than my best guest whatever VPS or program you are using is blocking something that doesn't allow it to run the only other thing I would say is check your TCP Bindings and see if it allows to what you are running. I am not much of help towards this as it was a blocked port for me and I just managed to get it forwarded. I mean I can be looking at the wrong spectrum of what this error is but my last guess would be for you to check your TCP Bindings. Or try running this on a different machine and see if it works.

 

[Kyber]

Hi @Eric, I'm still face with "The parameter is incorrect" error on v62 client (i already do extractly the same step by step as your post).
- I already removed/bypassed client's check message (about detected a "hack program")
- I have put dinput8.dll into game folder(get it from win7 64bit in my vmware, the .dll's version is: 6.01.7600.16385)
- I have edit the client to be open in Window Mode by default
- I have tested on vmware win10 64bit and the error still there; tested on my local PC but still bug.
- I try to debug client with ollydbg, and realized that the problem still cause from dinput8.dll (even using dinput8.dll version 6.01.7600.16385). I have spent a day but cannot find out the solution to fix it.
What did i miss? I'm using win10 lastest update (build 1709). Did anyone still have this issue like me?
Edit:
Oh, look like @PrinceReborn have the same issue like me. And Eric already mentioned this issue in #18 and #21 . Do we have any new solution to fix this issue?

 

[anhtanh95]

Hi @Eric, I'm still face with "The parameter is incorrect" error on v62 client (i already do extractly the same step by step as your post).
- I already removed/bypassed client's check message (about detected a "hack program")
- I have put dinput8.dll into game folder(get it from win7 64bit in my vmware, the .dll's version is: 6.01.7600.16385)
- I have edit the client to be open in Window Mode by default
- I have tested on vmware win10 64bit and the error still there; tested on my local PC but still bug.
- I try to debug client with ollydbg, and realized that the problem still cause from dinput8.dll (even using dinput8.dll version 6.01.7600.16385). I have spent a day but cannot find out the solution to fix it.
What did i miss? I'm using win10 lastest update (build 1709). Did anyone still have this issue like me?
Edit:
Oh, look like @PrinceReborn have the same issue like me. And Eric already mentioned this issue in #18 and #21 . Do we have any new solution to fix this issue?

Through all the reasearch of Eric at #21. Yep, the root cause is from WINAPI GetModuleFileNameW , i dont know why it happened, but i have found the way to fix it. It failed randomly when dinput8 call GetModuleFileNameW(0x400000, L"", 260) at 2 address for example: "0x538F2D02" and "0x5390AD14"..
As the document on MSDN:

DWORD WINAPI GetModuleFileName(
  _In_opt_ HMODULE hModule,
  _Out_    LPTSTR  lpFilename,
  _In_     DWORD   nSize
);

Here is the result return when it failed.

ReturnAddr(538F2D02)
The module file name is: "". Result returned: 0

ReturnAddr(5390AD14)
The module file name is: "". Result returned: 0
[BUG] DInput8Create return failed.

Here is the result return when it success.

ReturnAddr(5DA02D02)
The module file name is: "C:\Users\Public\MapleV62\localhost.exe" . Result returned: 38

ReturnAddr(5DA1AD14)
The module file name is: "C:". Result returned: 3

As you can see, GetModuleFileNameW(0x400000, L"", 260) cannot return the path file name (the lpFilename = "" in this case) and return 0, so it made failed for DInput8Create. (Still don't know why it failed). After run client for 10+ time, i have realized that the first 4 bytes is change everytime you run the game, but the 4 last bytes never change. It is 0x2D02 and 0xAD14. So i have do more research with the result above:
1. I tried to modify and hardcode it to make lpFilename="C:\Users\Public\MapleV62\localhost.exe" and the return value is the length of lpFilename....and hell yeah.... it work perfectly every single time .
2.. As some research on the internet, it tried to make dinput8 to call GetModuleFileNameW(NULL, L"", 260); and it work perfectly too.
So, after 1. and 2., i has detouring the WINAPI GetModuleFileNameW to made it call this function:

You must be registered to see links

Here is the final result :laugh:

You must be registered to see links

 

[Eric]

@anhtanh95 Nice work, you figured it out! While this is one way to fix it, the method I used for Orion was actually hooking the entire dinput8 and patching the method calls from there. The beauty of detours!

 

[Halcyon]

Did Windows 1803 mess with v117.2? I think it got jacked again, or it might just be me..

 

[Eric]

Did Windows 1803 mess with v117.2? I think it got jacked again, or it might just be me..

some post-bb clients (like v117 for example) have an additional support issue with windows 8/10 too. are you getting the parameter error, or is the process hanging and crashing? the fix i've explained here will only apply to one of the problems with modern os's regarding dinput

 

[Halcyon]

some post-bb clients (like v117 for example) have an additional support issue with windows 8/10 too. are you getting the parameter error, or is the process hanging and crashing? the fix i've explained here will only apply to one of the problems with modern os's regarding dinput

No, just the hanging again, like post-1709.