Welcome!

Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!

Join Today!

Windows 8/10 Client Support Fix

Joined
Jan 18, 2010
Messages
3,109
Reaction score
1,139
After a few hours of debugging, some research, and digging heavily all throughout the client, I've managed to not only figure out (at least for myself) the causes behind the infamous "The parameter is incorrect" error seen on modern operating systems, but also how to effectively fix the issue for any and all client versions that the error occurs on (up to v13x~v14x iirc).

Before I get started, I'd like to point out and note a few things. First, the issue and exception along with where it's located. So by now we all know it by "Parameter is incorrect", but the actual error code number is -2147024809. Let's take a look at the game application's initialization of DirectInput8.

Code:
v9 = DirectInput8Create(v8, 2048, "0€y¿:H¢Mª™]dí6—", v3 + 4, 0);
if ( v9 < 0 )
	_com_raise_error(v9, 0);

Now let me fix it up for you:
Code:
hr = DirectInput8Create(hModule, 2048, &_IID_IDirectInput8A, &this->m_pDI, NULL);
if ( hr < 0 )
	_com_raise_error(hr, 0);

All we see here is the client creating the m_pDI IDirectInput interface with a 2048 (2GB) minimum RAM requirement of the application. At first hand you'd think all is well until you actually debug and breakpoint this area. Well, with that in mind, we can remember that error code. We know it's -2147024809 which actually converts to 80070057 (base16/hexadecimal). With that said, knowing the client is going to use hexadecimal values and this one is likely to be pretty unique, we could always search the client for this exact AoB. We'll only find a limited amount of results (like we had hoped), however none of these actually throw the exception or come close to it when we trace and breakpoint the source of the issue. This leaves us right back where we started, with something wrong in CInputSystem::Init, specifically from DirectInput8Create.

Well, what is DirectInput8 returning at "v9"? It's actually returning a HANDLE Result, and a commonly known HRESULT is in fact 0x80070057, or E_INVALIDARG. This means that the error involved actually has absolutely nothing to do with the physical application itself, as it is an external library call that returns an E_INVALIDARG result. Since the result is clearly < 0, it'll call to com_raise_error to trigger a CxxThrowException which will generate the StringPool that prints both the name and error code in the MapleStory OK window as it crashes. Now that we have some little information on the error, we know that the message and problem we're having is not specific to MapleStory like some of our other error codes.

Next, the problem and the workarounds available. Well by now we know the issue is specific to DirectX, and by some quick searching of the error 80070057 we'll find that the issue is actually seen throughout many other games and applications. Keeping in mind that the issue only occurs on Windows 8 and above, we know it's some newer platform affecting it. It turns out that around August 2012, Microsoft had officially deprecated the external calls to all of the DirectX 9 functions that the client utilizes, and upon doing so killed the compatibility on a lot of these older game clients that use them. At the same time, all new modern operating systems (since the start of the official release of Windows 8) had started using DirectX 11.1 and above. Well, the issue that had been brought up a few times was that it's just a multi-threading problem, and running it a few more times would generally fix whatever problem people were having. This is where the use of the current workaround released is involved. What we did to simply ignore and throw away the error ever occurring was simply call a code-caved function to cause the thread to sleep for two seconds, and jump back. Upon doing so, we assemble over the conditional call to the DirectInput's COM error exception. This means that we'll indeed get rid of the parameter is incorrect error, but doesn't mean that we took care of the issue.

So I tested out the client with just simply sleeping and jumping back, removing the COM error exceptions. It seems to work most of the time, but very commonly the client will continue to fault and terminate. However, since we have removed the COM error exceptions, we don't see any "parameter is incorrect" anymore; the client process just ends and you have to re-run the game. It's because of this that I needed to look more into this myself so that I could find a fix that would for sure make the client no longer have issues executing the external calls. Since I knew the cause was coming from DirectInput8Create, I traced the function to it's import at dinput8.dll which was the first thing I thought of. I already had olly open so all I needed to confirm was where the module for dinput8.dll was located, and since it was in system32 I knew that definitely had to be the issue. So using the File Versions to compare the two, we'll notice that all of us Windows 7 users where the game runs just fine use DirectX 6.01.7600.16385. From there, I compared that to the other OS's, where people on 8 had 6.02.9200.16384 and people on 10 had 10.00.10240.16384.

