Oliver Kieselbach
47ffb348a9
Production session d434a3ba (12d stuck, ANALYZE-APP-012 first-ever fire) tripped Table
Storage's 64KB property limit on RuleResult.MatchedConditionsJson — the correlation
evaluator embedded full eventA/eventB Message + errorDetail (often multi-KB stack
traces) for every matched pair AND duplicated all pairs into an uncapped allMatches
list. The queue-path retry/poison architecture caught the StoreRuleResultAsync false
return correctly, but the underlying evidence shape was the root cause.
Three layers of fix:
1) Root cause — RuleEngine.ConditionEvaluators.cs (EvaluateEventCorrelationCondition):
- Drop eventA_message / eventB_message (free-text, can be huge)
- Drop errorDetail from AddDataFieldsToEvidence whitelist (often a stack trace)
- Cap allMatches at 10 pairs + matchesTruncated flag for the rest
- Per-pair evidence now ~500 bytes; UI lazy-loads full event via /events/{id}
2) Defense-in-depth — TableStorageService.Rules.cs (StoreRuleResultAsync):
Pre-flight check on JsonConvert.SerializeObject(MatchedConditions). If output
exceeds 60KB (4KB headroom under the 64KB hard limit), substitute a small
truncation marker {_truncated, _originalBytes, _reason} and log a warning.
Future rules that overshoot still persist + flag instead of failing opaquely.
3) Manual-path observability — GetRuleResultsFunction.cs (?reanalyze=true):
Check StoreRuleResultAsync bool, collect failed RuleIds, log structured Error,
return HTTP 200 with {success:false, persistFailureCount, persistFailureRuleIds}.
Partial-success rather than 500: UI keeps rendering the rules that DID persist.
Optional UI banner can read persistFailureCount in a follow-up.
Tests: +3 RuleEngineCorrelationEvidenceSlimTests pin the slim evidence shape, the
allMatches cap (25 pairs → 10 + truncated=true), and the no-truncate path (3 pairs
→ truncated=false). 773/773 backend pass.
Follow-up after deploy: re-queue the existing poison message (1a72afdc-...) for
session d434a3ba. With slim evidence the persist should succeed cleanly; only then
delete from poison. If it fails again, the 60KB guard adds a truncated marker and
the Rule still persists.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Autopilot Monitor
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.
Private Preview
Autopilot Monitor is currently running as a Private Preview. Visit autopilotmonitor.com to request access and learn more.
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 documentation is available at autopilotmonitor.com/docs
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.