Oliver Kieselbach
b36cf8ff36
Round-two review, both findings confirmed against the code. A replayed exit was being confirmed as post-AccountSetup by reading the registry at replay time. That read reflects NOW, not the event's time, so an agent that was down across the DeviceSetup→AccountSetup transition would confirm the stale intermediate exit and, once the apps settled, synthesise a completion while the AccountSetup page was still up. Windows offers no way to tell the two apart from the event itself — Shell-Core writes the identical description CommercialOOBE_ESPProgress_Page_Exiting for both. So the deferred edge is now armed by LIVE exits only (EspExitedEventArgs.IsBackfill): only for those is the continuous-observation argument valid. A replayed exit keeps the single immediate synthesis attempt it always had. For that attempt to be worth anything it must see real data, so the replay moved out of EspAndHelloHost.Start() into ReplayEspExitBackfill(), invoked from ImeLogHost.onStateRestored — after LoadState() has restored the package states. That is what makes "the agent came back long after the ESP finished" recoverable. The five-minute window for non-reboot restarts was unsound: the scheduled task carries a BootTrigger only, with no restart-on-failure, so after an exception_crash the agent does not return until the next boot — hours later, long after Windows wrote the final exit. The window is now measured rather than guessed: back to the last moment the previous run is known to have been alive, taking the wider of the snapshot mtime (rewritten every decision step, available for every exit type) and LastBootUtc. The five-minute default is the floor, ClampLookbackMinutes the ceiling, and a future timestamp from clock skew is ignored instead of producing a negative window. Also switched the backfill tests to the real Shell-Core wording — the invented string matched the regex but hid the fact that both exits look identical. 9 new tests. Agent V2.Core 2362, 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.