sots-re/findings/control-flow/watchpoints-modcount-status.md

Three questions, one armed run: ModCount, Frame, and the Player.Status regression

• Type: control-flow (live measurement)
• Status: verified — hardware data-write watchpoints on the running game, with a byte-identical oracle control
• Confidence: high. Twenty-four consecutive ModCount values with no gap; every predicted address hit to the byte.
• Owner / date: lane W2 · 2026-09-08
• Instrument: src/shim/hooks/watchpoints.{h,cpp}, build w2watch-3512c9a-20260908T1900Z, config shim.cfg.w2watch
• Tests: alliance-mask-and-modcount.md §3 (lane A2's probe 1 and its four falsifiers), treaty-turn-stamp.md §3 (lane T2), turn-driver.md §0.1 (lane T)

---

0. The four results

1. ModCount gets exactly 12 writes per End Turn on this save, and lane A2's prediction is confirmed to the address. Two turns measured, 12 and 12, values running 13→24 and 25→36 with no gap. Ten of the twelve come from the command flush, one from ProcessTurn's first instruction, one from OnAllCombatDone_Tail. Zero from the abandon/chaos check. §2.
2. The ModCount / Frame naming dispute is settled, and lane A2 was right. S+0x8 took 12 writes in the window; S+0xc took exactly one, from BeginProcessTurn + 0x2a, and its value became the turn number. addresses.json's StrategyServer_off_ModCount names the wrong word and lane T's StrategyServer_off_PhaseCounter is ModCount. §3.
3. The Player.Status regression has a writer, and it is not where lane T2 looked. StrategyNetworkClient::OnMessage + 0xa15 writes Status = 4 after ProcessTurn returns and before the autosave, over the 1 the ProcessTurn tail had just written. T2's "there is NO writer between tail phase 31 and the autosave" is falsified by watching it happen, twice. §4.
4. The instrument is byte-neutral, and this was checked rather than assumed (rule 19). With all four watchpoints armed, one End Turn from ref-turn2.sav reproduced the determinism oracle exactly: (Autosave EndTurn).sav bb4fd9ac89f41e3b…, (Autosave).sav 978041acd168b56e…. §1.

---

1. The instrument, and its control

One MinHook detour in the whole module. Debug registers are per-thread, so the watchpoints have to be armed from a point that runs on the turn thread and precedes the writes. StrategyServer::ApplyAllTurnCommands 0x0078f6a0 is both — lane A2 read it as the End-Turn command flush, called from StrategyNetworkClient::OnMessage immediately before that handler calls ProcessTurn, and its this is the S frame — so S+0x8 and S+0xc are one add away. The detour is the register-transparent asm stub the M0 hook already uses; the watchpoints themselves modify no code at all.

watch: arm hook StrategyServer::ApplyAllTurnCommands rva=0x0038f6a0 va=0120f6a0 create=MH_OK enable=MH_OK
watch: players vector @0e0b267c begin=0e163528 end=0e163548 count=8
watch: SELFTEST canary writes=1 traps=1 dr7=0xdddd0055 PASS
watch: slot 0 -> S+0x8   = 0x0e0b2630        slot 2 -> player[0]+0x164 Status = 0x0e0cc2d4
watch: slot 1 -> S+0xc   = 0x0e0b2634        slot 3 -> player[1]+0x164 Status = 0x0e0c5d44
watch: ARMED on tid 5928 dr7=0xdddd0055, S=0e0b2628

The self-test is not decoration. Method rule 1 says a green verdict is not evidence, and "the arm silently did nothing" looks exactly like "nothing writes this". So before any game address is believed, DR3 is pointed at a word the shim owns, that word is written once, and the handler is required to report exactly one trap. It did. dr7 = 0xdddd0055 is all four slots enabled, R/W = 01 (data write), LEN = 11 (4 bytes).

The control (rule 19). Lane H's finding is that a MinHook detour can change the game's output, so a run taken with a new detour installed proves nothing until the same run is taken without it. This lane's control is stronger than a same-day A/B: the armed run is the oracle run. One End Turn from ref-turn2.sav, watchpoints live, produced

file	size	sha256 prefix	historical
(Autosave EndTurn).sav	66,732	bb4fd9ac89f41e3b	identical
(Autosave).sav	67,219	978041acd168b56e	identical

So the arming detour, four hardware watchpoints and ~36 exception deliveries changed nothing in the turn. That is worth stating as its own small result: a data breakpoint is a trap taken after the store retires, and unlike a code patch it has no relocation hazard — which is a point of contrast with §2 of tail-probes.md, where a detour on a clean prologue boundary did perturb.

What the instrument cannot see, stated up front. Debug registers are per-thread and these were armed on the turn thread (tid 5928) only. A write from another thread would be invisible. The evidence that there was none is indirect but strong: the 24 recorded ModCount values are contiguous — 13, 14, … 36, no gaps — so nothing incremented that word without being trapped.

2. ModCount — every writer, in order

Workload: ref-turn2.sav (turn 2, 8 players, ModCount = 12, Frame = 2), two End Turns. The window below is the second one, which is fully covered — arming happens inside the first End Turn, so the first window misses the three writes that precede the flush. Both windows agree on everything they share.

Addresses are Ghidra VAs; the trap reports the instruction after the store, so a 3-byte inc shows as site + 3.

#	trap EIP	site	writer	value	return addresses
1	0x0086c3e9	0x0086c3e6	unresolved handler	25	0x0088fce2 → ApplyTurnCommandBatch+0x332
2-5	0x00821a87	0x00821a84	unresolved handler, ×4	26-29	0x0088ffcb → ApplyTurnCommandBatch+0x61b
6	0x0084946e	0x0084946b	unresolved handler	30	0x008900a4 → ApplyTurnCommandBatch+0x6f4
7	0x0088bf01	0x0088befe	unresolved (near DestroyFleet)	31	0x008902b4 → ApplyTurnCommandBatch+0x904
8-9	0x0089046f	0x0089046c	inlined in ApplyTurnCommandBatch, ×2	32-33	0x0078f6e6 → ApplyAllTurnCommands+0x46
10	0x008657ad	0x008657aa	StrategySim::MoveFleetCommand	34	0x00890652 → ApplyTurnCommandBatch+0xca2
11	0x007dc6f3	0x007dc6f0	StrategyServer::ProcessTurn, first instruction	35	—
12	0x007d92cd	0x007d92ca	OnAllCombatDone_Tail + 0x2a	36	—

Against lane A2's prediction, item by item:

• "exactly 12 hits" — confirmed, twice.
• "two of them at 0x007dc6f0 and 0x007d92ca" — confirmed, both, to the byte. These are the only two predicted addresses in A2's probe and both landed exactly.
• "zero of them at 0x007b9e20" — confirmed. Abdn is false on every system of this save and the abandon/chaos check's bump never fired. Note what kind of negative this is: rule 20's distinction. This is "the site never trapped", which on a watchpoint is stronger than a word count — but it still does not separate "the function was not called" from "it was called and the gate held". A2's static reading says the gate is sys->+0xc4; that remains a static claim.
• "the other 10 … with a return address in ApplyTurnCommandBatch 0x0088f9b0 or its callers" — confirmed. Every one of the ten carries either an ApplyTurnCommandBatch return address or ApplyAllTurnCommands+0x46, and the outer frame is OnMessage+0x2c9 (0x00784909), which is the return of the ApplyAllTurnCommands call A2 located at 0x00784904. A2's whole call chain is confirmed live, address by address.
• A2's inlined site 0x0089046c is confirmed — the trap at 0x0089046f is three bytes past it — and it fires twice in this window, so the six inlined sites are not one-shot.
• 0x008657aa (MoveFleetCommand) confirmed to the byte.
• A2's falsifier (c) fires, and it is a refinement rather than a refutation. A2 predicted all 12 would be "before ProcessTurn is entered". Ten are. The eleventh is ProcessTurn's own first instruction and the twelfth is after it. So the correct statement is: all ten command-application bumps precede ProcessTurn; the two driver bumps bracket the turn. The "queue is flushed first" reading survives intact.
• Falsifier (b) fires and is the useful part. Four of the ten handler EIPs are not attributable to a named function — the nearest known symbol is between 0x581 and 0x10e9 away, which is not containment. They are recorded as addresses in ghidra/addresses.d/lane-w2.json with status mapped rather than dropped or guessed. The one to disassemble first is 0x00821a84: it fires four times per turn, the most of any handler on this save, and it sits immediately after StrategyServer::MarkPlayerTurnEnded (0x00821a40, 60 bytes, ending 0x00821a7c) — so it is that function's neighbour, not that function.
• Falsifier (d) does not fire: no trap at 0x007850d5 / 0x0078514b / 0x00785224, so A2's exclusion of OnMessage's three inc [reg+4] sites was right. (OnMessage does appear in §4, but for Status, not for ModCount.)

12 is not a constant (rule 20). It is this save's command count. The corpus disagrees with itself usefully: turn1-state → turn2-state → turn3-state moves ModCount 0 → 12 → 24 (this game), human-turn2-orders.sav sits at 25 on frame 2 (a different game), and the Zuul line runs 63 @ f5 → 210 @ f15 → 412 @ f23, i.e. ~15-25 per turn. The structure is what generalises: two driver bumps plus one per applied command.

3. ModCount vs Frame — settled

Lane T (StrategyServer_off_PhaseCounter, turn-driver.md §0.1) and lane A2 (StrategySim_off_ModCount, alliance-mask-and-modcount.md §2.1) disagreed about which of S+0x8 and S+0xc is which, and addresses.json's StrategyServer_off_ModCount sits on the third opinion. One run separates them, because the two words behave completely differently:

word	writes per End Turn	writer	value
S+0x8	12	ten command handlers + ProcessTurn + OnAllCombatDone_Tail	monotonic, no relation to the turn
S+0xc	1	BeginProcessTurn + 0x2a (trap 0x007d990d)	3 → 4 on the turn that produced frame 4

A word written once per turn whose value is the turn number is Frame. A word written once per applied command is a modification counter. Lane A2 is right on both, and its correction of addresses.json stands. Lane T's StrategyServer_off_PhaseCounter — "nobody has named this one" — is ModCount, and the note that "both advance once per turn in different functions" is wrong about S+0x8: it advanced twelve times.

Lane A2 also predicted BeginProcessTurn's bump at 0x007d990a from the instruction stream. Trap 0x007d990d. Confirmed.

4. Player.Status — the complete ordered story

DR2 and DR3 watched players[0]+0x164 and players[1]+0x164 for the whole window. Every write of Status on those two players, in order, for one End Turn:

order	site	writer	player	value
1	0x00821a75 (store ends here)	MarkPlayerTurnEnded + 0x35, called from OnPlayerEndTurn + 0x35 (return 0x007d9b2a)	both, one call each	4
2	—	BeginProcessTurn (Frame), ApplyAllTurnCommands (10 × ModCount), ProcessTurn entry	—	—
3	0x007dcc8a (trap 0x007dcc94)	ProcessTurn + 0x5ca — the phase-31 site	player 0 only	1
4	0x00785055 (store ends here)	StrategyNetworkClient::OnMessage + 0xa15	player 0 only	4
5	—	OnAllCombatDone_Tail (ModCount)	—	—
—	(the post-turn autosave is written somewhere here)
6	0x007ddd41 (trap 0x007ddd49)	ResumePlaying + 0xb1	both	0

Step 4 is the answer to the open item. The regression was stated as "the phase writes 1, the file carries 4, a load resets to 0, and the writer between tail phase 31 and the autosave is unaccounted". The writer is OnMessage + 0xa15 and it is a second, direct store site — not a call into MarkPlayerTurnEnded, because the trap EIP is inside OnMessage's body, not inside 0x00821a40. This corrects treaty-turn-stamp.md §3 on two points: MarkPlayerTurnEnded is not "THE ONLY WRITER OF Player.Status = 4 IN THE IMAGE", and "there is NO writer between tail phase 31 and the autosave; backlog item 6 looks in the wrong place" is wrong — the backlog item was looking in exactly the right place, it just could not see the site by reading.

Two further refinements the watchpoint gives for free:

• The phase-31 write of 1 hits the local player only, not every player. T2 read the site correctly (ProcessTurn + 0x5ca, value 1, inside a 0x44-stride loop); the loop selects one player on this save.
• ResumePlaying's zeroing runs inside the End Turn, after the autosave, not only on load. The saved files confirm the ordering independently: (Autosave EndTurn).sav (pre-turn) carries Status = 0 for all eight players, (Autosave).sav (post-turn) carries 4, 4, 4, 4, 0, 0, 0, 0. Player 0's value in that file is the 4 from step 4, having been 4 → 1 → 4 inside one turn; players 1-3's is the untouched 4 from step 1; players 4-7 never receive one.

5. Coverage — what this run did NOT establish (rule 15)

• One save, one game, two turns. ref-turn2.sav only. Nothing here is a claim about a turn with combat, with an abandoned system, or with more than two active players.
• Two players watched, not eight. DR2/DR3 covered players[0] and players[1]. Players 2-7's Status was inferred from the save files, not watched. In particular, who calls MarkPlayerTurnEnded for players 2 and 3 was not observed.
• Four of the twelve ModCount writers are unnamed (§2). The lane located them; it did not identify them.
• 0x007b9e20 never fired, which is a real negative for this save and says nothing about a save where Abdn is true. Rule 6: that path is still a hypothesis.
• Per-thread blind spot (§1). A ModCount write from a thread other than the turn thread would be invisible; the contiguity of the values argues there was none, but only for these two turns.
• The autosave's exact position between steps 5 and 6 of §4 is inferred from the file contents, not watched. A fifth watchpoint is not available (four DRs), and the StrategyHost::Autosave hook already exists in the harness if anyone wants to bracket it precisely.

6. Files

• Hit log, both turns: verify/results/shim/watchpoints/w2-modcount-status-2turns.txt
• Instrument log incl. the self-test: verify/results/shim/watchpoints/w2-shim-log-excerpt.txt
• Addresses: ghidra/addresses.d/lane-w2.json (10 entries)
• Instrument: sots-engine src/shim/hooks/watchpoints.{h,cpp}, configs shim.cfg.w2watch / shim.cfg.w2control
• Predictions, committed before the run: sots-engine/docs/W2-predictions.md

7. The instrument is reusable, and here is what it costs

watch=on in shim.cfg arms four 4-byte write watchpoints from StrategyServer::ApplyAllTurnCommands. To watch something else, change the four addresses computed in WatchOnApplyAll — anything reachable from S at that moment is one line. The run above cost one build and about six minutes of VM time for two turns, and it answered three questions that had consumed parts of four lanes of static reading. Method rule 18, again: what writes this? is a watchpoint.

Two things a future user should keep — and then §8 for the queue items this lane did not reach, each with the reason and the cheapest next step.

• keep the canary self-test. It is four lines and it is the difference between "nothing writes this" and "the arm silently failed".
• keep the oracle control. Loading ref-turn2.sav and ending one turn costs nothing extra and proves the run is measuring the un-instrumented game.

---

8. Not reached, and why — with the cheapest next step for each

Lane H's account of the trade workload was more useful than the attempt would have been. Same discipline here.

8.1 TShn — the brief's address is wrong, and that is the finding

The lane brief said "watchpoint on the player+0x274 map". That is the wrong object. player+0x274 is observed_techs (lane V, eventlive-verification.md §4.3). The TShn map is ServerSystem+0x274 — the NVO container — per system-visibility-record.md §8, whose own words are "a watchpoint on ServerSystem+0x274's map during one turn". Anyone who armed the briefed address would have watched the tech-observation array and reported a confident nothing.

The real obstacle is structural, and it is why this was not just a fifth line in WatchOnApplyAll: a std::map's nodes are heap-allocated, so TShn has no fixed address to arm before the node exists. Two ways round it, both cheap now that the module exists:

1. Arm the map header (ServerSystem+0x274 … +0x27c) rather than a leaf. That traps the insertion, which is arguably the better question — E3's puzzle is which systems get an NVO entry, and Spica-vs-Bismol is a question about the gate, not about the value.
2. Arm the leaf directly, by loading turn1-state.sav, walking the map for Spica's node once at ProcessTurn entry, and pointing DR0 at that node's TShn word. This needs the node layout, which objects/ has.

Either is one arming function away. What is not solved is the arming point: ApplyAllTurnCommands gives S, and ServerSystems hang off S+4+0x40, so reaching a named system needs a name compare in the arming code. About twenty lines.

8.2 rcex — closed without the VM

See findings/subsystems/rcex-explained.md. It is sixteen 4-bit per-player counters; nibble p is set to 1 on the turn the system enters player p's AFlags and ticked to 0 the next turn, 7/7 across two different games. The corpus had the answer; nobody had put the nibble index next to the AFlags bit index. The one part that still wants a watchpoint is the site of the decrement — the "rcex tick" named in ServerSystem::ProcessTurn's body-order note — and rcex is at a fixed offset in a fixed object, so it is the easiest target this module has.

8.3 The trade-route / spy workload — not attempted, deliberately

Lane H's reasons (tail-probes.md §3.2) all still hold: trade routes need trade-station construction plus its tech, which from ref-turn2 is tens of End Turns at 30-60 s each with a Build/Research click path per turn, and the turn-23 Zuul save still has none; and no lane has identified which UI produces a spy-program entry, so for spies there is still no click path to write down. This lane spent its VM time on the multiplayer demonstration and the watchpoint run because both had falsifiable predictions attached and this does not.

What is different now, and it is the thing that makes the next attempt materially cheaper: "confirm the workload took before spending a turn measuring it" is exactly what this module does, and both containers are one add from the arming point already in the code.

container	address at ApplyAllTurnCommands entry (this = S)
trade-route vector (slot 15's body)	*(void**)(S + 4 + 0x154) → tradeManager, then tradeManager + 0x3c (_Mylast at +0x40)
spy-program vector (slot 14's body)	*(void**)(S + 4 + 0x158) → spyManager, then spyManager + 0x10 (_Mylast at +0x14)

Arm DR0/DR1 on the two _Mylast words and the game announces the moment either vector grows, with the EIP and two return addresses of whoever grew it. For the spy vector that is not just workload confirmation — it is the answer to "which UI produces a spy-program entry", because the return addresses name the caller. That is a better use of the next VM slot than playing twenty turns blind.