Seeing a blizzard as a company or their developers don’t seem motivated in any way, shape or form to get an “esports game” to play and perform like one… And having tried and failed to get consistent performance out of this game for over two years while throwing 20.000€ at hardware and 3 separate fully built extreme overclocking systems at it (Intel and AMD) taking beyond obsessive care to make sure every single part of the system is as close to perfect as the blank cheque approach and obsessive ideology allow… taking care of minimizing the latency, and maximizing the performance of every subsystem to the absolute max… RME Babyface Pro FS intreface taking care of audio inputs and outputs (at RME’s roughly 4-10 times faster round trip audio time compared to consumer solutions), storage handled by an Intel Optane P5800X 1.6TB drive, 2.5Gbps FTTH internet connection running both Active Optical Cables and Cat8 PIMF ones to several tested home and enterprise network cards (Intel E810, Intel i226, Realtek 8126, Intel I210, Mellanox ConnectX Pro 3), an AM5 memory tune 99.8% of people could never dream of running, diving into the chipset and usb topology to clear every last possible performance obstacle. Every driver (ask me how I know NDIS performs better than NetAdapterCx), bios and windows setting optimized through years of testing and performance recording and analysis hoping it could make up for or at least make a lick of difference for the genuinely TRAGIC level of code quality. I have taken it upon myself to do the work of whoever is supposed to be even moderately thinking about the performance of this game into my own hands. And spent several days finally doing proper Windows Performance Recording and Analysis to try to uncover where exactly the performance issues stem from on arguably if not the single most optimized machine for esports gaming on the planet performance wise. Below is the final result and writeup that I will preface with the statement that I had Claude Fable 5 help me analyze and write by burning an additional few hundred on tokens.
If anyone at all at Blizz gives half of an excrement it would be absolutely amazing if you could work on this and you’re free to contact me if you require any of the raw capture data.
[Kernel trace] 70–330 ms engine-wide freezes in Stadium: single-threaded work on one fingerprinted function (RVAs + build ID included, traces available)
TL;DR: Using Windows Performance Recorder kernel traces of live Stadium matches, I captured multiple whole-screen freezes (72 ms, ~200 ms, ~330 ms) and traced them to their exact cause inside Overwatch.exe: 20+ engine threads sleep on a barrier while a single thread grinds through one specific function (same function in every freeze, across two separate game sessions — RVAs below). My hardware is exonerated at every layer with data included. The freezes occur in every game mode; the most reliable reproduction is Stadium, where roughly 40–50% of rounds produce one within seconds of going live. The fix has to come from your side: this work needs to be chunked or moved off the frame-critical path.
Test system (exonerated — evidence below)
Ryzen 7 9850X3D (custom loop, direct die) · RTX 5090 · 32 GB DDR5-8000 CL34 (validated: TM5, y-cruncher) · ASUS ROG Crosshair X870E Apex · Intel Optane P5800X 1.6 TB U.2 adapted into the primary M.2 slot (4 dedicated CPU lanes) · Intel i210 NIC on CPU lanes · 540 Hz OLED. During every captured freeze the system was 72–89% idle, all DPC/ISR latencies clean (max 0.24 ms across the whole trace), zero hard faults, and Overwatch performed zero disk I/O. This is not a hardware, driver, network, or storage problem.
Capture methodology
Two independent kernel traces (wpr -start GeneralProfile -filemode), two different days, two different game sessions:
- Trace 1: ~3.5-minute Stadium QP round. One 72 ms freeze mid-round analyzed to sample level.
- Trace 2: ~160 s covering a full Stadium round-1. Two freezes captured: a ~200 ms hard lock ~1–1.5 s after leaving spawn (mid-slide, start of live combat), and a ~330 ms main-thread saturation event later in the round.
Analysis in WPA (CPU Usage Precise + Sampled, wait-chain / readying-thread analysis) and PerfView (kernel rundown events). I’m happy to provide the ETL files or any specific export.
Anatomy of a freeze (identical in both traces)
- 20+ Overwatch threads enter a synchronized wait. In trace 1, the three heavyweight workers each logged a single wait of ~72.24–72.39 ms and woke within a 60–90 µs stagger. In trace 2’s hard lock, the same worker population logged waits of ~160–206 ms.
- One thread never stops. In trace 1 it was a fiber job worker (entry
Overwatch.exe+0x2683F30), compute-bound for 107.4 of 108 ms on one core. In trace 2 it was the primary thread itself (entry point+0x2665700), compute-bound for 204.1 of 204.3 ms with a maximum wait of 35 µs. - That thread releases the barrier. Wait-chain analysis (Readying Thread Id + ready stacks) shows every sleeping worker woken by a
KernelBase!SetEvent → ntoskrnl!KeSetEvent → KiExitDispatcherfrom the busy thread, at the exact moment the freeze ends.
While this happens, the render pipeline gets nothing and the screen holds one frame. Input still flows (mouse-move events continue through the freeze), packets still flow (ndis DPC counts continuous through the freeze window: 376/s before, 275/s during) — the “network icons” that appear are the freeze’s consequence, not its cause: a frozen client acknowledges late.
The fingerprint: one function, every freeze, both sessions
Sampled profiling of the busy thread during the stalls lands overwhelmingly in one function:
- Hot function: sample cluster
Overwatch.exe+0x263606Athrough+0x2636498(peak sample addresses+0x2636381,+0x2636385,+0x263648A). - Trace 1 (72 ms freeze): ~32 ms in this function.
- Trace 2 (~200 ms freeze): ~84 ms in this function, plus ~74 ms of directly-commissioned kernel memory management from the same thread:
VirtualFree → MiDeleteVad → MiDeleteVirtualAddresses → MiFlushTbList,VirtualAlloc, and a demand-zero page-fault storm (KiPageFault → MiZeroFault → MiResolvePrivateZeroFault → KeZeroPages) — i.e., tens of MB of freshly committed private memory written through and then freed, single-threaded, behind an engine-wide barrier. Hot function + memory management = 77% of the freeze.
Cross-session verification: the two traces have different ASLR bases, and the sampled addresses match at identical image offsets in both — seven distinct sample offsets (…06A/…0CA/…376/…381/…385/…389/…477/…48A) line up exactly, and the implied module bases are exactly 64 KB-aligned in both sessions with every other sampled game address falling inside the image. Same build, same function, two independent captures.
- Build: Overwatch.exe, TimeDateStamp
0x6A429ED1(linked 2026-06-29 16:35:29 UTC), PE CheckSum0x03E44C7A, SizeOfImage0x047B2000. (No FileVersion resource is stamped in the binary.) - Session bases for reference: trace 2
0x7FF767330000(recovered from the primary thread’s kernel-recorded start address minusAddressOfEntryPoint 0x2665700, since the main module does not appear in kernel image-rundown events), trace 10x7FF62AD60000(via the offset identity above). - Trace 1 additionally shows ~45 ms of the stall executing from dynamically generated code — heap addresses at
0x29D97384xxx/0x2A1016DDxxxowned by no module in the complete image census.
The heavier variant (~330 ms)
Trace 2 also captured a longer event: 330 ms of wall-to-wall main-thread saturation (95.33–95.67 s trace time), workers starved in stages (100/162/238/481 ms waits, all released by the main thread), profile spread broadly across dozens of game functions — and terminating in the same +0x2636xxx function immediately as the stall ends. It reads as a content/state-preparation pipeline running synchronously on the main thread, capped by the same instantiation step that constitutes the shorter freezes. Zero disk reads or writes by Overwatch during the event, so this is pure CPU work on already-resident data — no user-side hardware or storage setting can touch it.
Reproducibility and player impact
The freezes occur in every mode I play — Practice Range, Quick Play, Competitive, Stadium QP and Stadium Competitive. The most reliable and most damaging reproduction is Stadium: 40–50% of Stadium rounds produce one within seconds of the round going live (my hard lock in trace 2 hit ~1–1.5 s after leaving the spawn door, mid-movement-ability), which is why both kernel traces were captured in Stadium QP. At 500+ FPS-class settings on top-tier hardware, a 72–330 ms freeze is 40–180 dropped frames at the exact moment a fight starts. In a competitive title this is the difference between a duel and a death.
Everything else has been ruled out with data: network (packets continuous through the freeze), disk (zero game I/O during stalls; the only heavy disk activity in the windows was the trace collector itself, VSS, and Defender housekeeping — all after the stalls ended), antivirus (Defender’s activity post-dates both freezes by 600+ ms; the busy thread was executing game code, not blocked on anything), CPU/GPU headroom (system mostly idle, GPU ~44%).
The ask
Whatever Overwatch.exe+0x2636xxx instantiates — the timing (round-start / first-combat), the allocate-serialize-free shape, and the fact that Stadium’s round-start (the moment builds and powers apply) triggers it most reliably all point at game-state/content instantiation, though the freeze occurs in every mode, so it is not exclusively a Stadium code path — it currently runs synchronously, single-threaded, with the entire engine barriered on it. Please chunk it, amortize it across frames, or move it off the frame-critical path (or pre-instantiate before the round goes live). I’ll gladly provide the full ETL traces, additional captures on request, or run instrumented builds/flags if you have them.
(Methodology available on request: wait-chain analysis via CPU Usage (Precise) readying-thread grouping; sample attribution via CPU Usage (Sampled) grouped by address; module base recovery via kernel thread-rundown start addresses + PE headers; all numbers above are from the raw kernel events.)
