Worldserver crash — Creature GUID overflow driven by PlayerBots (MoP Premium 7.1)

[Kneuma]

[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.

 

[peculiar.shove]

Also getting the exact same problem, not sure if related to the fact that playerbots generate tons of mails with 'Nivel 80' as the subject.

 

[ExO]

Thanks for the details. I’ll try to reproduce with debugging enabled in the weekend

 

[Kneuma]

Thanks @ExO. One extra datapoint not in the report (confirmed after I posted it): it's a clean on/off switch — with PlayerbotEnableWorld = 0 the server runs stable for hours (2.5h+, zero crashes), vs crashing every few minutes under load with it on. So it's specifically the world-bot creature-GUID consumption, not just bot count — should make it quick to reproduce/confirm with debugging. Raw .dmp + worldserver.conf ready whenever you want them, and I'm around this weekend to test a patched build.

@peculiar.shove fwiw the 'Nivel 80' mail spam is a separate bot side-effect (bots mailing each other), not the cause here — the crash is creature-GUID exhaustion from bot pets/totems/guardians.

 

[Kneuma]

Update — source-grounded root cause. Cross-checked against upstream SkyFire (the open 5.4.8 base this derives from; your build may differ, but GenerateLowGuid is core engine code and the crash string is a verbatim match):
ObjectMgr::GenerateLowGuid -> case HIGHGUID_UNIT: `ASSERT(_hiCreatureGuid < 0x00FFFFFE && "Creature guid overflow!"); return _hiCreatureGuid++;`

Confirms: hard cap 16,777,214 (0x00FFFFFE); no runtime GUID recycling (bare ++); the counter is only reset at startup from MAX(guid) FROM creature +1. The creature/pet path uses ASSERT (-> abort / hard crash), unlike Auction/Mail/EquipmentSet which overflow gracefully via World::StopNow() — which is why this shows as the violent C0000005 crash rather than a clean shutdown.

[How it should work] additions: recycle despawned/temp-summon creature GUIDs to a free-list, and/or widen the creature GUID space, and/or ensure PlayerBot temporary summons (pets/totems/guardians) don't permanently consume the persistent creature GUID range.

 

[tazinator]

Same issue here, I tried lowering Playerbot count and running an SQL flush daily as well as a server restart daily, but still seems to randomly hit.

I did notice once right before a crash a lot of the playerbots generating massive map issues so not sure if thats causing something.

 

[Kneuma]

@tazinator — second confirmation of the same bug, thanks for the data point. The "lowering count + daily restart still hits randomly" lines up with the source-side cause posted above: the cap (0x00FFFFFE) is a hard ceiling and _hiCreatureGuid increments monotonically with no recycling, so lowering bot count slows the approach to the cap but doesn't change the ceiling.

What I can say is verified on the live 7.1 repack here: PlayerBots.PlayerbotEnableWorld = 0 in worldserver.conf (then restart) stabilised it for me. The other bot modes — LFG / BG / Arena — are separate conf toggles and stay on, so bots still work for queued content. Worth trying if you haven't already.

On the "playerbots generating massive map issues right before a crash" — interesting observation, but I'd be guessing if I tied it directly to the GUID-cap mechanism (the ASSERT trips at the cap, not approaching it). Could be a separate symptom of bot pressure. If you can capture a Server.log slice from one of those moments, I'd love to see it — might point at a different angle.

Real fix lives in core code (ObjectMgr::GenerateLowGuid — see post #5). Until then, EnableWorld = 0 is the cleanest band-aid I've verified.