To confirm if this were the source of the problem, I made a backup of my current build of DirectX and replaced it in system32 with the working version of 6.01.7600.16385. After executing a clean barebones client with no checks that would constantly parameter me, it worked flawlessly. However, we clearly don't want to be replacing system32 files in order to play the game! After restoring my original dinput8.dll and trying the same client again after success, it began to parameter error me again and again. So, I confirmed that dinput8.dll was the issue and by using an older build of DirectX with non-deprecated calls the client would launch just fine on any OS.

How can we implement or fix it then? Very simple actually. The same dinput8.dll that we replaced in our system32 to confirm if it worked or not, we'll just place it inside of our MapleStory folder. This way, when we execute the client, it'll use the one in the current directory and ignore the one in system32 upon runtime. Sure, this is indeed the fix for it all, BUT Nexon hates making life easy for us! If all you do is paste in the dinput8.dll file into your MapleStory folder, you'll get a korean (if you're on the codepage) error like this:
GnxRLhJ - Windows 8/10 Client Support Fix - RaGEZONE Forums

In translation, this just means that the client has detected a "hack program" on the directory. Yep, Nexon has hard-coded checks in the client for the list of modules they use, and if they find any of those files within your directory the client will display a MessageBox with this error.

Alright, so down to the fix. First, you might as well download dinput8.dll to place into your MapleStory folder. You can download it Next, we're going to need to do some client editing. One thing I can say is that the client modification done here is extremely simple and anyone can do it.

Finding the function is easy but I'll provide addys for the common versions anyways.

Code:
v62 -> 00672F10 (JE to JMP)
v75 -> 006DF82D (JE to JMP)
v83 -> 00796357 (JE to JMP)
v111 -> 0085EC08 (JMP 0085EE88)

How to find it? Using IDA, open the Strings window and sort it by String. Go to the very bottom and you'll find the following string:
LmVmCwT - Windows 8/10 Client Support Fix - RaGEZONE Forums


Double-click on it to go to the dword value in IDA-View:
HD0Re2M - Windows 8/10 Client Support Fix - RaGEZONE Forums


Notice on the right there's a DATA XREF that says ZAPILoader? For you it'll be sub_XXXXXX, but double-click on it. It'll lead you to the ZAPILoader function with the checks. I would've included v117, but the sub is virtualized so you won't have any XREF's available to find it. If you want it anyways, the address of the function in v117 is 0089ECA0. You'll have to debug and find the address to jump yourself for that one :p

aaand that's it! Simply put, we add the working non-deprecated dinput8.dll into our MapleStory folder and bypass the client checks that prevent it.

Enjoy!

- Eric
 

Attachments

You must be registered for see attachments list
Last edited:
Junior Spellweaver
Joined
Aug 5, 2011
Messages
132
Reaction score
10
I really enjoy reading about the journey you take to arrive at your solutions lol.
I suspected it might be something like this, but I didn't care enough to go as deep as you did. :')
Thank you for the documentation and fix. ^_^
 
Moderator
Staff member
Moderator
Joined
Jul 30, 2012
Messages
1,102
Reaction score
432
I am still curious but how come in v0.62 the error doesn't occur in Windows 98/me compatibility mode? What exactly is different over the other ones (where it still happens) compared to 98/me? Also how come this only works on v0.62 where in v0.75+ it still happens (Parameter is Incorrect) even in 98/me mode?

Probably no answer on that but things like that make me always curious =P

Great job once again. Solutions like this is what keeps this game (Private Server scene) alive, seeing Microsoft is not willing to fix it.
 
Junior Spellweaver
Joined
Sep 9, 2015
Messages
132
Reaction score
10
If someone who knows how to use client editing and may release common versions clients with this release it will be highly appreciated.

Good job as always, Eric. You excel in everything. :p
 
Initiate Mage
Joined
Aug 10, 2016
Messages
32
Reaction score
0
Good Job, Eric :) Immediately i have tried v111 with win10.
Unfortunately. it keeps throws 0xC0000005 error rather than the invalid parameter error and does not get in game at all.
And the dinput8.dll you attached is 64bit ,MapleStory will not actually load it Would you show me a way how to fix it? Eric
 
Joined
Jan 18, 2010
Messages
3,109
Reaction score
1,139
I am still curious but how come in v0.62 the error doesn't occur in Windows 98/me compatibility mode? What exactly is different over the other ones (where it still happens) compared to 98/me? Also how come this only works on v0.62 where in v0.75+ it still happens (Parameter is Incorrect) even in 98/me mode?

