- 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.
Now let me fix it up for you:
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:
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
Finding the function is easy but I'll provide addys for the common versions anyways.
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:
Double-click on it to go to the dword value in IDA-View:
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
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
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:
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
You must be registered to see links
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:
Double-click on it to go to the dword value in IDA-View:
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
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: