How to diagnose a memory leak in your MU Online's GameServer

Memory that only goes up and never comes down is the classic symptom of a leak: the GameServer allocates resources over time — for each login, each loaded character, each processed event — and, due to a bug in releasing that memory, never gives it back to the operating system. The result is predictable: the process grows hour after hour until it freezes, becomes extremely slow, or is forcibly killed by Windows for lack of available memory. This tutorial teaches you to confirm the problem really is a leak, measure its pace, isolate the likely area of code, and mitigate the impact while the root cause is fixed.

How to tell a leak apart from normal memory usage

Normal memory usage rises with the number of players online and tends to stabilize at a level proportional to load — it may even drop a bit as players log out, depending on how the emulator manages character structures in memory. A leak is different: the memory curve rises monotonically (never drops significantly), even during low-traffic hours, and the rate of increase tends to be proportional to some repeated action (logins, map changes, item creation), not to the absolute number of players online at any given moment.

Step 1 — Establish a monitoring baseline

Before hunting for the cause, measure the problem. Configure collection of the GameServer.exe process's memory usage every 15-30 minutes, for at least 3-5 days, cross-referencing it with the number of players online at the same time:

# Simple periodic collection script (schedule via Task Scheduler)
$proc = Get-Process GameServer -ErrorAction SilentlyContinue
if ($proc) {
    "$(Get-Date -Format u),$($proc.WorkingSet64/1MB)" | Out-File -Append memlog.csv
}

With this log, calculate the growth rate (MB per hour) during low-traffic hours — if memory keeps rising even overnight with few players, the evidence of a leak is strong.

Step 2 — Build the chart and calculate time to collapse

With the collected data, project when the process will hit the available memory ceiling on the server (total RAM minus a safety margin for the OS and database). A leak of, say, 200MB/hour on a server with 8GB available for the GameServer indicates a collapse in about 40 continuous hours without a restart — essential information for sizing preventive restarts until a definitive fix.

Step 3 — Use VMMap for a detailed snapshot

VMMap (Sysinternals) lets you see, at a specific moment, how the process's memory is distributed — heap, stack, mapped memory, loaded DLLs. Run one snapshot right after boot and another after several hours of use, comparing which category grew disproportionately. Growth concentrated in "Heap" usually indicates allocated objects (character structures, items, network packets) not being released; growth in "Private Data" may indicate accumulating network buffers.

Step 4 — Correlate growth with specific game actions

A leak is rarely uniform — it's usually tied to a repeated action. Test by isolating variables:

• Repeated login/logout: log in and out of a test account several times in a row, watching whether memory climbs a step each cycle and never returns.
• Map switching: teleport between maps repeatedly, watching for the same pattern.
• Specific event: run an event (Blood Castle, Devil Square) several times in a row in a test environment and compare memory before/after.
• Chat/trade: communication and trading actions also allocate temporary structures that may not be released properly.

If an isolated test shows a step in memory that doesn't return, you've isolated the trigger action — valuable information even without source code access, since it already points you where to look (or what to report to the emulator's developer).

Step 5 — Analyze a full dump for accumulated objects

Generate a full process dump (procdump -ma GameServer.exe) after several hours of use, when memory is already visibly bloated, and analyze it in WinDbg with the heap extension:

!heap -s
!heap -stat -h 0

These commands show which allocation sizes dominate the heap. An abnormally high number of allocations of the same size (e.g., thousands of identical blocks matching the size of a "player connection" or "item packet" structure) is strong evidence that that type of object is being created repeatedly and never destroyed.

Step 6 — Consider plugins and customizations as a cause

Before assuming the leak is in the emulator's core, test with custom plugins/scripts disabled (custom event system, web shop integration, third-party anti-cheat). Many leaks on customized servers actually come from modules added by the server administrator, not the base emulator — re-enable them one at a time, monitoring the growth rate, to isolate the culprit.

Step 7 — Mitigation with a scheduled restart

While the root cause isn't fixed (which may depend on a fix in the emulator's source code or in a specific plugin), the practical, widely used mitigation in the community is a scheduled restart of the GameServer during low-traffic hours, with a comfortable margin before the calculated collapse time:

Schedule via Windows Task Scheduler:
- Time: 05:00 (lowest player concurrency)
- Action: stop the GameServer service, wait 10s, start it again
- Frequency: daily, or every X hours based on the rate measured in Step 2

Notify the community about the scheduled maintenance window to avoid complaints about "unexplained" downtime.

Recommended continuous monitoring tools

Common errors and fixes

Memory leak diagnosis checklist

• Memory monitoring baseline collected over several days.
• Monotonic growth pattern confirmed (doesn't drop with lower online count).
• Leak rate calculated (MB/hour) and time to collapse projected.
• VMMap snapshot compared between boot and hours of use later.
• Trigger action isolated (login, map switch, specific event).
• Plugins/customizations tested in isolation as a possible cause.
• Full dump analyzed with !heap in WinDbg, if possible.
• Scheduled restart configured as mitigation while the root cause is fixed.

With the leak under control and monitored, it's also worth reviewing the GameServer's overall capacity limits for peak hours, since insufficient memory is one of the most common causes of crashes at those times — see the MU Online server creation tutorial to review your environment's baseline configuration.

Frequently asked questions