pool: every VS refusal on a live walk is the subsegment bound, which makes the bound the suspect

[glslang]

First live 26100 walk since #102 split the VS plausibility predicate and made the refusal count a count. Both changes paid off immediately, and what they show points somewhere I dismissed while writing them.

The measurement

pool_census over KDNET, 408,013 chunks walked (241,970 allocated) in ~19s, partial, 3,569 diagnostics in 14 categories. Every VS diagnostic:

   542x  # VS chunk headers refused, resynchronising from #
   542x  refusing VS chunk at # the chunk runs past the end of its subsegment (size # previous size # encoded #
    68x  # VS chunks disagreed with the size of the chunk before them, from #
    68x  VS chunk at # records a previous size of # where the chunk before it measured #

and the walk's own total, which no diagnostic can carry:

"refused_chunks": 106516

Two things worth separating

1. One predicate accounts for every refusal. decode_vs_chunk has three: the size word decoding to zero, a chunk smaller than its own headers, and a chunk running past its subsegment. On a walk with 106,516 refusals, the first two fired zero times. That is not what corruption looks like — a header rewritten under us, or a wrongly keyed word, would spray across all three. One predicate at 100% is the shape of a predicate that is wrong.

The obvious candidate is the bound itself, which is region.address + region.size. #93 raised exactly this ("worth checking while in here: whether region.size is the right bound") and I dismissed it in #102 on the grounds that the test is > rather than >=, so a chunk ending exactly at the boundary is accepted. That answers the exact-boundary case and says nothing about a bound that is systematically too small — which is what this looks like. #92's discover_segment_context advances a VS region past _HEAP_VS_SUBSEGMENT and shrinks its size to match; if that shrink is short, or if the walk starts at a base that is not the subsegment's, every chunk near the end of every extent overruns.

2. 106,516 is refusals, not lost chunks. A refusal advances 16 bytes and tries again, so one lost sync inside an extent bills one refusal per 16 bytes until it resynchronises: 106,516 refusals across 542 extents is ~196 per extent, ~3.1 KB of brute-force scanning each. The count is still the right number to carry — it is what the walk actually did — but it sizes the disruption, not a population of corrupt chunks, and anything reading it as the latter will overstate the damage by orders of magnitude.

What would settle it

The encoded word travels with the refusal now, precisely so a refused header can be re-decoded by hand. Take one refused chunk from a sample, decode its Sizes against the subsegment's own _HEAP_VS_SUBSEGMENT extent read directly from the target, and compare that extent with the region.size the walker was using. If they differ, the bound is the bug and 106,516 refusals are an artefact of it.

The chain check is the cross-check that makes this readable: only 68 extents show a chunk disagreeing with its predecessor's size. If the chunks themselves were corrupt at anything like the rate the refusals suggest, that number would not be 68.

Reproduce

cargo test --test mcp_smoke -- --ignored --nocapture --test-threads=1 live_kernel

with WINDBG_MCP_SMOKE_KERNEL sourced from the configured profile, then pool_diagnostics with filter VS chunk for verbatim samples carrying real numbers.

[glslang]

Still relevant — nothing since (the version-aware heap work included) touched
decode_vs_chunk, the VS discovery sizing, or walk_vs's starting offset. It got
more relevant: walk_user_segment_heaps now routes user-mode segment heaps
through the same walk_vs, so this was about to start affecting user heap walks too.

But the bound is not the bug, and the inference that pointed at it does not hold.

The bound is provably right. ntdll!RtlpHpVsSubsegmentCreate on 26100:

lea r8,[rbx-30h]              ; subsegment bytes - sizeof(_HEAP_VS_SUBSEGMENT) rounded to 16
shr r8,4
mov word ptr [rdi+20h],r8w    ; subsegment->Size
lea rdx,[rdi+30h]             ; ...and the first chunk starts here

first + Size * 16 is the page range — which is exactly region.address + region.size, since discover_segment_context advances by first and shrinks by the
same. #93's suspicion and this one both point at a number that two independent sources
agree on. The walk now cross-checks them anyway (that Size was already being read for
the signature check and thrown away), so any target where they disagree says so.

