Step 1 of 5
Logs
Start with the diagnostic ZIP from the device. Those files are the real story of what happened during setup — without them, troubleshooting is only a guess.
TraceAnalysis
TraceAnalysis
Invited beta · Autopilot forensics
See why Autopilot stalled — with evidence, not guesswork.
Turn DeviceSetup hangs and enrollment failures into a primary finding, confidence factors, and fixes your team can act on.
US-only beta for now
ZIP stays in your browser. Masked findings go to OpenAI (United States) for the AI explanation. Reports are kept 30 days by default. See what moves where.
What you get from a diagnostic ZIP
TraceAnalysis is built for Autopilot failure forensics — so you leave with a decision, not another pile of logs to decode.
One primary finding
Opaque Autopilot dumps become a clear blocker you can put on a ticket — not a wall of warnings to reinterpret.
Evidence before narrative
Parsers and rules rebuild the timeline and rank a root cause. The LLM explains the finding; it does not invent it.
Remediation you can run
Matched Autopilot shapes — ESP DeviceSetup, MDM enrollment, TPM, hybrid join, Win32 conflicts — come with next steps.
How a diagnosis moves
From the ZIP on disk to a ticket-ready explanation — each step is grounded in parsed events and known Autopilot failure patterns.
Logs → finding → explain
Step 2 of 5
Parse
We read the dump and turn messy log lines into clear events — times, error codes, and setup stages — so the important moments are easy to see.
Step 3 of 5
Rules
We compare those events to known Autopilot failure patterns — like a stuck DeviceSetup screen or a failed app install — so answers come from evidence, not AI invention.
Step 4 of 5
Finding
You get one clear primary answer: what blocked enrollment and how confident we are. That focus helps you fix the real issue instead of chasing every warning.
Step 5 of 5
Explain
Plain-language guidance and next steps, based on that finding — so you or your help desk know what to try next without digging through raw logs.
For your security review
What leaves your machine — and what doesn’t
The short version security teams ask for first: the diagnostic ZIP stays local, the AI path is named, and retention is not buried.
ZIP never leaves the browser
Collect Diagnostics / Autopilot dumps are opened and parsed on your device. The raw ZIP is not uploaded to TraceAnalysis.
Stand-ins, then OpenAI (US)
Common identifiers become stand-ins such as device-1 and app-1 before a structured finding is sent to OpenAI’s API (default gpt-5.4-mini). OpenAI doesn’t train on this data. An OpenMed second pass may run on our model host before the call. If OpenAI is unavailable, a model we host is the fallback.
Reports kept 30 days by default
Diagnostic reports, chat, and related session records are retained for 30 days, or until you delete them. Account records last until you ask us to remove them or the beta ends.
Full detail: Privacy Notice · Sub-processors · DPA
Your ZIP is opened in your browser and never uploaded. Common identifiers are replaced with stand-ins (such as device-1 and app-1) before a structured finding is sent to OpenAI (United States) for AI analysis. OpenAI does not train on this API data; it may retain inputs and outputs up to 30 days for abuse monitoring. Masking is imperfect and may miss some values. Findings are stored with your report for 30 days by default, along with account and usage records.
Built for the people who own the outage
Same product, three jobs — so the right person gets the right depth without drowning in raw ESP tables.
Intune / Autopilot admins
Cut hours of log archaeology when DeviceSetup hangs or enrollment fails mid-fleet.
Help desk leads
Hand techs a ticket-ready problem, root cause, confidence, and fixes instead of a console dump.
Security-minded operators
ZIP stays local. Stand-in-masked findings go to OpenAI (US). Reports are kept 30 days by default — details on the homepage and in Privacy.
Dig aid vs ticket-ready
Same Autopilot ZIP — two different jobs
Same ZIP. PowerShell shows ESP stages and error states. TraceAnalysis returns a senior-admin root cause you can put on a ticket.
Dig aid
Get-AutopilotDiagnosticsCommunity
- Job
- Show stages/errors so you dig
- Form
- Colored console dump
- What you get
- Profile/ESP flags, DEVICE/USER ESP tables, OBSERVED TIMELINE
- Trust
- Admin interprets
Dig aid, not a peer report engine.
Ticket-ready
TraceAnalysis Diagnose
- Job
- Name the blocker + next fix
- Form
- Schema finding + report UI
F01 excerpt
problemAutopilot / ESP DeviceSetup is blocked while required Win32 apps remain undetected during IME processing.
root_causeRequired Win32 applications targeted for ESP DeviceSetup did not pass detection (PowerShell detection exitCode 1, applicationDetected=False), while IME also reported AAD token acquisition failures that can stall app enforcement.
DimensionDig aidGet-AutopilotDiagnosticsCommunityTicket-readyTraceAnalysis Diagnose
JobDig aidShow stages/errors so you digDiagnoseName the blocker + next fix
FormDig aidColored console dumpDiagnoseSchema finding + report UI
What you getDig aidProfile/ESP flags; DEVICE/USER ESP tables; OBSERVED TIMELINEDiagnoseproblem, root_cause, confidence, evidence[], recommended_fixes[]
Failure signalDig aidStatus 4 / red timeline / exit codeDiagnoseNamed apps + detection exitCode 1 + AAD token factor
TrustDig aidAdmin interpretsDiagnoseRules confidence 0.85 + matched factors
PrivacyDig aidRaw dig on machine/logsDiagnoseScrub before cloud explain
Cites: PowerShell Gallery · Oofhours · MS Learn ESP
Request beta access
Invited beta for US-based Autopilot / Intune admins. Leave your email and we’ll send an invite when a seat opens.
US-only beta for now
Talk with us
Questions about deploying TraceAnalysis, fixture coverage, or knowledge sources? Send a note — we follow up by email.
Or email [email protected]