Home › Setup guides › Capture logs from a failed build (run Decolla-Diag)
Setup guide · from scratch

Capture logs from a failed build (run Decolla-Diag)

If a build fails at any stage, run the one-touch Decolla-Diag tool on the USB. It captures every Windows Setup and Decolla log onto the stick for support - no commands to memorise, and the tool itself changes nothing on the machine. On a machine managed by Intune it first asks Windows to check in with Intune, and reports whether the Intune enrolment checked in.

Decolla provisioning USB (target machine)assisted guide — Decolla walks you through this
≈ 10 min
Windows — Autopilot & USB provisioning · step 9 of 12 · ≈ 10 min‹ PreviousNext ›
Do these first — this guide assumes you already have:
The Decolla way — skip the clicks.

Every step below can be done by hand. Or connect your Microsoft tenant to Decolla once, and Decolla performs this for you over Microsoft Graph in your own tenant — then hands back a verified result you can see and roll back per item. It also puts the fundamentals this step depends on in place — the target group, the licence allocation — so a build is never blocked half-way by a missing dependency.

⏱ By hand: about 10 min of clicking, every build. The Decolla way: part of one tenant connect, then automatic.
Before you start
  • The Decolla stick still plugged into the failed machine - it carries the DIAG tool and is where the capture is written.
  • The failed machine left exactly as it is - no reboot, no reformat - so the Setup and provisioning logs are still on disk to be swept.
  • The Shift+Fn+F10 trick for opening the Setup command prompt (most laptops need the Fn key).
  • A working PC or email access for afterwards, to hand the whole Decolla-Diag folder to Decolla support.
0 of 6 done
Step 1. If a build fails - the 'Windows 11 installation has failed' box, a machine stuck on a Setup screen, or a login that will not accept the password - do NOT reformat the stick or keep rebooting. The Decolla stick carries a one-touch diagnostic that grabs everything support needs. Leave the failed machine exactly as it is.
Screenshot: A 'Windows installation has failed' dialog on the target machine (captured during a live customer build — coming to this page)
Why: The reason it exists: the logs that explain the failure are sitting on the machine and the stick right now, and untouched is the only state they can be captured from.
Don’t: Do NOT reformat the stick or keep rebooting - a reformat erases the very diagnostic the stick carries, and each reboot risks moving the machine off the state that holds the answer.
Step 2. Open a command prompt on the failed machine. During Windows Setup or at the failure box: press Shift+F10 - on most laptops you must add the Fn key, so Shift+Fn+F10 (see the 'Boot a machine from the Decolla stick' guide for that Fn-key trap). If the machine has already booted into Windows instead, just open the USB stick in File Explorer.
Screenshot: The black WinPE command prompt open over Windows Setup (captured during a live customer build — coming to this page)
Why: The diagnostic runs from a command line during Setup, so you need the hidden Shift+Fn+F10 prompt first - unless Windows has already booted, where plain File Explorer is enough.
Watch for: On most modern laptops the top row is media keys, so plain Shift+F10 does nothing - use Shift+Fn+F10.
Step 3. Run the diagnostic. In the black command prompt, type the USB's drive letter then \DIAG - for example D:\DIAG - and press Enter. In Windows, double-click DIAG.cmd on the USB. It asks Windows for administrator rights itself - choose Yes when Windows asks, signing in with an administrator account if it asks for one - and a second window opens and does the capture. You do NOT need to know the USB's drive letter for the capture itself - the tool locates itself and writes back to its own stick.
Screenshot: Typing D:\DIAG at the command prompt (captured during a live customer build — coming to this page)
Why: One line kicks off the whole sweep - you point it at the stick and it finds, collects and files everything itself.
Watch for: The tool writes back to its own stick automatically, but you still have to LAUNCH it with the USB's real drive letter - D: is only the example, yours may differ.
Don’t: In Windows, do NOT close the window part-way to start again. If you chose No when Windows asked, let it finish - it still captures everything that does not need administrator rights and lists exactly what it left out - then run it again and choose Yes for the full capture.
Step 4. Wait for the word DONE. On a machine that is already running Windows and is managed by Intune, the tool first asks Windows to check in with Intune and waits up to two minutes to see whether it does. It then sweeps every drive for every Windows Setup log (Panther, $WINDOWS.~BT, DISM, CBS) and every Decolla provisioning log, plus a read-only machine snapshot (disk layout, boot config, hardware), and copies them into a timestamped folder on the USB named 'Decolla-Diag'. On a running Windows it also collects Microsoft's own management report and diagnostic bundle and the BitLocker status, so there is no second tool to run, and it finishes with three plain answers on the screen, straight above DONE: whether the Intune enrolment checked in after the tool asked, whether BitLocker settings from Intune are on the machine, and whether Windows has recorded the recovery key as backed up. If the first answer says the Intune enrolment did not check in, the capture shows the machine as of its last check-in, which that answer names; pressing Sync in Windows Settings (under Accounts, then Access work or school) is the way Microsoft documents to make it check in. The tool itself changes nothing on the machine and touches no partitions: asking for that check-in is the one thing it asks Windows to do. It leaves the organisation's keys behind: the build's settings are copied with every ticket and password blanked out.
Screenshot: The DONE message, showing whether it ran as an administrator and where the capture was saved (captured during a live customer build — coming to this page)
Why: It gathers every log support could ask for in a single pass - Setup logs, provisioning logs and a read-only hardware snapshot - so there is no second trip to fetch a missing file.
Watch for: Wait for the word DONE before pulling the stick - the wait for a check-in can take up to two minutes and the sweep covers every drive; yank it early and you keep a half-written capture. An answer that reads UNKNOWN is not a failure: the tool could not ask, could not read, or asked and saw no check-in in the time it waited - and it says which.
Step 5. Bring the stick back. Take the USB to any normal PC, or email the whole 'Decolla-Diag' folder from it to Decolla support. That folder contains everything needed to diagnose the failure - you will not be asked to type any more commands.
Screenshot: The Decolla-Diag folder on the USB in File Explorer (captured during a live customer build — coming to this page)
Why: The 'Decolla-Diag' folder is self-contained - handing over the whole folder is all support needs to work the failure, with no back-and-forth for more commands.
Don’t: Do NOT cherry-pick the one log you think looks relevant - send the WHOLE 'Decolla-Diag' folder; the answer often sits across several files.
Step 6. Optional, to read it yourself: the plain-English summary is 'Decolla-Diag\<machine>_<timestamp>\INDEX.txt'. Its first lines say whether the capture ran as an administrator, and its last section, NOT COLLECTED, lists anything it could not reach and why. Just above that, under INTUNE, are the same three answers the screen ended with. The actual Windows failure reason is usually the last lines of a 'setuperr.log' inside one of the '-BT-Panther' or '-Windows-Panther' subfolders; a Decolla provisioning failure is in the '-Decolla-logs' subfolder's provisioning.log.
Screenshot: INDEX.txt open in Notepad showing the captured file list (captured during a live customer build — coming to this page)
Why: INDEX.txt is the plain-English map into the capture - it tells you whether the failure was Windows Setup or Decolla provisioning before you open a single raw log.
Watch for: The real Windows reason is usually the LAST lines of setuperr.log - the top of the file is rarely where it went wrong.

If it goes wrong

The failures people actually hit on this process, each with the diagnosis and fix:

See it on a real device.

Decolla is in private build — early-access members see a build defined, deployed and rolled back first.

Get early access