"One predicate at 100%" was not evidence of anything. Against a garbage Sizes
word, the subsegment bound is the only predicate with real selectivity. A zero size is
one value in 65,536; a size below the headers is one more. Expected count for each
across 106,516 refusals: under two. Observing zero of both is what a correct check
produces, not a suspicious result — I had the reasoning backwards.

What is actually wrong is one level up. A VS chunk is variable-size, so it can only
be located from the end of the chunk before it. walk_region hands walk_vs one
committed extent at a time, and RtlpHpVsSubsegmentCommitPages commits and decommits
page ranges anywhere inside a subsegment, tracking them in
_HEAP_VS_SUBSEGMENT.CommitBitmap — so holes are the allocator's steady state, not
damage. walk_vs started every extent at that extent's own first 16-byte boundary,
which is a guess on every extent after a hole, and the refusals were the 16-byte
scan finding its way back. That is the ~196 per extent.

The refusals were the harmless half. Whatever the scan landed on that decoded plausibly
was pushed into spans as an allocation with a tag, so some unknown share of that
walk's 408,013 chunks was fiction.

walk_lfh and walk_page_ranges were never exposed to this — their slots are a fixed
size, so they index off the region base and are right wherever an extent starts.

Your second point stands unchanged and is now the load-bearing one: 106,516 was
refusals, not lost chunks, and it sized the disruption. The disruption had a cause.

#107 follows the chain across the holes instead. A regression test reproduces this
issue's signature in miniature — 128 refusals in one extent, all of them "runs past
the end of its subsegment", from a fixture with no corruption and a correct bound.

[glslang]

Correction to my comment above: you were right and I was wrong. The bound is the
bug. I verified it against ntdll!RtlpHpVsSubsegmentCreate, concluded it was provably
correct, and generalised that to the kernel without checking. The live run refuted it.

Refusals fell 106,516 → 76,398 with only the chunk-chain fix — not to zero, and the
remainder had the same one-predicate signature. 76,398 / 308 affected extents = 248
refusals each. 248 × 16 ≈ one page, which is what it is.

The page range holding a VS subsegment is one unit larger than the subsegment. From the
target's own descriptor array:

053 flags=0f UnitSize=11 UnitOffset=00      a VS range: 17 pages
054..063     UnitSize=00 UnitOffset=01..10  its 16 continuation units
064 flags=03 UnitSize=01                    and the next range begins

and _HEAP_VS_SUBSEGMENT at +0x53000 holds Size = 0xffd → 0xffd0 bytes of chunks
after first → 0x10000 total. Sixteen pages of subsegment in a seventeen-page range,
on 1,388 subsegments in one walk, at both the 0x10000 and 0x20000 sizes. UnitSize
is read correctly — it is just not the subsegment's size. The walk was decoding a page
with no chunks in it and refusing a header every sixteen bytes across the committed part.

nt!RtlpHpVsSubsegmentInitialize writes Size = (bytes - first) >> 4 and lays the first
chunk at + first, so Size is the chunk area. It is now preferred over the descriptor,
not merely compared with it, because it is already validated: a subsegment is only
accepted when Signature ^ Size == 0x2bed, so a Size read from the wrong offset cannot
reach the walk. Clamped so it can only shrink a region.

Where my earlier comment still holds: the "one predicate at 100%" inference was still
not evidence — that predicate is the only selective one against a garbage word, so its
dominance would look identical if nothing were wrong. It pointed at the right place for
the wrong reason. And the chunk-chain defect was real and independent; it just accounted
for the smaller share, and for the fabricated spans rather than the refusals.

Measured on the same target:

	baseline	chain fix	+ bound fix
refused_chunks	106,516	76,398	0
chunks walked	408,013	446,329	446,516
diagnostics / categories	3,569 / 14	5,310 / 19	2,205 / 12
chain-break diagnostics	68	1	0

The chain-break category going to zero is the corroboration worth having: a chain break
is the walk mis-striding, and there is now nowhere left for it to mis-stride.

#107 has both fixes and the live figures.