Kiosk won't start

Symptom: the device powers on, but you don't end up at the QR claim screen or the assigned content. Could be any of:

• Stuck on the Windows boot screen
• Stuck at the lock screen / login screen
• Auto-login completes but the desktop is showing instead of the sign app
• Sign app launches then immediately closes
• Boot loop (BIOS POST → Windows logo → restart, repeat)
• BSOD

This page walks the path from "did Windows boot at all" inward.

Quick diagnostic

Press Ctrl+Alt+End if you're connected via RDP, or just plug in a keyboard and watch the screen during boot. The visible state at each stage tells you where to look:

Renderer crashed but the app came back

Before triaging "kiosk won't start," check whether the app actually went down. Two distinct failure modes can both look like a brief outage:

• Renderer crash → auto-recovery (1s). GpuMonitor sees the renderer process die, schedules a deferred reload() after 1 second, the wall comes back. The whole-app process never died. The dashboard Event log records one process_crash event; the sign doesn't transition to offline.
• Whole-app crash → scheduled-task relaunch (30-60s). The Windows scheduled-task watchdog catches the dead app and relaunches it. The sign briefly transitions to offline, then back to online after ~60s.

If you're investigating because someone said "the wall went down," the first check is which of these happened. The dashboard's Event log on the sign detail page is the source of truth — if you see one process_crash and the state stayed online, GpuMonitor handled it and there's nothing left to investigate. If the sign actually went offline, the rest of this page applies.

BIOS or boot loop

The device cycles through POST → Windows logo → restart, never reaching the desktop.

Likely causes:

• Failing storage — the SSD is dying. Confirm by listening for clicking sounds (older drives) or checking SMART status if you can boot to recovery media.
• Bad recent Windows Update — known regression in Windows; wait 24-48 hours and try again, or use Windows recovery to roll back.
• Corrupt boot record — usually after improper shutdowns. Boot from Windows install media and run bootrec /fixmbr; bootrec /fixboot; bootrec /rebuildbcd.
• Recently changed BIOS settings — a tech tweaked something. Reset BIOS to defaults, then re-apply only the DisplaySync settings.

If the device is in repeated boot loop with no obvious recent change, the fastest path is usually USB recovery — wipe and reimage from your captured image rather than chase a per-symptom fix.

Windows boot takes forever or stalls

The Windows logo is up but boot never completes (>5 minutes).

Likely causes:

• Windows Update applying changes — wait. The first boot after a major update can take 10-15 minutes on weaker hardware. Be patient.
• Pending Sysprep — happens if the kiosk was captured but never finished Sysprep on this clone. Check Event Viewer for Sysprep-related errors after you finally get in.
• Failing storage — see boot loop above.

Fix the slow Windows Update problem long-term by configuring active hours and overnight install windows — see Kiosk configuration → Windows Update active hours.

Auto-login not firing

The device boots to the Windows lock or login screen and stops there. The kiosk user should auto-login — the dashboard expects this within ~10 seconds of boot complete.

Diagnose:

# Inspect the Winlogon registry values from another admin account
$winlogon = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
Get-ItemProperty -Path $winlogon -Name AutoAdminLogon, DefaultUserName, DefaultDomainName

Check that:

• AutoAdminLogon = "1" (string, not 1 integer)
• DefaultUserName = "DisplaySync" (or whatever you named your kiosk user)
• DefaultDomainName = the local computer name
• A DefaultPassword value exists (it'll show the password in plaintext — that's how Windows stores it; this is why the account is intentionally low-privilege)

Common breakages:

Sign app not auto-starting

Auto-login worked — you see the desktop briefly — but the DisplaySync sign app never launches.

Diagnose:

# Confirm the scheduled task exists and is configured
Get-ScheduledTask -TaskName "DisplaySync Sign" |
  Format-List TaskName, State, Triggers, Actions

Get-ScheduledTaskInfo -TaskName "DisplaySync Sign"

What you're checking:

• State: Ready (or Running). Not Disabled.
• Triggers: at logon, for the kiosk user.
• LastTaskResult: ideally 0. Anything else is the failure code.
• NumberOfMissedRuns: should be 0 for a recent boot.

