How to diagnose GameServer crashes during peak hours on your MU Online

Few problems are as frustrating as a GameServer that runs perfectly all day and crashes exactly when the server is full — at prime time, on the weekend, during an event. This pattern isn't a coincidence: it's the clearest evidence that the problem is tied to capacity — memory, connections, threads, or the database — not a random bug. This tutorial teaches you to systematically investigate these crashes, from collecting the crash dump to configuring limits that prevent the server from collapsing entirely.

Why the "crashes at peak" pattern is so revealing

When a failure occurs randomly, independent of load, it's usually a logic bug (a malformed packet, a specific command). When the failure correlates strongly with the number of players online, the pattern points to a finite resource being exhausted: memory allocated per connection that's never released, thread/handle count hitting an operating system ceiling, an exhausted database connection pool, or a configuration limit (MaxConnection) being exceeded without proper error handling. The first step of diagnosis is confirming this correlation with data, not just impressions.

Step 1 — Confirm the correlation with online player count

Before digging in, build a simple chart: number of players online (from the GameServer log or the website's counter, if available) cross-referenced with the exact time of crashes over the last 7-14 days. If crashes cluster above a certain player count (e.g., always above 400-500 online), you already have an approximate capacity ceiling to investigate.

A pattern like this (crashes always above ~500, days with fewer than 300 with no incident) is strong evidence of a capacity limit.

Step 2 — Collect the crash dump at the moment of the crash

Configure Windows to generate a full dump (or minidump) when GameServer.exe fails, via Windows Error Reporting or a tool like ProcDump from Sysinternals, continuously monitoring the process:

procdump -ma -e GameServer.exe C:\Dumps\

The -e parameter generates the dump automatically on the first unhandled exception, and -ma captures the process's full memory — essential for seeing the exact state at the moment of failure.

Step 3 — Analyze the dump

Open the dump in WinDbg (free, part of the Windows SDK) and run the basic triage commands:

!analyze -v
~*kb   -- stack of all threads
!heap -s -- heap summary, useful when memory overflow is suspected

Look in the call stack for the module and function where the exception occurred. Even without understanding every symbol, you can already classify it: failure in networking code (recv/send), failure in memory allocation (operator new, malloc returning failure), or failure in data access (null pointer in a character/inventory structure).

Step 4 — Check configured connection limits

In GameServerInfo.dat (or your emulator's equivalent), check the configured ceiling for concurrent connections:

[GameServerInfo]
MaxConnection = 800
MaxUserAcceptConnection = 1000

If the number of players online at the moment of the crash approaches or exceeds this value, the server may be trying to accept more connections than the configuration (or the hardware) supports, generating an unhandled exception instead of simply refusing the extra connection. Raising the limit without ensuring the hardware can handle it just postpones the problem to a higher number.

Step 5 — Monitor process memory throughout the day

Use Task Manager (Details tab, with the private memory column) or a monitoring script to log GameServer.exe's memory usage every 15-30 minutes:

Get-Process GameServer | Select-Object Name, @{n='MemMB';e={$_.WorkingSet64/1MB}}

If memory grows steadily throughout the day (never dropping, even as players log out), there's an accumulating memory leak — in that case, see the dedicated tutorial on diagnosing GameServer memory leaks to dig deeper into that specific investigation.

Step 6 — Check the database connection pool

A common, less obvious bottleneck: the GameServer keeps a limited number of open connections to SQL Server (pool). Under a player peak, if many operations (login, character save, trade) compete for the pool at the same time, connections can start failing or queuing, and depending on how the emulator handles that error, it can bring down the entire process instead of just delaying the operation.

Step 7 — Review operating system limits

Threads, handles, and sockets also have ceilings on Windows. On servers with many concurrent connections, check whether the process is close to the handle limit (visible in Task Manager, "Handles" column) and whether the Windows network configuration isn't limiting concurrent TCP connections (relevant on non-Server editions of Windows, which have artificial connection limits).

Step 8 — Test with simulated load before the next peak

If possible, use a bot/connection simulation tool (load-testing scripts specific to the emulator, or even multiple automated client instances) to reproduce the connection count close to what triggers the crash, in a test environment, outside real playing hours. This lets you observe server behavior under controlled stress and validate whether an adjustment (connection limit, database pool, code optimization) actually solves it, without risking the real player base.

Temporary mitigation while investigating

While the root cause isn't 100% resolved, a few mitigations reduce the impact:

• Scheduled GameServer restart during low-traffic hours (overnight), clearing accumulated state and reducing leaks before the next peak.
• Login queue configured near the real capacity limit, to politely refuse new connections instead of overloading the process.
• Automatic alerts when the online count approaches the historical crash ceiling, giving the team time to react.

Common errors and fixes

Peak-hour crash diagnosis checklist

• Correlation between online player count and crash times confirmed with data.
• ProcDump or equivalent configured to automatically capture a dump on failure.
• Dump analyzed in WinDbg with the involved code area identified.
• MaxConnection/MaxUserAcceptConnection limit reviewed against real capacity.
• Memory usage monitored throughout the day to rule out/confirm a leak.
• Database connection pool checked under load.
• Simulated load test performed outside real playing hours.
• Temporary mitigation (scheduled restart, login queue) applied while the root cause is fixed.

After stabilizing the GameServer at peak hours, it's worth reviewing the environment's overall capacity configuration to keep up with future player base growth — the MU Online server creation tutorial covers the ideal baseline configuration for this planning.

Frequently asked questions