- 28
- 2025
- 15
[Location, Faction, Race]
Server-wide / worldserver core — not location, faction or race specific. Affects all maps, both factions, all races. Repack: Emucoach 5.4.8 Rev 7.1 Release (hash d451d085c1664afb6dade41d540b34d454348136), Win64.
[Name, Type]
Creature GUID allocation in the core — ObjectMgr::GenerateLowGuid. Type: server crash / core engine bug, triggered by the PlayerBot system.
[Problem Description]
worldserver.exe crashes repeatedly with C0000005 ACCESS_VIOLATION. All evidence points to the creature GUID counter hitting its hard cap (0x00FFFFFE = 16,777,214) in ObjectMgr::GenerateLowGuid (the "Creature guid overflow!" assertion), driven by world bots whose pets/totems/guardians permanently consume creature GUIDs.
Evidence:
- creature table MAX(guid) = 9,815,084 of the 16,777,214 cap -> only ~6.96M GUIDs of runtime headroom per boot.
- The creature GUID counter is recalculated from the DB at startup and is never freed/recycled at runtime; only a restart resets it.
- Crash frequency was ~1 every 1-2 days historically. The day PlayerbotEnableWorld was enabled on a populated realm it crashed 4 times in ~3 hours (16:59, 18:08, 19:58, 20:05). The ~70-110 min cadence matches the time for hundreds of roaming world bots to burn ~7M creature GUIDs via pets/totems/guardians.
- Restart resets the counter (~9.8M from DB), it climbs and overflows again — textbook exhaustion pattern.
Reproduction: MoP Premium 7.1, PlayerbotEnableWorld = 1, high PlayerbotAmount (e.g. 300); let the realm run with bots active (pet/summon classes especially); worldserver crashes within ~1-2 hours of uptime once the in-memory creature GUID counter reaches the cap.
Note: the generated crash .txt dumps are unsymbolicated (raw addresses only); full .dmp + worldserver.conf available on request, and I am happy to help test a fix.
[How it should work]
worldserver should not exhaust the creature GUID pool under normal bot operation. Suggested core directions: recycle freed creature GUIDs (return despawned / temporary-summon GUIDs to the pool), and/or widen the creature GUID space, and/or ensure PlayerBot temporary summons (pets/totems/guardians) do not permanently consume the persistent creature GUID range. Operator-side mitigations (lower PlayerbotAmount, disable PlayerbotEnableWorld, periodic restarts) only delay the crash — a core fix is needed for stable 24/7 uptime with world bots.
Server-wide / worldserver core — not location, faction or race specific. Affects all maps, both factions, all races. Repack: Emucoach 5.4.8 Rev 7.1 Release (hash d451d085c1664afb6dade41d540b34d454348136), Win64.
[Name, Type]
Creature GUID allocation in the core — ObjectMgr::GenerateLowGuid. Type: server crash / core engine bug, triggered by the PlayerBot system.
[Problem Description]
worldserver.exe crashes repeatedly with C0000005 ACCESS_VIOLATION. All evidence points to the creature GUID counter hitting its hard cap (0x00FFFFFE = 16,777,214) in ObjectMgr::GenerateLowGuid (the "Creature guid overflow!" assertion), driven by world bots whose pets/totems/guardians permanently consume creature GUIDs.
Evidence:
- creature table MAX(guid) = 9,815,084 of the 16,777,214 cap -> only ~6.96M GUIDs of runtime headroom per boot.
- The creature GUID counter is recalculated from the DB at startup and is never freed/recycled at runtime; only a restart resets it.
- Crash frequency was ~1 every 1-2 days historically. The day PlayerbotEnableWorld was enabled on a populated realm it crashed 4 times in ~3 hours (16:59, 18:08, 19:58, 20:05). The ~70-110 min cadence matches the time for hundreds of roaming world bots to burn ~7M creature GUIDs via pets/totems/guardians.
- Restart resets the counter (~9.8M from DB), it climbs and overflows again — textbook exhaustion pattern.
Reproduction: MoP Premium 7.1, PlayerbotEnableWorld = 1, high PlayerbotAmount (e.g. 300); let the realm run with bots active (pet/summon classes especially); worldserver crashes within ~1-2 hours of uptime once the in-memory creature GUID counter reaches the cap.
Note: the generated crash .txt dumps are unsymbolicated (raw addresses only); full .dmp + worldserver.conf available on request, and I am happy to help test a fix.
[How it should work]
worldserver should not exhaust the creature GUID pool under normal bot operation. Suggested core directions: recycle freed creature GUIDs (return despawned / temporary-summon GUIDs to the pool), and/or widen the creature GUID space, and/or ensure PlayerBot temporary summons (pets/totems/guardians) do not permanently consume the persistent creature GUID range. Operator-side mitigations (lower PlayerbotAmount, disable PlayerbotEnableWorld, periodic restarts) only delay the crash — a core fix is needed for stable 24/7 uptime with world bots.