Common breakages:

Kiosk app launches then immediately closes

The sign app appears for a fraction of a second then exits. The watchdog will relaunch it, so you may see this cycle every 60 seconds.

Diagnose: look at sign.log (full runtime log) or error.log (ERROR-level only — faster triage). See File locations for the paths.

Get-Content "C:\ProgramData\DisplaySync\logs\sign.log" -Tail 100

# Or tail the live log while reproducing the crash
Get-Content "$env:ProgramData\DisplaySync\logs\sign.log" -Wait -Tail 20

The last 50 lines before the crash will tell you what happened.

Common patterns and fixes:

If the log doesn't reveal the cause and you have a recent rollback path, restoring the kiosk image is faster than continuing to diagnose.

Bluescreen

Windows BSODs are about hardware or drivers, not the sign app. The sign app runs in user-space — it cannot cause a BSOD.

Common causes:

• Failing RAM — run Windows Memory Diagnostic from boot media
• Failing storage — listen for unusual sounds, check SMART
• Bad driver update — common after Windows Update; roll back the most recent driver
• Overheating — packed conference rooms hit 30°C+; check thermal paste, dust filters, fan operation

If a single device BSODs repeatedly during an event, swap it out — diagnosing on-site is rarely worth the time pressure.

Sign app keeps relaunching, watchdog won't give up

The crash-recovery scheduled task watchdog restarts the sign app on crash with up to 3 retries per minute. To stop the cycle while you debug, enter maintenance mode atomically — set the sentinel + cleanly exit in one step, no race with the watchdog.

Right way: Ctrl+Shift+Q at the kiosk. The hotkey writes the .maintenance sentinel to the data root and exits the app cleanly in one step. See Hotkeys → Ctrl+Shift+Q.

Ctrl+Shift+Q

The sign app exits within ~1 second; the watchdog sees the .maintenance sentinel on its next 60s tick and skips relaunch. You now have a stable desktop to work on.

To re-enable the watchdog when you're done debugging:

Remove-Item "$env:ProgramData\DisplaySync\.maintenance" -Force
# Then either reboot or manually launch the sign app — the app deletes the sentinel itself on clean startup

Don't manually New-Item the .maintenance file alone — between when you create the sentinel and when the running app process actually exits, the watchdog may already have launched another instance. The hotkey is the atomic version.

Multiple DisplaySync Sign processes running

If the watchdog has been thrashing or a prior crash left an orphan, you can end up with multiple kiosk processes. Symptoms: dashboard heartbeat flickers, log writes overlap, port-bind errors in error.log.

Diagnose:

Get-Process -Name "DisplaySync Sign" | Measure-Object | Select-Object -ExpandProperty Count

Expected: 1 (the watchdog ensures one running instance). If > 1, an orphan from a prior crash is still alive.

Fix:

Stop-Process -Name "DisplaySync Sign" -Force
# Then either wait 60s for the watchdog to relaunch, or launch manually:
Start-Process "C:\Program Files\DisplaySync Sign\DisplaySync Sign.exe"

The watchdog will pick up cleanly on its next 60s tick if the running set is empty.

Last-resort recovery

When you can't fix the device in place during a live event:

1. Swap in a spare — physically replace with a working pre-imaged spare. Re-claim from the dashboard.
2. USB recovery — boot from your recovery USB and reimage.
3. Image redeploy — if you have the captured image and a network-attached imaging tool, push the image to the affected device.

For non-event timing (post-show triage), it's often worth understanding what failed so you can prevent the same issue on the rest of the fleet. For event-time, just get a working device on that wall.

Still stuck

Capture per Getting support:

• Last 500 lines of sign.log
• Get-ScheduledTask -TaskName "DisplaySync Sign" | Format-List * output
• Output of the Winlogon registry inspection above
• Recent Windows Event Viewer entries (Application + System logs, errors only, last 24h)
• A photo of the wall in its broken state

Then reach out — the failure mode plus the logs is usually enough to triage.