Oliver Kieselbach
b61d7023bc
Three real regressions, all confirmed against the code before touching it — two of them introduced by the recovery itself. The remembered exit edge was unqualified. Shell-Core raises 62407 at every ESP phase transition, so OnEspExited also latched the DeviceSetup→AccountSetup one; the deferred re-check would then open the strong AccountSetup gate as soon as the last user app settled, while the AccountSetup page was still up and its other subcategories still running. IsConfirmedPostAccountSetupExit() now demands positive evidence (AccountSetup activity observed, or SkipUser == true) and is deliberately stricter than the existing IsIntermediateDeviceEspExit() forward guard: an unknown SkipUser counts as not confirmed. Erring strict costs the pre-fix stall; erring loose costs a premature Succeeded. The immediate on-edge synthesis keeps its previous behaviour verbatim. The replay picked the oldest exit, not the final one. The reader walks oldest-first and the exit branch is fire-once, so the widened downtime window — which routinely holds both the intermediate and the final exit — handed over the intermediate one and the fire-once guard swallowed the exit that matters. ReplayBackfillRecords buffers the batch and lets only the newest exit-matching record through; ESP failures and the Hello-wizard rail keep replaying chronologically. The replay ran before the IME state restore. ImeLogTracker.Start() restores the persisted package states via LoadState() without raising OnAppStateChanged, and ImeLogHost starts after EspAndHelloHost, so the replay evaluated an empty app list — leaving the sharpest case unfixed: apps already terminal before the reboot, only the final exit lost to the downtime. ImeLogHost gained an onStateRestored callback wired to the re-check, and the host order is now pinned by DefaultComponentFactoryOrderingTests so a reshuffle fails loudly. 11 new tests. Agent V2.Core 2340, DecisionCore 533, Backend 4287, all green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
AutopilotMonitor
Advanced monitoring and troubleshooting solution for Windows Autopilot deployments. Gain full visibility into every enrollment session with a detailed event timeline, fleet health dashboards, and session reporting. Define custom analysis rules to automatically detect issues and gather rules to collect targeted evidence. Retrieve diagnostics packages on demand, configure agent settings like auto-reboot behavior and automatic timezone adjustment — all managed centrally from the web dashboard.
Availability
Autopilot Monitor is publicly available — the Community plan is free. Sign in with your work account at autopilotmonitor.com; new organizations complete a short activation step after first sign-in.
Overview
Autopilot Monitor provides real-time tracking, intelligent diagnostics, and automated troubleshooting for Windows Autopilot enrollment processes. It consists of:
- Bootstrap Script — PowerShell script deployed via Intune that starts monitoring early in the enrollment process
- Monitoring Agent — Lightweight .NET application that collects telemetry and evidence during enrollment
- Backend API — Azure Functions-based ingestion and processing pipeline
- Web Dashboard — Next.js application for real-time monitoring and fleet analytics
Architecture
For detailed information about the system architecture, components, and data flow, see Architecture Documentation.
Documentation
Full admin documentation is available at docs.autopilotmonitor.com
License
This project uses a split licensing model:
- MIT License — Agent (
src/Agent/) and Shared library (src/Shared/) — unrestricted use on end-user devices - AGPL-3.0 — Backend (
src/Backend/), Web Dashboard (src/Web/), and MCP Server (src/McpServer/) — server-side components remain open source
See LICENSE for full details.