That distinction matters. A policy that forces Chrome to open web links, for example, may appear to solve a recurring reset problem—but it can also prevent the user from later selecting another browser and having that choice persist. Before deploying anything, Windows users and IT administrators should separate an isolated default-app problem from an organization’s need to standardize application behavior.
Do monthly Windows updates normally reset defaults?
There is not enough evidence to conclude that routine monthly Windows updates generally reset default browser, PDF, and video-player choices across Windows 11 systems. One Tech Community user report alleged that this happened after updates, but a response in the same discussion said monthly updates should normally retain default apps and pointed to other possibilities: incomplete or damaged app registration, a management policy, or a cleanup or debloat utility.
That does not mean a reset cannot happen on a particular PC. It means the cause should not be assumed. A change after an update may be correlated with the update without being caused by it. An app update, a repair action, a removed application component, an import of management settings, or a third-party system-tuning tool may have occurred around the same time.
Microsoft’s deployment guidance does acknowledge a narrower issue around major Windows versions: default-association XML should be refreshed for each major version. It also warns that removing entries from an association file can lead to “An app default was reset” notifications. Those are real deployment considerations, but they do not demonstrate that every normal cumulative update is resetting consumer preferences.
For a single unmanaged PC, the sensible first step is to identify the specific association that changed. Is it .pdf, .html, mailto, http, or https? Did the preferred app remain installed and functional? Did the PC recently use a registry cleaner, debloat script, app-removal tool, or an employer’s device-management profile? The answer determines whether policy enforcement is appropriate—or whether it would merely mask a registration problem.
Why registry edits are not the supported route
Windows protects the registry area that stores default-app choices. Microsoft’s documented approach for deployment is an XML-based policy, rather than directly editing protected default-association registry data.
This is why old advice that suggests manually changing a UserChoice registry entry is unreliable at best. It treats default associations as ordinary registry preferences when Windows applies validation and protection around them. A supported deployment workflow instead captures associations, stores them in XML, and supplies that file to a policy.
That workflow has three separate pieces that are often wrongly blended together:
- DISM export captures the default associations associated with the running Windows installation and the account that runs the command.
- An XML association file records the associations an administrator intends to deploy.
- Group Policy or MDM tells Windows to apply that file.
Each part has different limitations. Exporting an XML file does not enforce it. Having an XML file does not mean it will apply to every device. And using a policy does not make it a harmless, one-time personal preference.
Exporting a baseline with DISM
Microsoft documents this elevated command for exporting the current installation’s associations:
Dism /Online /Export-DefaultAppAssociations:C:\AppAssoc.xml
The command is valuable for discovering the actual application identifiers registered on a machine. That is especially important because a file association points to a programmatic identifier, not simply a friendly app name. For a conventional Google Chrome installation, ChromeHTML is a plausible identifier; Chromium’s installer documentation describes Chrome as replacing ChromiumHTM with ChromeHTML. But it should not be guessed blindly. The exported XML from the target device is the better evidence of what that device currently exposes.
The export is also not a universal template for every user and every PC. Microsoft notes that the export is tied to the account used to run DISM. If an administrator exports defaults while their own account has Edge, a particular PDF app, or a custom protocol handler selected, those choices can become part of the deployment baseline.
Timing matters as well. Microsoft warns that an export can be incomplete if delayed-installed applications have not finished installing. Exporting immediately after installing software can therefore leave out an association that appears later. A careful process is to let application installation complete, export the file, check the result against the system’s reported associations, and preserve a current baseline before making edits.
For organizations, completeness is more important than a minimal file containing only the handful of entries they care about. Microsoft advises retaining a complete baseline and keeping it current across major Windows versions. A stale or pruned file can produce unwanted reset notifications or unexpected assignment behavior when Windows encounters associations the file no longer covers as intended.
The Group Policy setting and its major caveat
The relevant setting is named Set a default associations configuration file. Microsoft maps it to:
Computer Configuration
> Administrative Templates
> Windows Components
> File ExplorerThe policy is configured by enabling it and entering the path to the XML association file. At a high level, that is straightforward: place the XML where target devices can reach it, configure the policy, and allow Windows to apply the specified associations at sign-in.
But the policy’s documented scope deserves more attention than many how-to guides give it. Microsoft’s Group Policy deployment instructions say that this policy works only for domain-joined clients. That makes it a natural fit for traditional Active Directory environments, not a guaranteed fix for a personally owned standalone PC simply because Local Group Policy Editor is available.
A separate Microsoft policy reference lists the setting as applicable to Windows Pro, Enterprise, Education, and IoT Enterprise/LTSC editions, rather than Windows Home. These two facts should be read together, not treated as a promise that every Pro computer can use the setting locally without domain management. The edition list describes policy availability; the deployment guidance places an important domain-join limit on the documented Group Policy procedure.
As a result, an unmanaged Windows 11 Pro PC may not be an appropriate place to rely on this as a durable workaround. Windows Home is not listed as an applicable edition for the setting, and the available documentation does not establish that a Local Group Policy configuration on a standalone Pro device will work in every case. A user should not build their recovery plan around an unsupported or uncertain deployment scenario.
There is a further management hierarchy to consider: for this setting, MDM policy takes precedence over Group Policy. On a work or school device enrolled in management, an organization’s MDM configuration can therefore override a local or domain policy. If the defaults keep changing on such a PC, the right path is usually to ask the IT administrator what association policy is assigned rather than repeatedly changing defaults by hand.
“Suggested” determines whether policy becomes enforcement
The most consequential detail is the XML behavior on Windows 11 version 22H2 and later. When the default-association configuration policy is set, Windows applies configured defaults at sign-in.
For an association without Suggested="true", the documented behavior is to apply it at every sign-in. In practice, that means the XML acts as an enforcement tool. If an administrator specifies a browser handler in that way, a user who later chooses another browser can find the organization’s configured default reinstated after signing in again.
The alternative is to mark an association as suggested and use an XML version. With Suggested="true", Windows applies that suggested association once for each XML Version. If the administrator later increments the version, the suggestion can be applied again. This gives administrators a way to provide a recommended initial default without continuously reimposing it at every sign-in.
That makes the policy useful for distinct goals:
- Mandatory organizational standard: Leave an entry as a normal, non-suggested association when the organization intends to enforce the application choice at sign-in.
- Initial recommendation with more user autonomy: Use the suggested behavior and manage the XML version deliberately.
- Personal recovery after one unexplained reset: First repair or reselect the default normally. A sign-in-enforced policy is usually disproportionate unless the machine is genuinely managed for that purpose.
Calling the non-suggested policy mode a way to make a preference “stick forever” gets the relationship backwards. It makes the policy’s preference stick, not necessarily the user’s.
Practical checks before deploying association XML
Whether the PC is personal or business-managed, a few checks reduce the chance of replacing one annoyance with another.
First, confirm that the intended application is fully installed and registered. An export performed before delayed installation completes may not contain the correct identifiers. If an app is missing from the exported association list, reinstalling or repairing it may be more useful than editing an XML file based on a guessed ProgID.
Second, inspect the XML exported on the same device and under the relevant account. The necessary identifier for a browser, PDF reader, or protocol handler may differ from what an online example uses. ChromeHTML is supported by Chromium’s documented registration model for Google Chrome, but the exported file remains the practical check for a particular installation.
Third, avoid casually deleting unrelated XML entries. Microsoft specifically warns that changing the baseline by deleting entries can trigger default-reset notifications. Keep a backup of the original export and document each intentional change.
Fourth, plan to refresh the file for major Windows releases. This is maintenance work, not a one-and-done configuration artifact. Apps and Windows components can add, remove, or alter registered handlers over time.
Finally, test with a noncritical account or device before broad deployment. The important test is not merely whether the intended app opens a file immediately after policy deployment. Sign out and sign back in, then test whether the observed behavior matches the intended enforcement or suggested-default model.
Where SetUserFTA fits—and where it does not
SetUserFTA is a separate, third-party approach that is sometimes suggested for restoring per-user file associations. Its vendor describes it as operating in the current user context without changing machine-wide defaults, and says it can be deployed through a logon script or Group Policy.
That scope can be attractive where each user needs their own default assignment rather than a device-wide standard. It also illustrates why it should not be casually described as the same solution as Microsoft’s XML deployment policy: one is third-party per-user automation, while the other is a Windows administrator deployment feature.
There are significant limitations. The vendor describes Personal Edition 1.8.3 as free for personal, non-commercial use, but also unsupported and without ongoing development. Its maintained 2.x product is licensed for business environments. Organizations should therefore account for licensing and support rather than treating it as a broadly free enterprise tool.
The vendor also says its utility does not target UserChoiceLatest on consumer Windows 11 Home and Pro editions. That is a material compatibility boundary for exactly the consumer devices on which many people seek a quick default-app fix. The available material also does not substantiate detailed claims about how the tool bypasses Windows protections, so users should avoid relying on implementation claims that have not been verified.
A proportionate path forward
For a personal Windows PC, start with the normal Default apps interface and confirm the chosen application remains installed and properly registered. If defaults change again, investigate nearby app changes, system-cleaning utilities, and device-management enrollment before concluding Windows Update is responsible.
For a domain-managed fleet, Microsoft’s XML policy is the supported administrative mechanism—but deploy it with a complete, current baseline and a clear decision about whether defaults are mandatory or merely suggested. Use non-suggested entries only when repeated sign-in enforcement is actually desired.
For managed devices where different users require different defaults, per-user tooling may be worth evaluating, but its licensing, support status, and consumer Windows 11 limitations need to be understood first.
The central lesson is simple: default-association XML is powerful precisely because it is policy. Treating it as a personal “set it and forget it” switch risks converting an intermittent reset complaint into a system that deliberately overrides the user at every sign-in.