docs(render): resolve #458 — the a9c9 doorway admission is a 0.5 % edge-plane precision boundary (AD-118)

Two live cdb captures on the paired 2013 client at the Holtburg doorway:
the blockset template (every Render::block_check call of one frame — 2,601
resident blocks x 2 exit views) proves retail tests a9c9 at ring slot
25,46 and returns PARTIALLY then OUTSIDE; the blockcheck template dumps
its four corner interval vectors (0 0 0 0 300.4|310.2 and 0 0 0 1001 ...,
slab 75..330). acdream's replay at the same P pose reproduces the sentinel
pattern, the four edge planes and both verdicts, drawing a9c9 once, with
clip heights 298.8/308.5 m — a 0.5 % plane difference (about 0.35 px of
projected door-vertex position). At the fixture pose that margin is what
flips the south-west corner from inside to outside on the fourth edge
plane, so retail's four-corner unanimity test says OUTSIDE where ours
says PartiallyInside. Not fixable bit-exactly short of D3D's x87
transform; the KnownFailure row stays with its comment rewritten, the
register carries AD-118, and the first filtered capture's silent miss
(cdb sign-extends poi() inside .if; use dwo()) is noted in the template.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/ISSUES.md

@@ -41,7 +41,7 @@ remain closed. See
 
 ## #458 — Walk admits land block `a9c9` at holtburg-doorway-still that retail does not draw
 
