- Joined
- Jan 18, 2010
- Messages
- 3,109
- Reaction score
- 1,139
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
Yep. See how you got Unknown error? The entire error is solely based on GetModuleFileNameW(hModule, &Filename, 3u) returning false in the dinput8 library. I can't seem to understand closely what's going wrong. I've tried reading every single operation throughout all threads of the MapleStory process, but out of the tens of thousands of calls thrown I couldn't find a unique pattern or reason behind why it fails. So, I looked further into the physical call in the KERNEL32 module.
I debugged returned RESULT calls that are thrown by SetLastError and retrieved by GetLastError calls within the DLL and the process, and you'll get BUFFER_OVERFLOW results and stuff. However, the documentation states that it will reduce it to the nSize parameter given (which is 3 in this case). Also, this isn't why the function fails either. It fails because len is invalid (the length of the string).
I tried bypassing the call by jumping over it, nopping it out and all registers that use it, and by just simply modifying the 0x80070057 result to return 0 instead so it always succeeds. It works just fine upon call, but when the parameter WOULD be thrown, the client crashes now (stops responding completely). So, for some reason, the call to getting the file name (even though the file name is never used?) is required and if not called it crashes the client. I stumbled upon this post here:
You must be registered to see links
which I thought about. While I was debugging the process, there were several hundred returns of "DELETE_PENDING" and when I removed it and the client crashed, it would constantly spam "ERROR_ACCESS_DENIED". After scrolling down, the person states how it affects Windows 8 but running the application as administrator seems to make the issue(s) go away. However, with and without file tampering and making it run in compatibility of 7 alongside running as admin it would still crash (given it took me at least 30 client runs in order to trigger it). Soo I know the source of the error, but I'm not so sure the cause. We know it's GetModuleFileNameW, and we know it's because the function returns false; we don't know why the function is returning false. We also know that if we hardcode it to always return true even if it fails that it will work when GetModuleFileNameW returns true, but crashes if it doesnt and we say it is a success. Sleeping the current thread allows the OS to finish processing the pending deletion, but even with this in place we STILL crash a lot. If we can understand why the module filename is function in KERNEL32 is failing internally, then we can understand why all of this happens. What I find interesting as well is that for my v90 client using dinput8 works just fine with modifications and compatibility, but v83 does not. I never seem to manage to trigger it on my v90 spamming it to death but it'll happen several times with v83. I don't understand how this makes a difference because the error is not the client, it's entirely external and deals with WINAPI. But hey, it could just be pure coincidence and everyone else gets it besides myself.
I'll try messing with it some more, but after inspecting it I can't seem to figure out why it's so random, differs upons versions 83 and 90, and why removing the call to fix the error in turn crashes the process entirely instead of continues initializing the direct input. So annoying
Attachments
You must be registered for see attachments list