Kernel bugcheck 0x1E (AV_nt!HvpGetCellMap) recurs 3x on build 26100.9457 / 26200.9457, never on the two prior builds

Short answer: not "diagnosed and fixed" — but it has stopped, and your dump corroborates the mechanism.

I re-scanned my four 0x1E minidumps (raw byte scan, no debugger): three of them contain a partial ...ache.hve string in the string pool at the identical file offset, one of those also carries an Amc fragment. That is consistent with \Windows\appcompat\Programs\Amcache.hve — the hive you named. Different machines, different processes, same hive-load path (NtLoadKeyEx -> CmLoadDifferencingKey/CmLoadAppKey -> CmpInitHiveFromFile -> CmpCreateHive -> CmpCheckRegistry2 -> HvCheckHive) and the same faulting instruction (mov rax,[rax+rdx*8] at nt!HvpGetCellMap+0x43, rax = 0xFFFFFFFFFFFFFFFF). So it is not Amcache-specific — Amcache is simply the hive that happened to be loading.

Two things I would push back on:

"Generic memory corruption" is a weak read. Four crashes at the identical instruction offset with rax = -1 is a deterministic code/data-structure fault, not random bit flips. Your machine and mine both passed mdsched/Intel PDT. Also note the faulting stack contains no third-party driver module, so Driver Verifier has nothing to catch here — I would not spend a restore point on it.

Your second signature matters. nt!CmpCheckRegistry2+0x2ad with exception 0xC0000096 (PRIV_INSTRUCTION) is the same hive-validation layer. Both of your signatures live in the same function pair — that strengthens "hive load/validation path" over "RAM".

What changed on my box, and the outcome:

Date Change Result

2026-10-02 BIOS A.K0 + microcode 0x133 -> 0x137 + Intel ME 16.1.42.2872 last 0x1E was that morning 08:06; none since

2026-10-03 KB5124010 preview -> 26200.9550 ~1.3 days clean

2026-10-04 13:09 last crash of any kind (0xC2, different family) —

2026-10-05 Windows 11 26H2 -> 26300.9550 (new kernel) 0 crashes in 5.4 days, previously ~1 crash every 1-3 days

So the 0x1E/HvpGetCellMap family has not recurred once, but three changes landed inside 72 hours and I cannot prove which one did it. Prior to that, five 0x1E crashes all sat on the 26200.9457 line and none on earlier builds — which is why I called it build-bound in the original post.

What I'd suggest for your SCAR 18:

Your i9-14900HX is the same Raptor Lake Vmin-shift class as my i9-14900KF. Read your actual microcode, don't trust the vendor changelog: (Get-ItemProperty 'HKLM:\HARDWARE\DESCRIPTION\System\CentralProcessor\0').'Update Revision' returns a byte array — read it as '{0:X2}{1:X2}' -f $r[1],$r[0] (little-endian). Update ASUS BIOS if it is behind.

Move off the 9457 line (newest cumulative / 26H2) and see if it stops. If it recurs on 26300+, post back — that would prove the fix is not in the newer kernel and the build-bound theory is wrong.

Two corrections to my original post, so nobody chases the wrong thing: my microcode at the time was 0x133 on BIOS A.J0 (not 0x151 — transcription error on my part), and my system disk is the WD_BLACK SN850X (Disk 0); the Patriot P400L is a secondary staged disk. Storage was never involved.

To avoid counting phantom crashes: HiberbootEnabled must be 0 and check Kernel-Boot Event 20 (last shutdown's success status) — a failed fast-startup produces a spurious Event 41/6008 on a perfectly clean shutdown.

One caution on your Google Drive link: minidumps can contain live credentials — mine had a production API key resident in three of them. Rotate anything that appeared in that dump set, and don't leave it publicly linked.