Probably no answer on that but things like that make me always curious =P

Great job once again. Solutions like this is what keeps this game (Private Server scene) alive, seeing Microsoft is not willing to fix it.

Good question. I've been wondering this myself and if it has some client checks for something with privileges or compatibility. I haven't seen anything major changed in v62 versus 75+ when it comes to any actual functions, so it may be something hidden that I'm not directly finding..

Good Job, Eric :) Immediately i have tried v111 with win10.
Unfortunately. it keeps throws 0xC0000005 error rather than the invalid parameter error and does not get in game at all.
And the dinput8.dll you attached is 64bit ,MapleStory will not actually load it Would you show me a way how to fix it? Eric

Not sure because after v100+ the game client's API loader functions had changes. All clients up until then follow the same code and instructions that needed to be modified, but when I checked v111 it didn't. The error thrown has to be because of when/where I jumped though. You can trial and error it, but I have no v111 besides an IDB so I have nothing to test/confirm for that version :p. Indeed it is, but if you'd like the 32bit version of the DLL, I have that one uploaded on my MEGA too. You can download it
 
Junior Spellweaver
Joined
Jul 6, 2008
Messages
170
Reaction score
17
This is really interesting, thank you for spending time researching the issue. Unfortunately the fix doesn't seem to be working for me with a v0.83 client.

Adding the .dll into the MapleStory folder does cause for the Korean error message to appear, and editing the client in Ollydbg at the location mentioned makes the error message go away... However the client still produces 'The Parameter Is Incorrect' error. I've tried both x64 and x86 versions of the .dll file.

I've also tried starting the client with SimpleProgramDebugger attached to make sure it is loading the dinput8.dll file from the MapleStory folder - which it is. Including the times when the client throws 'The Parameter Is Incorrect' error.
 
Joined
Jan 18, 2010
Messages
3,109
Reaction score
1,139
This is really interesting, thank you for spending time researching the issue. Unfortunately the fix doesn't seem to be working for me with a v0.83 client.

Adding the .dll into the MapleStory folder does cause for the Korean error message to appear, and editing the client in Ollydbg at the location mentioned makes the error message go away... However the client still produces 'The Parameter Is Incorrect' error. I've tried both x64 and x86 versions of the .dll file.

I've also tried starting the client with SimpleProgramDebugger attached to make sure it is loading the dinput8.dll file from the MapleStory folder - which it is. Including the times when the client throws 'The Parameter Is Incorrect' error.

Hmm weird.. I have yet to get this error. What OS are you using, and is it x86 or x64? What localhost are you using, and did you do any other changes to it? I'll see if I can trace or replicate the error on whatever localhost you're using so that I can figure it out and fix it.
 
Junior Spellweaver
Joined
Jul 6, 2008
Messages
170
Reaction score
17
Hmm weird.. I have yet to get this error. What OS are you using, and is it x86 or x64? What localhost are you using, and did you do any other changes to it? I'll see if I can trace or replicate the error on whatever localhost you're using so that I can figure it out and fix it.

I'm using Windows 10 Home x64 (Build 14393), and I've also tried it on Windows 8.1 x64. I am attempting this fix with the clean v0.83 localhost from http://forum.ragezone.com/f425/maplestory-client-archive-gmsdlreborn-1101897/ with the .dll linked in this thread. I've tried both the x86 and x64 versions of the .dll, and have tried even older versions of the .dll with no success thus far. Would be great if you don't mind having a look into it, as this issue is the bane of v0.83 servers right now for modern OS's, and any help is greatly appreciated.
 
Skilled Illusionist
Joined
Apr 26, 2015
Messages
302
Reaction score
77
I'm using Windows 10 Home x64 (Build 14393), and I've also tried it on Windows 8.1 x64. I am attempting this fix with the clean v0.83 localhost from http://forum.ragezone.com/f425/maplestory-client-archive-gmsdlreborn-1101897/ with the .dll linked in this thread. I've tried both the x86 and x64 versions of the .dll, and have tried even older versions of the .dll with no success thus far. Would be great if you don't mind having a look into it, as this issue is the bane of v0.83 servers right now for modern OS's, and any help is greatly appreciated.

Did you try to hook the call to DirectInput8Create and add a Sleep Windows API call of some seconds before calling it?

