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

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

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.

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

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.

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.

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.

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