-**Status:** OPEN — found 2026-09-03 by the S3 chunk 1 eight-kind transcript conformance (the gate's first real walk catch).
+**Status:** RESOLVED 2026-09-03 — a PRECISION BOUNDARY, not a walk defect (register row AD-118; the KnownFailure row is kept on purpose — see the resolution below). Found 2026-09-03 by the S3 chunk 1 eight-kind transcript conformance (the gate's first real walk catch).
 **Severity:** MEDIUM (retail-order exactness; one far land cell drawn that retail skips — no known visible artifact)
 **Component:** `WalkLandscape.CheckBlocks` / `LandCellCheck` block-level visibility at a LOD-ring boundary
 
@@ -99,6 +99,32 @@ pose against the decomp (the per-view union, the block MinZ/MaxZ clip heights, t
 exit-view edge planes, not the cell test. Resolve in the S3 review round or an S3 chunk 5;
 remove the KnownFailure trait in the same commit.
 
+**Resolution (2026-09-03 afternoon, lead + owner, two live cdb captures on the paired 2013
+client at a NEARBY doorway pose — `docs/research/2026-09-01-overhaul/oh-capture/
+holtburg-doorway-still.blockset.log` and `.blockcheck.log`, templates
+`tools/walk-oracle/oh/oh-capture-blockset.cdb.template` / `oh-capture-blockcheck.cdb.template`):**
+(a) Retail DOES test `a9c9` — `draw_check_blocks` calls `Render::block_check` for ring slot
+gx=25 gy=46 (`did=a9c9ffff`) twice a frame, once per surviving exit view (2,601 resident
+blocks × 2 views = 5,202 calls + 477 from the second caller @0x00505243). The first
+filtered capture printed nothing because cdb sign-extends a 32-bit `poi()` inside `.if`;
+`dwo()` fixed it (template note). (b) At the afternoon pose retail returned PARTIALLY
+(1) in view 1 and OUTSIDE (0) in view 2 with the four corner interval vectors
+`bound[0..4] = 0 0 0 0 300.4|310.2` (view 1) and `0 0 0 1001 300.4|310.2` (view 2), z slab
+75..330 — and acdream's replay at the SAME `P` pose (a throwaway test, deleted) produced
+the SAME sentinel pattern, the SAME four edge planes, the SAME verdicts (1 then 0) and ONE
+`LC:a9c9` token, with clip heights 298.81/308.49 m vs retail's 300.4/310.2 m: a 0.5 %
+difference in the doorway's fourth edge plane (its slope ratio 0.05042 vs 0.05104 — about
+0.35 px of projected door-vertex position at 720p). (c) At the FIXTURE pose (frame 2 of the
+morning walk capture) acdream's replay has that fourth plane classify three block corners
+OUTSIDE (1001) and the south-west corner INSIDE (0): `block_plane_check` → PartiallyInside
+→ the block draws. Retail's plane, 0.5 % away, puts the last corner outside too → OUTSIDE →
+no `LC`. One far LOD block, one corner, one plane, at a boundary. The morning z-range and
+structural notes above stand (slab and loop shape match). No bit-exact fix exists short of
+reproducing D3D's x87 projection and `copy_view`'s float rounding; the conformance row stays
+`Status=KnownFailure` with its doc comment rewritten to this finding, and the register
+carries it as AD-118. The two look-in-flood divergences (2)/(3) above are the pre-existing
+FW1 near-win gate state and remain tracked by `WalkLookInGateSweepTests` (skipped).
+
 ## #457 — Two App tests pass only in Release (IL-offset pins fail under Debug)
 
 **Status:** OPEN — found 2026-09-03 during the S3 chunk 3 re-review; pre-existing at `dffd7055` (before chunk 3), not a campaign regression.

docs/architecture/retail-divergence-register.md

@@ -214,6 +214,7 @@ readiness/requeue adaptation. See
 | AD-102 | **Filed 2026-08-15 at Campaign CC slice CC4 (the Heritage page's Viamontian button and the Town page's Sanamar button).** Retail gates BOTH controls behind `CPlayerSystem::AccountHasThroneOfDestiny`: `gmCGHeritagePage::ListenToElementMessage @ 0x00483860` shows `MakeToDWarningDialog` instead of selecting Viamontian (element `0x100003c3`) for a non-ToD account, and `gmCGTownPage::ListenToElementMessage @ 0x0047c480` does the same for Sanamar (element `0x1000040b`, `startArea` index 3 — also the reason `CharGenState::RandomizeStartArea`'s ToD-aware `RandInt(3 or 4)` bound exists). acdream's `ChargenOptions` (CC1) carries no account/DLC-ownership signal anywhere in the model, so both controls ship WITHOUT the gate — every installed heritage/town in `Options.HeritagesById`/`Options.StarterAreas` is always selectable, matching what a ToD-owning account would see. | `src/AcDream.App/UI/Layout/CharacterCreationHeritagePage.cs` (`HeritageByButtonId[0x100003C3u]`); `src/AcDream.App/UI/Layout/CharacterCreationTownPage.cs` (`StartAreaByButtonId[0x1000040Bu]`, `Randomize`) | ACE's server-side `CharacterCreate` handler never checks ToD ownership either (the field is purely a retail-client UI gate), so accepting the selection unconditionally never produces a request the emulator would reject; adding an account-ownership model to CC1's DAT-only `ChargenOptions` is out of this slice's scope and would need its own design (where does the "ToD owned" bit come from — account service, launcher config, a new env flag?). | None observable against ACE. A future retail-parity gate that specifically checks "does a non-ToD account get warned off Viamontian/Sanamar" will fail until an account-ownership signal exists to gate on. | `gmCGHeritagePage::ListenToElementMessage @ 0x00483860`; `gmCGTownPage::ListenToElementMessage @ 0x0047c480`; `gmCGTownPage::SetTown @ 0x0047c360`; `CharGenState::RandomizeStartArea` (DoRandom case 4, `RandInt(hasToD ? 4 : 3)`) |
 | AD-99 | **Filed 2026-08-15 at Campaign LA gate round 2 finding 1 (character-select Exit button).** On a confirmed Exit, acdream closes the client through the existing graceful window-close path (`d.Window.Close`, the same seam `GameplayInputCommandController`'s in-world Escape fallback already uses) instead of retail's real post-confirm behavior: `RecvNotice_CloseDialog`'s case-1 arm queues UI mode `0x10000009`, which `gmEpilogueUI::Register` claims — a brief epilogue/farewell screen — before the process actually terminates. The confirmation dialog itself (`MakeConfirmExitDialog`, its exact `ID_CharacterManagement_ConfirmExit` text, and the `m_confirmExitDialogContext != 0` re-entry guard) IS ported faithfully; only the post-confirm destination differs, the same shape as AD-74's Options-panel exit. | `src/AcDream.App/UI/Layout/CharacterManagementUiController.cs` (`RequestExit`); `src/AcDream.App/UI/RetailUiRuntime.cs` (`CharacterSelectionRuntimeBindings.RequestExit`); `src/AcDream.App/Composition/InteractionRetainedUiComposition.cs` (`d.Window.Close` binding) | acdream has no `gmEpilogueUI` port (out of scope this round); reusing the ONE existing graceful-shutdown seam keeps `disconnected`/`exited` status events firing through `GameWindow.OnClosing` → `CompleteShutdown` rather than inventing a second shutdown path, per explicit direction for this finding. | A user confirming Exit sees the window close immediately instead of retail's brief epilogue screen; a future feature wanting to reproduce that screen (or an intermediate "logged off, returned to character select" state) has no seam yet — same gap class as AD-44. | `gmCharacterManagementUI::MakeConfirmExitDialog @0x004ed250`; `RecvNotice_CloseDialog @0x004ed760` case 1; `gmEpilogueUI::Register(0x10000009)` @0x0047a680; `gmCharacterManagementUI::OnAction @0x004ed410` (Escape key, unported — button-only this round) |
 | AD-113 | **Filed 2026-08-25 at Campaign CT slice CT-GF1 (client-wide retained-UI ancestor clip).** Porting retail's `UIRegion::DrawHere @0x0069FA30` ancestor-clip intersection (an element's screen rect is intersected against the FULL inherited clip-rect chain and the subtree is skipped when the intersection is empty — the `var_24` gate @0x0069FB8E) as `UiElement.ClipsChildren`'s new client-wide default (true, threaded through the pre-existing `UiRenderContext.PushClip`/`PopClip`) needed one deliberate opt-out: retail spawns a menu's dropdown popup as a SEPARATE top-level region (`UIElement_Menu::MakePopup`), clipped only by the screen, while acdream's `UiMenu` draws its popup INLINE from the owning button in a second traversal (`OnDrawOverlay`, pre-existing, "regardless of this element's position in the tree" by its own doc comment). Without an escape, the new ancestor clip would wrongly cut off a popup that legitimately extends outside its own (possibly short) owning window — e.g. a channel dropdown opened upward past a short chat window's top edge. `UiElement.ExpandsClipForPopup` (default false) resets the accumulated clip to the full CANVAS rect (0,0,ScreenSize) — SCREEN-clipped, not truly unbounded, matching retail's own popup region (`UIElement_Menu::MakePopup` spawns a top-level region bounded by the screen) — for exactly the `OnDrawOverlay` call of an opted-in element (`UiRenderContext.PushClipUnbounded`, sharing the existing clip stack; corrected from an earlier `null`/unbounded clip at the CT-GF1 fix round); `UiMenu` overrides it true, paired with `ClipsChildren => false` so its own out-of-bounds `OnHitTest` union (the popup occupies `ly < 0` or `ly >= Height` depending on open direction) stays reachable through the same early-bounds gate that now defaults on for every other element. | `src/AcDream.App/UI/UiElement.cs` (`ClipsChildren`, `ExpandsClipForPopup`, `DrawOverlays`); `src/AcDream.App/UI/UiRenderContext.cs` (`PushClipUnbounded`); `src/AcDream.App/UI/UiMenu.cs` (the two overrides) | The popup is the ONLY overlay-drawing widget in the tree today (grep-confirmed: exactly one `OnDrawOverlay` override client-wide), and it already renders on top of the whole UI by construction (the overlay pass beats even rect backgrounds), so exempting it from the ancestor clip matches its existing "regardless of tree position" contract rather than introducing new behavior. | A future `OnDrawOverlay` override that is NOT a screen-anchored popup (e.g. an in-place highlight meant to stay window-clipped) would silently escape every ancestor's clip if it left `ExpandsClipForPopup` at its default; the opt-in default direction makes that the exception rather than the rule, but a widget that WANTS window-clipped overlay content has no dedicated seam beyond simply not overriding the escape. | `UIRegion::DrawHere @0x0069FA30`; `UIElement_Menu::MakePopup`; the register's own AP-201 retirement note (the FIRST `ClipsChildren`/`PushClip` port, for `UiScrollablePanel`'s viewport) |
+| AD-118 | **Filed 2026-09-03 at Campaign OVERHAUL v2 S3 (docs/ISSUES.md #458, resolved).** The walk's portal-view EDGE PLANES are built from acdream's own float projection (`WalkCopyView` on `IWalkRayCaster`'s unprojected rays; the replay context's `Matrix4x4` view-proj), while retail builds them in `Render::copy_view @0x0054dfc0` from D3D-transformed screen points under x87 arithmetic. The planes agree to about 0.5 % (measured live at the Holtburg doorway: the fourth door-edge plane's clip height at the ring-21 block `a9c9` is 300.4/310.2 m in retail vs 298.8/308.5 m here — a slope ratio of 0.05104 vs 0.05042, roughly 0.35 px of projected door-vertex position at 720p), which is invisible everywhere except at a block/cell corner that sits within that margin of a plane: there `Render::block_check`'s four-corner unanimity test can flip PartiallyInside↔Outside for a far LOD block (one corner inside for us, outside for retail), admitting or skipping a whole distant land block retail decides the other way. | `src/AcDream.App/Rendering/Walk/WalkCopyView.cs` (per-edge plane build); `src/AcDream.App/Rendering/Walk/WalkVisibilityMath.cs` (`FillClipHeights`, `CornerPlaneCheck`, `BlockCheck`); `tests/AcDream.App.Tests/Rendering/Walk/WalkTraceReplay.cs` (the replay's projection) | Bit-exact agreement would require reproducing D3D's x87 vertex transform and `copy_view`'s exact rounding order; the algorithm, sentinels, loop shape, z slab padding and verdict logic are all ported verbatim and reproduce three of four capture poses exactly at the eight-kind transcript level. | A land block at ≥ 20 rings whose corner lies within ~0.5 % of a doorway edge plane may be drawn where retail skips it (or vice versa) — one far, low-LOD block, no known visible artifact; the `WalkTraceConformanceTests.Oh_doorway_still_first_frame_diff` row stays `KnownFailure` as the standing example. | `Render::copy_view @0x0054dfc0`; `Render::get_clip_height @0x0054cff0`; `Render::block_check @0x0054dc50`; `LScape::draw_check_blocks @0x00505f80` (the `if (esi_3 != 0)` residency gate and the per-view `block_check` call @0x005061df); captures `docs/research/2026-09-01-overhaul/oh-capture/holtburg-doorway-still.blockcheck.log` / `.blockset.log` |
 
 ---
 

docs/research/2026-09-01-overhaul/oh-capture/README.md

@@ -12,6 +12,7 @@ capture is the detach frame and carries no events — never count it.
 | `holtburg-doorway-still` | interior `a9b4013f`, ov=2 | walk / parts / alphadepth |
 | `terrace-edge` | outdoor `f418000b` (14 buildings, identical to FW0) | walk / parts / alphadepth |
 | `foundry-deep` | interior `a9b40176`, ov=1 | walk / parts / alphadepth |
+| `holtburg-doorway-still` #458 follow-up (2026-09-03 afternoon, a NEARBY pose — its own `P` line, not the walk capture's) | interior `a9b4013f`, ov=2 | `blockset` (every `Render::block_check` call of one frame: 2,601 blocks × 2 views + the return codes; `oh-capture-blockset.cdb.template`) / `blockcheck` (block `a9c9` only: the four corner interval vectors, z slab 75..330, ret 1 then 0; `oh-capture-blockcheck.cdb.template`) |
 
 `oh-recon.log` is the offset/breakpoint recon that PASSED before the poses.
 Per-pose counts and observations: `../s3-walk-ownership-map.md` §6b.

docs/research/2026-09-01-overhaul/oh-capture/holtburg-doorway-still.blockcheck.log

@@ -0,0 +1,124 @@
+Opened log file 'C:/Users/erikn/source/repos/acdream/.claude/worktrees/peaceful-blackburn-5333f0/logs/oh-capture/holtburg-doorway-still.blockcheck.log'
+0:018> .sympath C:\Users\erikn\source\repos\acdream\refs
+Symbol search path is: C:\Users\erikn\source\repos\acdream\refs
+Expanded Symbol search path is: c:\users\erikn\source\repos\acdream\refs
+
+************* Path validation summary **************
+Response                         Time (ms)     Location
+OK                                             C:\Users\erikn\source\repos\acdream\refs
+0:018> .symopt+ 0x40
+Symbol options are 0xB0367:
+  0x00000001 - SYMOPT_CASE_INSENSITIVE
+  0x00000002 - SYMOPT_UNDNAME
+  0x00000004 - SYMOPT_DEFERRED_LOADS
+  0x00000020 - SYMOPT_OMAP_FIND_NEAREST
+  0x00000040 - SYMOPT_LOAD_ANYTHING
+  0x00000100 - SYMOPT_NO_UNQUALIFIED_LOADS
+  0x00000200 - SYMOPT_FAIL_CRITICAL_ERRORS
+  0x00010000 - SYMOPT_AUTO_PUBLICS
+  0x00020000 - SYMOPT_NO_IMAGE_SEARCH
+  0x00080000 - SYMOPT_NO_PROMPTS
+0:018> .reload /f acclient.exe
+0:018> r $t0 = 0
+0:018> r $t8 = 0
+0:018> bp 00453aa0 "r $t0 = @$t0 + 1; .printf \"F %d\\n\", @$t0; .printf \"P %08x %08x %08x %08x %08x %08x %08x %08x\\n\", poi(0081ef00+4), poi(0081ef00+0x3c), poi(0081ef00+0x40), poi(0081ef00+0x44), poi(0081ef00+8), poi(0081ef00+0xc), poi(0081ef00+0x10), poi(0081ef00+0x14); .if (@$t0 < 0n2) { gc }"
+0:018> * NOTE (2026-09-03, first run): `poi(...) == 0xa9c9ffff` never matched ? cdb
+0:018> * sign-extends the 32-bit read inside `.if`, so the equality is false for any
+0:018> * DID with the top bit set. `dwo(...)` reads an unsigned dword; the blockset
+0:018> * template proved the register facts (did=a9c9ffff at gx=25 gy=46, twice a
+0:018> * frame for the two doorway views).
+0:018> bp 0054dc50 ".if (dwo(@esi+0x28) == 0xa9c9ffff) { r $t8 = 1; .printf \"BC did=%08x gx=%d gy=%d max=%08x min=%08x\\n\", dwo(@esi+0x28), @ebx, @ebp, dwo(@esp+0x14), dwo(@esp+0x18); .printf \"W0\"; dd poi(@esp+4) L20; .printf \"W1\"; dd poi(@esp+8) L20; .printf \"E0\"; dd poi(@esp+0xc) L20; .printf \"E1\"; dd poi(@esp+0x10) L20 }; gc"
+0:018> bp 005061e9 ".if (@$t8 == 1) { .printf \"BR ret=%d\\n\", @eax; r $t8 = 0 }; gc"
+0:018> g
+F 1
+P a9b4013f 430542ff 415c0def 42c0a8f8 bf7bf267 3e13e94a 3c745f23 bdd02083
+BC did=a9c9ffff gx=25 gy=46 max=43a50000 min=42960000
+W017c59818  00000000 00000000 00000000 00000000
+17c59828  43963738 00000000 03000000 00000000
+17c59838  02000000 04030201 06090704 090e0a06
+17c59848  0c120e08 0f17110a 131c150c 1621190e
+17c59858  19251c10 1c2b2012 1f2f2314 23332615
+17c59868  27392a18 2a3f2f1a 2d43321c 3148351e
+17c59878  334d3920 37523d22 3b584124 3e5b4426
+17c59888  41614828 45654b2a 47694e2b 496c502c
+W117c59898  00000000 00000000 00000000 00000000
+17c598a8  439b1786 00000000 537c5c33 537c5c33
+17c598b8  537c5c33 537c5c33 527a5a32 51795a32
+17c598c8  50765731 4e73552f 4c70532e 496c502c
+17c598d8  47694e2b 45654b2a 41614828 3e5c4426
+17c598e8  3b584124 37523d22 344e3a20 3148351e
+17c598f8  2d43321c 2a3f2f1a 27392a18 24352716
+17c59908  20302414 1c2b2012 19251c10 1621190e
+E017c57e18  00000000 00000000 00000000 00000000
+17c57e28  43963738 00000000 5818005c 00561700
+17c57e38  16005916 5716005a 004d1700 16003c17
+17c57e48  3b18003a 003b1700 16004116 5417004e
+17c57e58  00571600 14005615 4e150054 00401300
+17c57e68  0e003411 230a002d 00160700 01000201
+17c57e78  09030004 000f0400 08001806 2e090024
+17c57e88  00380b00 0c00410c 530d004a 005c1100
+E117c57e98  00000000 00000000 00000000 00000000
+17c57ea8  439b1786 00000000 04007e04 8008007f
+17c57eb8  00800c00 13007f10 8010007f 00801200
+17c57ec8  1d008018 7a1e007f 00782300 1e006d23
+17c57ed8  4d1c005a 00471a00 1a00471a 50190048
+17c57ee8  00591900 19005f19 60160062 00591600
+17c57ef8  15005516 4f160053 00461700 16003a16
+17c57f08  3b17003a 003f1600 18004917 5f180056
+BR ret=1
+BC did=a9c9ffff gx=25 gy=46 max=43a50000 min=42960000
+W017c59818  00000000 00000000 00000000 447a4000
+17c59828  4396371f 00000000 03000000 00000000
+17c59838  02000000 04030201 06090704 090e0a06
+17c59848  0c120e08 0f17110a 131c150c 1621190e
+17c59858  19251c10 1c2b2012 1f2f2314 23332615
+17c59868  27392a18 2a3f2f1a 2d43321c 3148351e
+17c59878  334d3920 37523d22 3b584124 3e5b4426
+17c59888  41614828 45654b2a 47694e2b 496c502c
+W117c59898  00000000 00000000 00000000 447a4000
+17c598a8  439b176b 00000000 537c5c33 537c5c33
+17c598b8  537c5c33 537c5c33 527a5a32 51795a32
+17c598c8  50765731 4e73552f 4c70532e 496c502c
+17c598d8  47694e2b 45654b2a 41614828 3e5c4426
+17c598e8  3b584124 37523d22 344e3a20 3148351e
+17c598f8  2d43321c 2a3f2f1a 27392a18 24352716
+17c59908  20302414 1c2b2012 19251c10 1621190e
+E017c57e18  00000000 00000000 00000000 447a4000
+17c57e28  4396371e 00000000 5818005c 00561700
+17c57e38  16005916 5716005a 004d1700 16003c17
+17c57e48  3b18003a 003b1700 16004116 5417004e
+17c57e58  00571600 14005615 4e150054 00401300
+17c57e68  0e003411 230a002d 00160700 01000201
+17c57e78  09030004 000f0400 08001806 2e090024
+17c57e88  00380b00 0c00410c 530d004a 005c1100
+E117c57e98  00000000 00000000 00000000 447a4000
+17c57ea8  439b176a 00000000 04007e04 8008007f
+17c57eb8  00800c00 13007f10 8010007f 00801200
+17c57ec8  1d008018 7a1e007f 00782300 1e006d23
+17c57ed8  4d1c005a 00471a00 1a00471a 50190048
+17c57ee8  00591900 19005f19 60160062 00591600
+17c57ef8  15005516 4f160053 00461700 16003a16
+17c57f08  3b17003a 003f1600 18004917 5f180056
+BR ret=0
+F 2
+P a9b4013f 430542ff 415c0def 42c0a8f8 bf7bf267 3e13e94a 3c745f23 bdd02083
+eax=27948130 ebx=00000009 ecx=00a566d8 edx=3e900471 esi=00a566d8 edi=009a09b0
+eip=00453aa0 esp=001afe84 ebp=001aff74 iopl=0         nv up ei pl nz na pe nc
+cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00200206
+acclient!SmartBox::RenderNormalMode:
+00453aa0 a130f38600      mov     eax,dword ptr [acclient!RenderDevice::render_device (0086f330)] ds:002b:0086f330=00a64b88
+0:000> .echo ===DETACHING===
+===DETACHING===
+0:000> qd
+quit:
+NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\Visualizers\atlmfc.natvis'
+NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\Visualizers\concurrency.natvis'
+NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\Visualizers\cpp_rest.natvis'
+NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\Visualizers\ObjectiveC.natvis'
+NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\Visualizers\stl.natvis'
+NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\Visualizers\Windows.Data.Json.natvis'
+NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\Visualizers\Windows.Devices.Geolocation.natvis'
+NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\Visualizers\Windows.Devices.Sensors.natvis'
+NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\Visualizers\Windows.Media.natvis'
+NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\Visualizers\windows.natvis'
+NatVis script unloaded from 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\Visualizers\winrt.natvis'