Docs / Troubleshooting & FAQ / Common issues
Troubleshooting & FAQ · Chapter 1 of 1

Common issues

The failure modes that show up most often in real MAS 2.0 use, with the recovery step and the log evidence to grab if the recovery doesn't help.

5 min read
Applies to v2.0+
Last updated 2026-07-19
PUBLISHED

The failure modes that show up most often in real MAS 2.0 use, with the recovery step and the log evidence to grab if the recovery doesn't help.

Every entry follows the same shape: symptom → what it means → recovery → log evidence. The log evidence line names the Serilog context (usually MAS.<Layer>.<Class>) that emits the diagnostic line — grep the current log at %LOCALAPPDATA%\MilochApplicationStudio\logs\mas-YYYYMMDD.log.

SCCM: Ship fails with "Connect to site server timed out" #

Symptom. The SCCM job in the Ship drawer transitions to Failed during the Warm-up stage with an error toast citing a timeout against the Site Server.

What it means. MAS' first ConfigMgr call after a cold app launch initialises the SMS Provider connection. On some sites (VPN, double-NAT, or a heavily patched Site Server) the initial handshake takes longer than the 30-second default MAS grants.

Recovery.

  1. Confirm the SCCM Admin Console can reach the site server from the packaging workstation. Launch the Console; if it hangs at Connecting, the problem is upstream of MAS.
  2. Restart MAS. The Site Server FQDN and Site Code are cached from the profile — the retry uses the same values and often succeeds because the underlying provider is warmed up.
  3. If it still fails, extend the warm-up timeout: Settings → Profiles → <profile> → Advanced → Site connection timeout (default 30s → try 60s).

Log evidence. MAS.SccmConnector.SccmSession emits Connecting to site server followed by Site server connection took N ms on success, or Site server connection failed: WMI error on the timeout.

Intune: Ship fails immediately with "Sign in required" #

Symptom. The Intune job never leaves Queued and the toast reads Sign in required — refreshing the token cache.

What it means. MAS uses MSAL to cache the Graph token in the current user's token cache. Windows sometimes clears that cache during profile refresh or after an unattended sign-out; MAS' silent-token acquisition then returns interaction required.

Recovery.

  1. Open Settings → Profiles → <Intune profile> → Sign in again. A browser popup asks for the same credentials as the original sign-in.
  2. Retry the Ship. The queued job re-runs with the fresh token.

Log evidence. MAS.IntuneConnector.GraphAuth emits Silent token acquisition failed: InteractionRequired and the recovery path logs Interactive sign-in completed for tenant <id>.

Capture: Icon extraction falls back to generic shell icon #

Symptom. The Capture-summary card shows the Windows shell default icon instead of the installer's application icon.

What it means. MAS extracts icons from Portable Executable resources. Some installers (particularly older InnoSetup builds and single-file NSIS wrappers) put their branding icon inside the payload EXE that only becomes accessible after installation, not in the installer itself. MAS falls back to the shell icon rather than block Capture.

Recovery.

  1. Set a custom icon manually: Capture → Summary card → Icon [Change...]. Point at any .ico or .png at least 256×256. The Pre-Ship stage picks it up automatically.
  2. For repeat use, add the icon to the vendor's Memory-DB row: Home → Recent projects → <row> → Edit identity → Icon. Every future Capture of that vendor's installers reuses it.

Log evidence. MAS.MsiExtraction.IconExtractor emits No icons found in installer PE resources, falling back to shell default when the extraction path bottoms out.

Build: "Workspace path already exists" on a rebuild #

Symptom. Clicking Rebuild on an existing package fails with Workspace path already exists — remove or rename before rebuild.

What it means. MAS refuses to overwrite an existing workspace because a partial build could leave a mixed state on disk (some files from the old build, some from the new). This is a safety guard, not a bug.

Recovery.

  1. If the old workspace is safe to discard: click the Remove and rebuild affordance in the same dialog. MAS deletes the folder and rebuilds.
  2. If the old workspace has hand-edits in SupportFiles\ that must be preserved: cancel the rebuild, back up SupportFiles\ to a safe location, then use Remove and rebuild. Copy the backed-up SupportFiles\ back after the rebuild — MAS never touches that folder, so subsequent builds preserve it.

Log evidence. MAS.PsadtGeneration.WorkspaceService emits Refusing to overwrite existing workspace at <path>: use ForceOverwrite = true to proceed.

Pre-Ship: "Detection rule required" even after adding one #

Symptom. The Ship button stays disabled with a red banner At least one detection rule is required even after adding a detection rule in the Detection Editor.

What it means. The rule was saved to the workspace but not yet committed to the package record. This happens when the Detection Editor was opened, edited, and closed without an explicit Save click.

Recovery.

  1. Reopen the Detection Editor from the Pre-Ship page. The uncommitted rule is still visible in the list with a Modified marker.
  2. Click Save. The banner clears and the Ship button arms.

Log evidence. MAS.PsadtGeneration.DetectionRuleStore emits Loaded N rules for package <id>, M unsaved on the Pre-Ship refresh.

Memory DB: "Optimistic-lock conflict" on save #

Symptom. Saving an edit to a Recent Project row surfaces Optimistic-lock conflict — another session modified this record.

What it means. A second MAS window opened the same package record, made a change, and saved first. MAS refuses to overwrite without the operator seeing the conflict.

Recovery.

  1. Note the fields you edited.
  2. Click Reload from database — the row refreshes to the other session's state.
  3. Re-apply your edits on top; save again.

Log evidence. MAS.Infrastructure.PackageHistoryStore emits RowVersion mismatch on save: expected <A>, stored <B>.

Updates: "Update check returned 404" #

Symptom. Settings → Updates → Check now returns Update check failed: 404.

What it means. The feed URL points at a channel that has no published release yet. In the MAS 2.0 launch window this happens frequently on the preview and dev channels, and briefly on the stable channel between releases.

Recovery.

  1. Confirm the channel: Settings → Updates → Channel. stable is the only publicly-published channel.
  2. If it's already stable, the release is still being published — retry in a few minutes.
  3. If the problem persists on stable, open a ticket via feedback. The feed is hand-published for MAS 2.0's opening window; the auto-update pipeline covers subsequent releases.

Log evidence. MAS.UpdateService.VelopackClient emits Fetching RELEASES from <url>, HTTP status <code>.