It solved the problem on my v90 localhost and also v83.
 
Junior Spellweaver
Joined
Apr 30, 2012
Messages
100
Reaction score
40
Did you try to hook the call to DirectInput8Create and add a Sleep Windows API call of some seconds before calling it?

It solved the problem on my v90 localhost and also v83.

I've also tried Eric's proposed fix on a "clean" v83 client and it didn't work; from my understanding the sleep call is a workaround, not a fix (albeit an effective one). I could do some troubleshooting if anyone else has had success.
 
Joined
Jan 18, 2010
Messages
3,109
Reaction score
1,139
I'm using Windows 10 Home x64 (Build 14393), and I've also tried it on Windows 8.1 x64. I am attempting this fix with the clean v0.83 localhost from http://forum.ragezone.com/f425/maplestory-client-archive-gmsdlreborn-1101897/ with the .dll linked in this thread. I've tried both the x86 and x64 versions of the .dll, and have tried even older versions of the .dll with no success thus far. Would be great if you don't mind having a look into it, as this issue is the bane of v0.83 servers right now for modern OS's, and any help is greatly appreciated.

Alright, may I ask how often you get the parameter error thrown? Is it every time? I used the same client and tried to achieve the parameter error, yet I never get it.

However, I think I might possibly know why it's occurring. By preference (and an easier way for me to debug), I modify DirectX's flags so that I can initially launch the application in a Window Mode setting. This is the only other modification I've done to the client which is why I believe it is what helps fix it. After thinking about it, br1337 pointed out the commonly used Sleep delay that will thread sleep the client for about 2 seconds or so. If we think about this, the 2 second duration that we are doing a Sleep on is around the same time it takes for your graphics card to transition your computer's resolution into the 800x600 and ready it before the Gr2D starts drawing and such. Well, because I'm always opening my test client(s) inside of windows mode, the graphics never have to be adjusted before Gr2D creates it's DirectInput. Instead, the application immediatly loads after being executed and uses the new dinput8.dll file for the fixed calls. I'm guessing that because I do that, I guarantee the client to always launch before the calls to DirectInput have been made, and this is why I don't get parameter.

I didn't think that could actually be the problem, but seeing as a delay between when the client switches your resolution to when it calls a DirectInput8 is where things will often fail, it might be. That'd also be funny if this was why Nexon began always initializing the client in a window mode upon startup, and after the client has initialized the Gr2D user's can then ALT+Enter into Full Screen.

Aaanyways, you can try and confirm my theory and see if that's actually the cause or not. Assuming you have the dinpu8.dll checks JMP'd in the clean client already, go to address 009F7A9B in your v83 localhost and modify the instruction to MOV EAX, 0. Save those changes and try it out again, see if it works or not.
 
Junior Spellweaver
Joined
Jul 6, 2008
Messages
170
Reaction score
17
Alright, may I ask how often you get the parameter error thrown? Is it every time? I used the same client and tried to achieve the parameter error, yet I never get it.

However, I think I might possibly know why it's occurring. By preference (and an easier way for me to debug), I modify DirectX's flags so that I can initially launch the application in a Window Mode setting. This is the only other modification I've done to the client which is why I believe it is what helps fix it. After thinking about it, br1337 pointed out the commonly used Sleep delay that will thread sleep the client for about 2 seconds or so. If we think about this, the 2 second duration that we are doing a Sleep on is around the same time it takes for your graphics card to transition your computer's resolution into the 800x600 and ready it before the Gr2D starts drawing and such. Well, because I'm always opening my test client(s) inside of windows mode, the graphics never have to be adjusted before Gr2D creates it's DirectInput. Instead, the application immediatly loads after being executed and uses the new dinput8.dll file for the fixed calls. I'm guessing that because I do that, I guarantee the client to always launch before the calls to DirectInput have been made, and this is why I don't get parameter.

I didn't think that could actually be the problem, but seeing as a delay between when the client switches your resolution to when it calls a DirectInput8 is where things will often fail, it might be. That'd also be funny if this was why Nexon began always initializing the client in a window mode upon startup, and after the client has initialized the Gr2D user's can then ALT+Enter into Full Screen.

Aaanyways, you can try and confirm my theory and see if that's actually the cause or not. Assuming you have the dinpu8.dll checks JMP'd in the clean client already, go to address 009F7A9B in your v83 localhost and modify the instruction to MOV EAX, 0. Save those changes and try it out again, see if it works or not.

