A user on a brand-new Surface Pro 11 opens Teams for a 9am call. Nothing happens. No error, no dialog, just a taskbar icon that flashes and disappears. The new Outlook does the same thing a minute later. Word, Excel, and classic Outlook all open fine on the same machine. If this happened to you any time from mid-August 2026 onward, on an ARM-based Windows 11 PC, you have run into a real, currently-open Microsoft issue - and there is a documented workaround, even though Microsoft has not shipped a permanent fix yet.
After installing Windows security updates released on or after August 11, 2026 (KB5121003 on Windows 11 24H2/25H2, KB5121000 on 26H1), Microsoft Teams and the new Outlook for Windows can fail to launch or close unexpectedly on ARM64 devices such as Surface Pro 11 and Surface Laptop 7 - most often on new or freshly imaged PCs that have not yet run their first Microsoft Store update. Microsoft's status for this is Mitigated, not Resolved: a workaround exists, but no permanent code fix has shipped. The workaround is to update the Auto Super Resolution Package to version 1.0.19.0 or later from the Microsoft Store. This post covers what is actually confirmed by Microsoft, what is informed inference on our part (clearly labelled), how to check whether a fleet is exposed, and how to push the fix at scale.
The problem: Teams and new Outlook refuse to launch on ARM64 Windows 11
Microsoft's Windows 11 release-health page carries this entry, word for word:
"After installing Windows security updates released on or after August 11, 2026, (KB5121003), Microsoft Teams and the new Outlook for Windows might fail to launch or might close unexpectedly on ARM-based devices, such as Surface Pro 11 and Surface Laptop 7. Classic Outlook, Word, Excel, and other applications are not known to be affected. This issue is most likely to occur on new or freshly imaged PCs that have not yet installed any Microsoft Store updates."
Read that carefully, because three details in it matter more than they look:
First, this is an ARM-only issue. An x64 Surface Laptop or a Dell Latitude never hits this, no matter how out of date it is. Second, only two specific apps are named: Teams and the new Outlook for Windows. Classic Outlook, Word, and Excel are explicitly called out as unaffected on the same device at the same patch level - so whatever is wrong, it is not a general ARM64 instability problem, it is specific to how these two particular apps start up. Third, and most useful operationally: this is worst on new or freshly imaged PCs. An ARM64 device that has been in daily use for months, quietly picking up Microsoft Store updates in the background, is far less likely to be affected than a device that just came out of Autopilot provisioning or OOBE.
The issue was opened 2026-09-01 at 18:46 PT and last updated 2026-09-01 at 19:20 PT. The documented affected platforms are Windows 11, version 26H1; Windows 11, version 25H2; and Windows 11, version 24H2 - client only, no server platforms are listed. The originating update is described on Microsoft's page as OS Build 26100.9168 (KB5121003), dated 2026-08-11. As you will see in the verification section below, the build number that actually appears in the registry differs by Windows 11 version even though Microsoft's page prints one figure - which is exactly why "How to verify" below does not take that single number at face value.
Why it happens: an outdated Auto Super Resolution component, and what we actually know
Before we go further, an acronym needs unpacking, because it is the whole reason this bug is ARM-only.
Auto Super Resolution (Auto SR) is a Windows 11 feature that upscales games: it renders a game at a lower resolution and then uses an AI model to reconstruct a sharper, higher-resolution image in real time, so you get both a smoother frame rate and a cleaner picture. Microsoft's own support article states it plainly: "All processing to enhance game visuals occurs on-device using the integrated GPU and Neural Processing Unit (NPU). Graphics and game details never leave your device." That NPU requirement is the whole story. Microsoft's Copilot+ PC developer guide says Copilot+ PCs are powered by "a high-performance Neural Processing Unit (NPU) ... that can perform more than 40 trillion operations per second (TOPS)", and that "many of the new Windows AI features require an NPU with the ability to run at 40+ TOPS." Auto SR specifically ships on Copilot+ PCs built around a Qualcomm Snapdragon X or X2 Series processor with a Hexagon NPU - which is, today, an ARM64 chip family. There is no x64 equivalent shipping this component. That is the entire reason an x64 PC is structurally immune to this specific bug: it does not have the piece of software the bug lives in.
With that boundary drawn, here is the most plausible, best-grounded explanation we can offer, and why we think it fits the symptoms:
Both Teams and the new Outlook for Windows are modern, MSIX-packaged Windows apps that lean on shared platform components (WebView2-based rendering surfaces, DirectX/graphics pipeline hooks, and OS-level app-launch instrumentation) rather than being classic, self-contained Win32 binaries the way Word and Excel still largely are. Auto SR is not just a game feature sitting off to one side - Microsoft's own DirectX developer blog on Auto SR describes it coordinating "data transfers among the NPU, Central Processing Unit (CPU), and Graphics Processing Unit (GPU)" as part of the graphics stack. A brand-new Snapdragon X device ships with whatever Auto SR package version was baked into its factory image, and that image was built before today's date - so an out-of-the-box device is, by definition, carrying an old Auto SR build until it does its first Microsoft Store sync. Our inference is that an outdated Auto SR component sitting in that shared graphics/NPU pipeline is being probed or initialised as part of the modern app-launch path that Teams and new Outlook use, and that a version mismatch there is enough to abort the launch - while classic Win32 apps that never touch that pipeline sail through untouched. That is a plausible mechanism consistent with every symptom Microsoft has published. It is not confirmed.
How to verify: is a device even at risk
Before you touch anything, confirm three things in order: is the device even ARM64, is it on an affected Windows 11 version and build, and can you tell what Auto SR version it is running. Each has a documented, or honestly-labelled undocumented, way to check.
1. Is the device ARM64?
The simplest, most reliable signal is the PROCESSOR_ARCHITECTURE environment variable. On an ARM64 device it reads ARM64; on an x64 device it reads AMD64.
Win32_ComputerSystem.SystemType is a real, documented WMI property (see References), but the current Microsoft Learn page enumerating its possible values does not explicitly list "ARM64-based PC" among them, even though that is the literal string real ARM64 devices report. This is a value that exists on live devices but is not fully reflected in the published enumeration - treat it as an observed-and-undocumented cross-check, and lean on PROCESSOR_ARCHITECTURE as the primary signal.
2. Is the device on an affected version and build?
Read the version and build from the registry, using the same key this project's other posts already standardise on:
| Value | What it tells you | What to look for |
|---|---|---|
| DisplayVersion | Which Windows 11 feature update the device is on | 24H2, 25H2, or 26H1 - the three documented affected platforms |
| CurrentBuildNumber | Base OS build number | Differs by version - see the table below, this is not one number for all three |
| UBR | Cumulative update revision within that build | Must be at or above the originating update's UBR for that version |
Here is the part that trips people up: Microsoft's release-health page prints a single "Originating update: OS Build 26100.9168 (KB5121003)" line at the top of this issue, but that number is specific to the 24H2 branch. The per-version pages for 25H2 and 26H1 show different figures once you look at each version's own status page:
| Windows 11 version | Originating build | KB |
|---|---|---|
| 24H2 | 26100.9168 | KB5121003 |
| 25H2 | 26100.9168 (as printed on Microsoft's own 25H2 status page) | KB5121003 |
| 26H1 | 28000.2704 | KB5121000 |
CurrentBuildNumber 26200, not 26100 - 25H2 devices in the field carry a different base build number than the 26100.9168 figure Microsoft's known-issues page prints for the 25H2 entry. Don't hardcode "26100.9168" as the universal threshold. Compare each device's build number against its own version's baseline, and treat anything with a build number higher than the documented originating build as already past it.
3. What Auto SR version is actually installed?
This is the one honest gap in this section. Microsoft has not published the exact package name or package family name for the Auto Super Resolution Package anywhere we could verify - not on the release-health page, not on the Microsoft Store listing, not in the Auto SR support article. All three only ever refer to it by its display name, "Auto Super Resolution Package." Rather than guess a package family name that might not exist and assert it as fact, the companion script in this post does a read-only, case-insensitive wildcard search across installed AppX packages for names containing "SuperResolution" or "AutoSR", and reports honestly when nothing matches - it does not claim the package is absent, only that it could not be identified by name.
Channel: Windows Logs > Application
Microsoft has not published an Event ID specific to this Teams/new Outlook launch failure. If you want a fallback signal while you wait on Store update propagation, the generic Windows crash/hang sources below are the standard pattern to check for - but they are general Windows Error Reporting behaviour, not confirmed markers of this specific bug, so do not build alerting logic on them alone.
| Source | What it generally means | Relevance here |
|---|---|---|
| Application Error | A process terminated unexpectedly (a crash/fault) | Could appear if the app closes rather than simply never opening |
| Application Hang | A process stopped responding | Less likely fit for "fails to launch," but worth ruling out |
| (none observed) | Silent failure to open at all | The most commonly reported symptom - a flash and nothing, with no Application-log entry at all - so absence of an event is not evidence against this issue |
The fix: updating Auto Super Resolution, and what that means for fleets
Microsoft's own workaround is three steps. Here is the full walkthrough, on a single affected device:
- Open the Microsoft Store app.
- Select Library in the left-hand navigation, then choose Get updates (this is the same action Microsoft's page describes as Downloads > Check for updates - the Store's own menu wording has moved slightly between builds, but the destination is the same update-check screen).
- Let the Store finish checking. It will list every app and system package with a pending update, including the Auto Super Resolution Package.
- Select Update next to Auto Super Resolution Package (or Update all), and let it install. It is a small package and typically finishes in well under a minute on a normal connection.
- Relaunch Teams and the new Outlook to confirm they now open.
You can confirm the update actually landed with the same wildcard search the companion script uses, once you know a specific package matched on your device:
Fleet-scale: what you can and cannot control centrally
This is Store-package-based, not Win32-app-based, so the usual Intune app deployment path does not apply here - you cannot push the Auto Super Resolution Package as a Win32 app assignment, because it is not a LOB app you own; it is an OS-shipped system component managed through the Store's own update mechanism. What you can control centrally is whether Microsoft Store auto-updates are allowed to run at all, which is the difference between "self-heals within a day of the fix reaching the Store" and "sits broken until someone manually opens the Store on every device."
The control is ApplicationManagement/AllowAppStoreAutoUpdate, and it has both a GPO face and an Intune/CSP face - the same underlying setting, verified directly against Microsoft's Policy CSP reference.
| Surface | Setting | What it controls |
|---|---|---|
| Group Policy | "Turn off Automatic Download and Install of updates" | Enabled = blocks Store auto-update (registry value AutoDownload = 2). Not configured/Disabled = Store apps, including Auto SR, update themselves |
| Intune / CSP | AllowAppStoreAutoUpdate | 0 = Not allowed, 1 = Allowed, 2 (default) = Not configured |
Group Policy path - to confirm or change the setting locally or via a domain GPO:
- Open the Group Policy Editor (
gpedit.mscfor local policy, or the Group Policy Management Console for a domain GPO). - Navigate to Computer Configuration > Administrative Templates > Windows Components > Store.
- Open Turn off Automatic Download and Install of updates.
- Confirm it is set to Not Configured or Disabled - either leaves Store auto-update running. If it is Enabled, Store apps will not self-update, and this fix will not reach the device on its own.
Intune Settings Catalog path - the CSP-backed equivalent, verified against Microsoft's Policy CSP documentation for ApplicationManagement/AllowAppStoreAutoUpdate (OMA-URI ./Device/Vendor/MSFT/Policy/Config/ApplicationManagement/AllowAppStoreAutoUpdate):
- Sign in to the Microsoft Intune admin center.
- Go to Devices > Configuration, then Create > New policy.
- Platform: Windows 10 and later. Profile type: Settings catalog.
- Select Add settings, search for App Store Auto Update, and add it from the Application Management category.
- Set it to Allowed (value 1). Leaving it at the default (2, Not configured) also permits auto-update, but setting it explicitly to Allowed removes ambiguity and stops a future change from silently disabling it.
- Assign the profile to the relevant device group and review the deployment status.
One more honest note on management surfaces: Company Portal's "Get updates" button only manages apps Intune itself assigned to the device - it has no visibility into OS-shipped Store system packages like Auto Super Resolution Package, so it will not help here, and telling users to check Company Portal for this issue would send them looking in the wrong app. The Microsoft Store app itself, not Company Portal, is the only interface that can update this package.
Proof it worked: the fleet triage script
The companion script, Get-ArmTeamsOutlookRiskReport.ps1, runs the three checks from "How to verify" together and prints a single AT-RISK / NOT-AT-RISK verdict with its reasoning. It is entirely read-only: it never installs, updates, or changes anything, and it requires no PowerShell module beyond what ships in Windows.
Run it with -ExportCsv to write a single-row CSV per device for fleet collection, and feed that into whatever inventory pipeline you already use to track Autopilot-provisioned Copilot+ PCs.
References
- Microsoft Learn — Windows 11, version 24H2 known issues and notifications
- Microsoft Learn — Windows 11, version 25H2 known issues and notifications
- Microsoft Learn — Windows 11, version 26H1 known issues and notifications
- Microsoft Support — Automatic Super Resolution
- Microsoft Learn — Copilot+ PCs developer guide
- Microsoft Learn — ApplicationManagement Policy CSP
- Microsoft Learn — Win32_ComputerSystem class
- Microsoft DirectX Developer Blog — Automatic Super Resolution: The First OS-Integrated AI-Based Super Resolution for Gaming
Download it from Imran76Awan/Windows-11-Scripts — no sign-in required. It is read-only: it reports and never changes a device or anything in Intune. Validate it in your own environment before relying on the output.