Oliver Kieselbach
ec945a93d2
Round-three review, confirmed. The previous round stopped a replayed exit from arming the DEFERRED re-check but left the immediate synthesis attempt right below it untouched. My justification for that — "pre-existing behaviour" — was simply wrong: the immediate attempt on a replayed exit never existed, because the backfill had no caller. I introduced it, and by moving the replay behind the IME state restore I made the dangerous state reachable by design: if the newest 62407 in the window is only the intermediate DeviceSetup→AccountSetup exit while the restored app states are already terminal, that attempt opens the strong AccountSetup gate before the final exit has even happened. A test was pinning the faulty assumption as expected behaviour. A replayed exit now returns before touching completion at all — no deferred edge, no immediate attempt. Nothing available to it can establish its position in time: Shell-Core writes the identical description for both exits, and every probe that could order it reads state as it is now rather than at the event's time. The replay keeps the job it was written for in session 772fe502 — feeding EspExiting, FinalizingSetup and the Hello wizard to the reducer for the window in which no agent process was observing. Completion is the exclusive business of exits this agent watched live. With the synthesis attempt gone, the replay no longer needs restored app states, so it moves back into EspAndHelloHost.Start(); that also keeps this host's startup independent of the IME host's. ImeLogHost.onStateRestored goes back to doing just the re-check, which is still needed for a live exit observed before the restore finishes. The test asserting the faulty assumption is inverted, plus coverage that the replay is not neutered (EspExiting still forwards) and that a live exit following a replayed one completes normally. Agent V2.Core 2364, 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.