Thank you both for your replies,

To answer your questions; The parameter error gets thrown just as many times as before, although admittedly it is hard to compare due to the randomness of the error in the first place. I've been able to open a clean v0.83 client 50 or so times in a row without getting it, but then can go 50 times in a row and get the error every single time, but of course this is quite rare and you would be out of your mind to continue trying to open it after that many attempts without trying something like rebooting your computer. As you probably know, there seems to be correlation between the error and what other applications you have open on your computer. Closing Skype, Steam and Chrome can often cause the error to go away. However I would say on average I would get the error about 20% of the time with a clean client, and with the fix provided, I would say I have still been getting the error about the same percentage of the time.

I have now tried your and br1337's suggestion and changed 009F7A9B to MOV EAX,0 within the client, and unfortunately I still get the parameter error. Again this has been tried on both Windows 10 x64 and Windows 8.1 x64.

I have uploaded the client and .dll that I have been using if you wish to investigate further:

v0.83 clean client with dinput.dll JMP & windowed mode hack:
dinput.dll:
 
Skilled Illusionist
Joined
Apr 26, 2015
Messages
302
Reaction score
77
Thank you both for your replies,

To answer your questions; The parameter error gets thrown just as many times as before, although admittedly it is hard to compare due to the randomness of the error in the first place. I've been able to open a clean v0.83 client 50 or so times in a row without getting it, but then can go 50 times in a row and get the error every single time, but of course this is quite rare and you would be out of your mind to continue trying to open it after that many attempts without trying something like rebooting your computer. As you probably know, there seems to be correlation between the error and what other applications you have open on your computer. Closing Skype, Steam and Chrome can often cause the error to go away. However I would say on average I would get the error about 20% of the time with a clean client, and with the fix provided, I would say I have still been getting the error about the same percentage of the time.

I have now tried your and @br1337's suggestion and changed 009F7A9B to MOV EAX,0 within the client, and unfortunately I still get the parameter error. Again this has been tried on both Windows 10 x64 and Windows 8.1 x64.

I have uploaded the client and .dll that I have been using if you wish to investigate further:

v0.83 clean client with dinput.dll JMP & windowed mode hack:
dinput.dll:
Mind sharing this windowed mode hack?

When I arrive in home I will try to check what exactly I've done to fix the problem in v83.
 
Joined
Jan 18, 2010
Messages
3,109
Reaction score
1,139
Mind sharing this windowed mode hack?

When I arrive in home I will try to check what exactly I've done to fix the problem in v83.

Read the bottom of my post. It's not really a "hack", just a flag that makes the application run in Window Mode instead of a Full Screen like GMS does. You can look into the client/Gr2D/DirectX on that, but it's just changing the 0x10 flag to 0x0.

Also PrinceReborn at least on my Windows 10 x64 Alienware with Chrome open and running, Skype all active, CE and all kinds of other apps in the background, I still have yet to get a parameter error using your client. I guess it just really depends on the computer because my friends and I don't seem to run into issues. However, like you said, it'll for sure happen if you run the client so many times it triggers it. I believe on a normal basis of running the client it should work every time, and involves much less client editing in the long run.

One other thing I'm not sure I have mentioned about the other workaround is that it can cause an exception in the client where it doesn't execute CoInitialize and will throw that error instead of parameter. I've noticed this when testing it out with both my fix AND the code-cave in the client, and it goes away when I only use the dinput8.dll trick.
 
Junior Spellweaver
Joined
Jul 6, 2008
Messages
170
Reaction score
17
That's very strange that you and your friends are not having issues with the parameter error with this dinput8.dll fix while it seems to have made no difference to me and my friends that have tried it.

I've been trying to find patterns of when the client throws the error compared to when it doesn't while monitoring the executable with SimpleProgramDebugger and have found that when the parameter error is thrown there is always an exception immediately after loading HID.dll and before loading SOUND_DX8.dll. I have no idea if this even means anything, but it does seem pretty strange that it happens at this point in time during the client load, and nowhere near where dinput8.dll is loaded.

Here's a report of a successful client load:
And here's a report of when the client throws the parameter error:
 
Joined
Jan 18, 2010
Messages
3,109
Reaction score
1,139
That's very strange that you and your friends are not having issues with the parameter error with this dinput8.dll fix while it seems to have made no difference to me and my friends that have tried it.

