From cd806da576f5424f6c2373f6943a0d647f7dbdd7 Mon Sep 17 00:00:00 2001 From: Howard Enos Date: Tue, 23 Jun 2026 15:28:58 -0700 Subject: [PATCH] sync: auto-sync from HOWARD-HOME at 2026-06-23 15:28:30 Author: Howard Enos Machine: HOWARD-HOME Timestamp: 2026-06-23 15:28:30 --- .claude/memory/MEMORY.md | 1 + .claude/memory/project_ampipit.md | 33 +++++++++++++++++++ .../windows-offline-dism-repair-gotchas.md | 28 ++++++++++++++++ 3 files changed, 62 insertions(+) create mode 100644 .claude/memory/project_ampipit.md create mode 100644 .claude/memory/windows-offline-dism-repair-gotchas.md diff --git a/.claude/memory/MEMORY.md b/.claude/memory/MEMORY.md index f31b932e..197a1fe2 100644 --- a/.claude/memory/MEMORY.md +++ b/.claude/memory/MEMORY.md @@ -173,3 +173,4 @@ - [AD2 = Dataforth-ops fork](project_ad2_dataforth_fork.md) — branch ad2 = main + thin Dataforth layer; keep fork edits ADDITIVE (Dataforth context in clients/dataforth/CLAUDE.dataforth.md, NOT .claude/CLAUDE.md); rebase onto main directly when sync.sh self-lock hits; no vault/jq/sops/age on this box. - [GuruScan verification IN TEST / paused](project_guruscan_in_test_paused.md) — multi-engine scanner verify on DESKTOP-MS42HNC paused 2026-06-22 (VM rebooted mid-Emsisoft run); HitmanPro done (36 removed), Emsisoft full-scan unverified; resume `guruscan-agent-test.sh DESKTOP-MS42HNC scan-one Emsisoft`; Defender RTP/Tamper still off on VM - [GuruRMM fleet dispatch-hang fix](project_gururmm_dispatch_hang_fix.md) — blocking send_to on a full bounded channel to one black-holed agent wedged ALL command dispatch; fixed with try_send (9dae20c, deployed); proper black-hole eviction still missing (was reverted in 80df458) — finish it if it recurs +- [Windows won't-boot / offline DISM repair playbook](windows-offline-dism-repair-gotchas.md) — Automatic Repair loop = boot-critical fault (disk/registry/wedged update), NOT shell/appx store corruption (that's a symptom); `FaultyPackageInProgress` + 100s of Install/Uninstall-Pending packages = wedged CU -> RevertPendingActions or clean install. Offline DISM rejects `wim:` source (0x800f082e) -> MOUNT the wim, source `\Windows`. Ventoy breaks WIM mount (0xc1420134) -> use Rufus. 25H2(26200)=24H2(26100)+enablement, so match 26100 media. First hit: Four Paws AvImark #32447. diff --git a/.claude/memory/project_ampipit.md b/.claude/memory/project_ampipit.md new file mode 100644 index 00000000..3b7de855 --- /dev/null +++ b/.claude/memory/project_ampipit.md @@ -0,0 +1,33 @@ +--- +name: project_ampipit +description: AMPIPIT (A Modular Pre-install Post-Install Tool) — Howard's active Rust+Slint Windows deploy/recovery toolkit, being migrated into ClaudeTools as a private Gitea submodule. Will fold into GuruRMM. +metadata: + type: project +--- + +AMPIPIT is Howard's active Rust + Slint portable Windows deployment/recovery toolkit (single .exe, +runs live + in WinPE/WinRE). Currently at `C:\AMPIPIT` as its own git repo; Phases 0-5 code-complete +(832+ tests), Phase 6 hardware validation pending. NOT merely a "reference program" — it is a real +project under active development (supersedes the stale framing in [[project_masterbooter]] which +lists it as reference-only). + +**Migration in progress (2026-06-23):** bringing AMPIPIT into ClaudeTools as a **git submodule** at +`projects/msp-tools/ampipit`, matching the guru-rmm / guru-connect pattern (own repo on the ACG +Gitea `git.azcomputerguru.com`, referenced as a submodule). Active feature: a recovery partition +with the **GuruRMM agent + built-in repair-script library** baked in, so offline/broken Windows can +phone home for repair (Claude diagnoses via RMM, directs repair scripts — no direct shell). Spike +verdict GO-WITH-WORK. Design slice: `C:\AMPIPIT\docs\RECOVERY_RMM_DESIGN_SLICE.md`. + +**Why / hard constraints (Howard, 2026-06-23):** +- **Do NOT lose any of the existing work** — preserve full git history; back up to a verified second + remote (Gitea) BEFORE removing anything; remove `C:\AMPIPIT` only after full verification. +- **No public GitHub.** Howard is deleting the old public `github.com/Howweird/AMPIPIT` repo. AMPIPIT + must live PRIVATE on the ACG Gitea only. Drop the github remote after Gitea is verified. +- **Follow Mike's rules for Guru projects.** AMPIPIT already encodes the 3rd-party rule as ADR-047 + (first-party core; non-MS binaries only via the PE tool registry / RemoteAccessProvider / RmmAdapter + traits). The GuruRMM agent rides that pluggable path, never hardcoded into core. + +**How to apply:** When working on AMPIPIT, root the session in the AMPIPIT repo dir so its own +`CLAUDE.md`, coding/code-review/security-review agents, and the `ampipit-build` skill load. Use the +`ampipit-build` skill. Sensitive-domain changes (BCD/partition/WIM/USMT/recovery partition) require +the coding -> code-review -> security-review chain. diff --git a/.claude/memory/windows-offline-dism-repair-gotchas.md b/.claude/memory/windows-offline-dism-repair-gotchas.md new file mode 100644 index 00000000..be9bdb7d --- /dev/null +++ b/.claude/memory/windows-offline-dism-repair-gotchas.md @@ -0,0 +1,28 @@ +--- +name: windows-offline-dism-repair-gotchas +description: Windows won't-boot / offline DISM repair playbook — diagnose wedged-update boot loops, and the WinPE source/mount gotchas (wim: not allowed offline, Ventoy breaks WIM mount) +metadata: + type: reference +--- + +Field-learned gotchas for repairing a Windows box that won't boot, from offline WinPE/recovery. First hit on Four Paws AvImark server (Syncro #32447, 2026-06-23) — boot-looping into Automatic Repair. + +**1. Diagnose the REAL boot blocker before chasing DISM corruption.** +A machine that drops into **Automatic Repair** is failing on something boot-critical (disk, registry hive, boot files, or a wedged update) — NOT on shell/Search/appx component-store corruption. Component-store corruption in `ShellExperienceHost`/`StartMenuExperienceHost`/`windowssearchengine`/Cortana is a *symptom*, not the cause; repairing it does NOT fix the boot loop. Read the actual cause first: `C:\Windows\System32\LogFiles\Srt\SrtTrail.txt`, and run `chkdsk C: /f` (disk errors are the #1 Automatic Repair cause). + +**2. `FaultyPackageInProgress` + hundreds of "Install/Uninstall Pending" packages = a wedged cumulative-update transaction.** That IS the boot blocker. Confirm offline with `dism /Image:C:\ /Get-Packages /Format:Table` — look for many `Install Pending` / `Uninstall Pending` lines at the same timestamp (a half-applied CU swapping old build -> new build). Try to back it out with `dism /Image:C:\ /Cleanup-Image /RevertPendingActions`, or WinRE -> Troubleshoot -> Advanced -> Uninstall Updates -> "Uninstall latest quality update". If RevertPendingActions FAILS and there's no `pending.xml`, the transaction is too corrupt to repair in place -> clean install. + +**3. Offline DISM won't accept a `wim:` source (`0x800f082e CBS_E_NOT_ALLOWED_OFFLINE`).** For `/Image:C:\ /Cleanup-Image /RestoreHealth` you must **mount** the install.wim and point `/Source` at the mounted folder's `\Windows`, not use `/Source:WIM:...:idx`: +``` +mkdir C:\wimmount +dism /Mount-Image /ImageFile:D:\sources\install.wim /Index:6 /MountDir:C:\wimmount /ReadOnly +dism /Image:C:\ /Cleanup-Image /RestoreHealth /Source:C:\wimmount\Windows /LimitAccess /ScratchDir:G:\scratch +dism /Unmount-Image /MountDir:C:\wimmount /Discard +``` +Mount point must be an empty folder on a writable **NTFS local** drive (not the USB — Rufus UEFI sticks are FAT32 and hold the source itself). `0x800f0915` (repair content missing) usually means the offline backup store is gone and `/LimitAccess` blocked the WU fallback. + +**4. Ventoy breaks WIM mounting (`0xc1420134` / "GetMountedImagesKey... file not found").** Ventoy serves the ISO through a virtual driver that also blocks `wim:` source access. Use a **Rufus**-built install stick instead — mounting then works. + +**5. Build matters for the source: Win11 25H2 (build 26200) is 24H2 (build 26100) + enablement package; component store is 26100-versioned.** DISM matches on component version, not the marketing build, so the matching media for a 26200 box is a **24H2 / 26100 ISO**. Verify before repairing: `dism /Get-WimInfo /WimFile: /Index:6`. + +Related: [[cyndyoffice-physical-hp-lockups]], [[feedback_rmm_system_context_mapped_drives]].