AKradian-I have reported some of these things happening before. They usually appear soon after an update of some kind. I went through a whole bunch of suggestions from the tech crew and nothing they suggested worked..... only to find that they cleared up after the next Windows update.
Now when I see frozen farm monsters and the top five items of your list, I figure it will clear up with the next Windows update and it does.
It clears up because the Windows Update forces a full restart of your computer.
You can just do the restart yourself instead of waiting for the update.
Actually, part of the trouble shooting with the tech crew was to do that. However, as I pointed out to them, I shut down every night and reboot every morning.
I deleted the game and reinstalled it as well. The problem remained until the next Windows update.
It is a recurring problem that starts up after some (but not all) Maplestory updates, I just wait (impatiently) till the next Windows update and the problems go away. Thankfully, the time between the onset and the problem being resolved has been getting shorter.
Actually, part of the trouble shooting with the tech crew was to do that. However, as I pointed out to them, I shut down every night and reboot every morning.
I deleted the game and reinstalled it as well. The problem remained until the next Windows update.
It is a recurring problem that starts up after some (but not all) Maplestory updates, I just wait (impatiently) till the next Windows update and the problems go away. Thankfully, the time between the onset and the problem being resolved has been getting shorter.
if the shutdown dont work for you guys ,make sure net.framework is totally activated and updated ...this was the solution to fix my problems with the dll (mostly workaround for windows 8 +10)
This started happening to me yesterday, and I'm glad to hear it's not just me that's having problems! I'm experiencing many of the issues outlined in the first post, as well as a few more:
1. The music sometimes will not change when transitioning maps. Sometimes it will change to what's supposed to be playing if you leave and re-enter the map, other times the music will persist across multiple map changes. I had the Henesys theme stick with me after teleporting to El Nath, and it didn't change until 3 map transitions later.
2. Sometimes the backgrounds are disappearing. I entered the shop in Henesys and the back wall was gone, nothing but blue.
3. I opened the map and the image didn't appear, although the quest-start lightbulbs did.
4. The sound effects for some skills won't play the first time you cast them, only on the second and subsequent times.
This started happening to me yesterday, and I'm glad to hear it's not just me that's having problems! I'm experiencing many of the issues outlined in the first post, as well as a few more:
1. The music sometimes will not change when transitioning maps. Sometimes it will change to what's supposed to be playing if you leave and re-enter the map, other times the music will persist across multiple map changes. I had the Henesys theme stick with me after teleporting to El Nath, and it didn't change until 3 map transitions later.
2. Sometimes the backgrounds are disappearing. I entered the shop in Henesys and the back wall was gone, nothing but blue.
3. I opened the map and the image didn't appear, although the quest-start lightbulbs did.
4. The sound effects for some skills won't play the first time you cast them, only on the second and subsequent times.
Issues 2 and 3 are symptoms of a different problem. It's a memory leak that is solved by restarting the client.
I am not sure about 1 and 4. If you haven't restarted your computer yet, could you just exit and relaunch the client and see whether the sound issues are solved?
I think this goes here as well. Today I encountered the following issues:
1. The stage in DI where the mobs drop green ohk orbs - the orbs don't drop (not sure if visual or actual) they were just stuck in the same area where they're dropped.
2. The recipe gauge in Muto (hard mode if it matters) didn't change from one recipe to the next. This went on until the 2nd run. So by the time I was given the 2nd recipe for the 2nd run, it showed the recipe bar was almost up, despite the fact that the recipe was just given. Bar up top worked fine (the muto vs gilla(?) one).
3. The arcane force requirement didn't disappear from the map even after 2 minutes had passed.
4. The notification for how long before you can use another rune didn't appear.
I thought all of these were just due to lag but then I realized I could only rope lift once in a map. So I tried harvesting, nothing happened either, just gave me the error. So I did a full shutdown, everything works fine now.
This is gonna sound unrealistic, but I found a way to reproduce this 100% consistently. I found it through reverse engineering, so I don't think I can share the details here.
To reproduce, have your system run for 2^31-1 milliseconds (or 24.8 days) with no full shutdowns. That's it lol..
Hint to Nexon's developers: the 'timeGetTime' API on Windows returns a DWORD, but it's stored into a variable called "tCur" which happens to be a signed int32 therefore it caps at 2^31-1, unfortunately the value this API returns only gets reset when you boot from a full shutdown.
Now, why is this called "Memory/DLL Corruption" if there's nothing "corrupted"...?
This is gonna sound unrealistic, but I found a way to reproduce this 100% consistently. I found it through reverse engineering, so I don't think I can share the details here.
To reproduce, have your system run for 2^32 milliseconds (or 49.7 days) with no full shutdowns. That's it lol..
Hint to Nexon's developers: the 'timeGetTime' API on Windows returns a DWORD therefore it caps at 2^32, unfortunately the value this API returns only gets reset when you boot from a full shutdown.
This is gonna sound unrealistic, but I found a way to reproduce this 100% consistently. I found it through reverse engineering, so I don't think I can share the details here.
To reproduce, have your system run for 2^32 milliseconds (or 49.7 days) with no full shutdowns. That's it lol..
Hint to Nexon's developers: the 'timeGetTime' API on Windows returns a DWORD therefore it caps at 2^32, unfortunately the value this API returns only gets reset when you boot from a full shutdown.
Now, why is this called "Memory/DLL Corruption" if there's nothing "corrupted"...?
It's called "Memory/DLL Corruption" because:
1. The process behaves abnormally. This means that either its data or its code are not as they should be (and normally are). Hence, "corruption".
2. Restarting the process does not restore normalcy. Therefore, the cause of the problem is not within the process' own memory.
3. (Full) Restarting the computer does restore normalcy. Therefore, the cause of the problem is not in persistent memory (HDD).
4. Therefore, the cause of the problem is in volatile memory that does not belong to the process alone. I don't know enough about Windows programming to know what forms of "shared memory" it has, hence the "memory/DLL".
Yours is an interesting theory, but I have two problems with it.
1. I have a Windows 7 laptop (where all shutdowns are "full") and looking at the event log I see it has never been up for 49 days straight. Longest I can see is 27 days. And yet Maple does go into this abnormal state on that computer. Note that I use this computer for mules, and sometimes don't even notice or care that Maple is "corrupted" on it.
Looking at my Windows 10 computer's event log, it looks like the correct number for when Maple "corrupts" is around 25 or possibly even 21 days. But I am not sure as I don't know how to differentiate "full" from "hybrid" shutdowns in that log. It does seem fairly consistent, though, which lends credence to the thought that the cause of the "corruption" is not user behavior but something external.
2. It's true that timeGetTime only returns a DWORD, but if I understand correctly it wraps back to 0 once it reaches MAXINT. While this might cause the Maple client to behave strangely if it happens to be up at the moment of rollover, the strange behavior should not persist after restarting the client. Unless it saves the time "high water mark" into persistent memory (HDD, Registry, etc) for whatever reason - in which case a full shutdown wouldn't help either.
This is gonna sound unrealistic, but I found a way to reproduce this 100% consistently. I found it through reverse engineering, so I don't think I can share the details here.
To reproduce, have your system run for 2^32 milliseconds (or 49.7 days) with no full shutdowns. That's it lol..
Hint to Nexon's developers: the 'timeGetTime' API on Windows returns a DWORD therefore it caps at 2^32, unfortunately the value this API returns only gets reset when you boot from a full shutdown.
Now, why is this called "Memory/DLL Corruption" if there's nothing "corrupted"...?
It's called "Memory/DLL Corruption" because:
1. The process behaves abnormally. This means that either its data or its code are not as they should be (and normally are). Hence, "corruption".
2. Restarting the process does not restore normalcy. Therefore, the cause of the problem is not within the process' own memory.
3. (Full) Restarting the computer does restore normalcy. Therefore, the cause of the problem is not in persistent memory (HDD).
4. Therefore, the cause of the problem is in volatile memory that does not belong to the process alone. I don't know enough about Windows programming to know what forms of "shared memory" it has, hence the "memory/DLL".
Yours is an interesting theory, but I have two problems with it.
1. I have a Windows 7 laptop (where all shutdowns are "full") and looking at the event log I see it has never been up for 49 days straight. Longest I can see is 27 days. And yet Maple does go into this abnormal state on that computer. Note that I use this computer for mules, and sometimes don't even notice or care that Maple is "corrupted" on it.
Looking at my Windows 10 computer's event log, it looks like the correct number for when Maple "corrupts" is around 25 or possibly even 21 days. But I am not sure as I don't know how to differentiate "full" from "hybrid" shutdowns in that log. It does seem fairly consistent, though, which lends credence to the thought that the cause of the "corruption" is not user behavior but something external.
2. It's true that timeGetTime only returns a DWORD, but if I understand correctly it wraps back to 0 once it reaches MAXINT. While this might cause the Maple client to behave strangely if it happens to be up at the moment of rollover, the strange behavior should not persist after restarting the client. Unless it saves the time "high water mark" into persistent memory (HDD, Registry, etc) for whatever reason - in which case a full shutdown wouldn't help either.
My fault, I looked at it incorrectly but it seems to be a signed int32 (therefore it caps at 2^31-1, (24.8 days)) rather than a DWORD (unsigned int32).
As in, timeGetTime returns a DWORD, however the game stores it as an int32.
I updated the original post with the correct information.
As you can see, it overflows all the way to -2 billion:
And honestly the 24.8 days makes a lot more sense, as you said it happens around 25 days (perfectly matches my explanation).
Cutscenes and such get stuck because the game simply wasn't designed to operate with negative numbers for the time the system is up for, simply put. I honestly can't see why MapleStory doesn't manage durations on its own.
One question about this theory: why does the game need to know how long your computer has been running for? If I were to guess I'd say it's some kind of security bug bringing down the whole game.
One question about this theory: why does the game need to know how long your computer has been running for? If I were to guess I'd say it's some kind of security bug bringing down the whole game.
It uses it for durations.
As of v188 the game uses timeGetTime over 250 times, for all the situations explained in the OP, and some extras.
Comments
It clears up because the Windows Update forces a full restart of your computer.
You can just do the restart yourself instead of waiting for the update.
I deleted the game and reinstalled it as well. The problem remained until the next Windows update.
It is a recurring problem that starts up after some (but not all) Maplestory updates, I just wait (impatiently) till the next Windows update and the problems go away. Thankfully, the time between the onset and the problem being resolved has been getting shorter.
Normal shutdown does not clear the corrupted memory. You have to do a full shutdown, which is what Windows Update does, to clear it.
Follow the procedure outlined at https://www.howtogeek.com/129021/how-to-do-a-full-shutdown-in-windows-8-without-disabling-hybrid-boot/ to create a desktop shortcut for full shutdown, and use that next time this happens to you.
http://forums.maplestory.nexon.net/discussion/11752/resolved-jett-link-skill-core-aura
After investigation, memory/DLL corruption was the cause of this issue.
https://www.reddit.com/r/Maplestory/comments/6a8ux5/i_can_only_use_rope_lift_one_time_per_map/
Thank you, but it was already in the list as:
Here's a video about Rope Lift i recorded while i got it:
1. The music sometimes will not change when transitioning maps. Sometimes it will change to what's supposed to be playing if you leave and re-enter the map, other times the music will persist across multiple map changes. I had the Henesys theme stick with me after teleporting to El Nath, and it didn't change until 3 map transitions later.
2. Sometimes the backgrounds are disappearing. I entered the shop in Henesys and the back wall was gone, nothing but blue.
3. I opened the map and the image didn't appear, although the quest-start lightbulbs did.
4. The sound effects for some skills won't play the first time you cast them, only on the second and subsequent times.
Issues 2 and 3 are symptoms of a different problem. It's a memory leak that is solved by restarting the client.
I am not sure about 1 and 4. If you haven't restarted your computer yet, could you just exit and relaunch the client and see whether the sound issues are solved?
1. The stage in DI where the mobs drop green ohk orbs - the orbs don't drop (not sure if visual or actual) they were just stuck in the same area where they're dropped.
2. The recipe gauge in Muto (hard mode if it matters) didn't change from one recipe to the next. This went on until the 2nd run. So by the time I was given the 2nd recipe for the 2nd run, it showed the recipe bar was almost up, despite the fact that the recipe was just given. Bar up top worked fine (the muto vs gilla(?) one).
3. The arcane force requirement didn't disappear from the map even after 2 minutes had passed.
4. The notification for how long before you can use another rune didn't appear.
I thought all of these were just due to lag but then I realized I could only rope lift once in a map. So I tried harvesting, nothing happened either, just gave me the error. So I did a full shutdown, everything works fine now.
To reproduce, have your system run for 2^31-1 milliseconds (or 24.8 days) with no full shutdowns. That's it lol..
Hint to Nexon's developers: the 'timeGetTime' API on Windows returns a DWORD, but it's stored into a variable called "tCur" which happens to be a signed int32 therefore it caps at 2^31-1, unfortunately the value this API returns only gets reset when you boot from a full shutdown.
Now, why is this called "Memory/DLL Corruption" if there's nothing "corrupted"...?
Joking aside... Because its the Gameplay Behavior that gets "corrupted" due to abnormal Memory/DLL.
It's called "Memory/DLL Corruption" because:
1. The process behaves abnormally. This means that either its data or its code are not as they should be (and normally are). Hence, "corruption".
2. Restarting the process does not restore normalcy. Therefore, the cause of the problem is not within the process' own memory.
3. (Full) Restarting the computer does restore normalcy. Therefore, the cause of the problem is not in persistent memory (HDD).
4. Therefore, the cause of the problem is in volatile memory that does not belong to the process alone. I don't know enough about Windows programming to know what forms of "shared memory" it has, hence the "memory/DLL".
Yours is an interesting theory, but I have two problems with it.
1. I have a Windows 7 laptop (where all shutdowns are "full") and looking at the event log I see it has never been up for 49 days straight. Longest I can see is 27 days. And yet Maple does go into this abnormal state on that computer. Note that I use this computer for mules, and sometimes don't even notice or care that Maple is "corrupted" on it.
Looking at my Windows 10 computer's event log, it looks like the correct number for when Maple "corrupts" is around 25 or possibly even 21 days. But I am not sure as I don't know how to differentiate "full" from "hybrid" shutdowns in that log. It does seem fairly consistent, though, which lends credence to the thought that the cause of the "corruption" is not user behavior but something external.
2. It's true that timeGetTime only returns a DWORD, but if I understand correctly it wraps back to 0 once it reaches MAXINT. While this might cause the Maple client to behave strangely if it happens to be up at the moment of rollover, the strange behavior should not persist after restarting the client. Unless it saves the time "high water mark" into persistent memory (HDD, Registry, etc) for whatever reason - in which case a full shutdown wouldn't help either.
As in, timeGetTime returns a DWORD, however the game stores it as an int32.
I updated the original post with the correct information.
As you can see, it overflows all the way to -2 billion:
And honestly the 24.8 days makes a lot more sense, as you said it happens around 25 days (perfectly matches my explanation).
Cutscenes and such get stuck because the game simply wasn't designed to operate with negative numbers for the time the system is up for, simply put. I honestly can't see why MapleStory doesn't manage durations on its own.
It uses it for durations.
As of v188 the game uses timeGetTime over 250 times, for all the situations explained in the OP, and some extras.
Now we wait and see whether anything will change.