I've been trying to find patterns of when the client throws the error compared to when it doesn't while monitoring the executable with SimpleProgramDebugger and have found that when the parameter error is thrown there is always an exception immediately after loading HID.dll and before loading SOUND_DX8.dll. I have no idea if this even means anything, but it does seem pretty strange that it happens at this point in time during the client load, and nowhere near where dinput8.dll is loaded.

Here's a report of a successful client load:
And here's a report of when the client throws the parameter error:

Well, that's not surprising that it's failing around there because that is called in dinput8.dll, which is the root cause of everything. I'll look into and debug/trace the physical dinput8.dll file and begin looking into what Microsoft has fucked up on. Anyway, after the call of DirectInput8Create, it'll later call the below function which is where your program is debugging all the load calls from.

Code:
HMODULE __cdecl ExtDll_Init()
{
  HMODULE result; // eax@1

  g_hinstHid = ExtDll_LoadDll(L"HID.DLL", (int)&g_hiddll, 22, (int)g_hiddll_fn);
  g_hinstSetupapi = ExtDll_LoadDll(L"SETUPAPI.DLL", (int)&g_setupapi, 18, (int)g_setupapi_fn);
  g_hinstwinmmdll = ExtDll_LoadDll(L"WINMM.DLL", (int)&off_C361660, 7, (int)off_C3611A0);
  result = ExtDll_LoadDll(L"USER32.DLL", (int)&g_user32, 2, (int)g_user32_fn);
  g_hinstuser32 = result;
  return result;
}

This is where dinput8 is initializing all of its external DLL's where HID (Human Interface Device) is loaded from. Makes sense because that's what will load your Mouse/Keyboard from USB input.

Heading to bed because I got early class tomorrow, but I'll look into it all tomorrow!

UPDATE: Alright, traced and pinpointed the root cause of the parameter error for all of our versions that seem to have it. It all boils down to _hresValidInstanceVer_, a call inside of dinput8.dll. This is the function:

PHP:
signed int __stdcall _hresValidInstanceVer_(HMODULE hModule, unsigned int a2)
{
  signed int result; // eax@4
  WCHAR Filename; // [sp+0h] [bp-Ch]@2
  unsigned int v4; // [sp+8h] [bp-4h]@1
  int v5; // [sp+Ch] [bp+0h]@1

  v4 = (unsigned int)&v5 ^ __security_cookie;
  if ( hModule && GetModuleFileNameW(hModule, &Filename, 3u) )
  {
    if ( a2 == 2048 )
    {
      result = 0;
    }
    else
    {
      if ( a2 )
        result = a2 < 2048 ? -2147023743 : -2147023746;
      else
        result = -2147024875;
    }
  }
  else
  {
    result = -2147024809;                       // E_INVALIDARG
  }
  return result;
}

Tested and confirmed that this exact function is what will throw that HANDLE result on both v83 and v90. Later today when I got time I'll test what it's failing on here, whether the HANDLE is NULL, or if GetModuleFileNameW fails. From there, I should be able to further understand the cause and fix the issue. Just putting this out there for anyone wishing to further investigate and to finally clarify what and where things go wrong!

Wish to try it out yourself? Sure! I've modified dinput8.dll to make this specific function's return result that you see above to return 0x80070060 instead of 0x80070057. Place into your MapleStory folder and run your client like you normally would. Instead of getting a parameter error, you should instead get the following error:
6cA8Wtv - Windows 8/10 Client Support Fix - RaGEZONE Forums


If you see the error above, then it means that the initial conditional inside the above function has returned false, and has thus thrown E_INVALIDARG; your parameter error.
 

Attachments

You must be registered for see attachments list
Last edited:
Skilled Illusionist
Joined
Apr 26, 2015
Messages
302
Reaction score
77
On the fix I did for v90 I added 5 seconds delay in order to prevent the errors.
 
Junior Spellweaver
Joined
Jul 6, 2008
Messages
170
Reaction score
17
I've now tried adding the delay to the DirectInput8Create call and dinput8.dll does definitely load later on now, just before HID.dll with it having a 2 second delay, but the parameter errors still persist with no improvement. I've also tried larger delays but to no avail. Also using the modified dinput8.dll that you linked Eric

Eric - Windows 8/10 Client Support Fix - RaGEZONE Forums
 
Back
Top