Windows 11 Apps Won’t Open: Repair, Reset, and Reinstall

An application that never appears, briefly opens and closes, or repeatedly crashes is not enough evidence to blame Windows itself. Start by checking whether the failure is limited to one program. Open a few unrelated applications that normally work, including a built-in Windows app and, if relevant, another conventional desktop program.

If only one application fails, keep the first troubleshooting steps local to that application. If many unrelated apps fail at the same time, especially after a Windows update or another system change, a broader Windows, driver, security-software, or system-file problem becomes more plausible. Preserve any exact error message, error code, crash dialog, or application log before resetting or reinstalling anything; destructive repair can remove useful evidence.

Before changing app data, restart Windows rather than only closing and reopening the program. A restart clears the current process state and completes some pending servicing work. For Microsoft Store apps, Microsoft specifically recommends reopening the app, checking Windows Update, checking app compatibility, and getting Store library updates before moving to repair or reinstall steps.

For a conventional desktop application, use the publisher’s supported updater or installer rather than assuming Microsoft Store instructions apply. If the failure began immediately after an application update, driver change, security-software change, or Windows update, record that timing. Correlation is useful diagnostic evidence, but it does not by itself prove which component is responsible.

In Windows 11, open Settings > Apps > Installed apps, select the affected app’s menu, and look for Advanced options. Microsoft says some apps expose Repair there; if Repair is unavailable or does not solve the problem, Reset may also be offered. Not every app exposes these controls.

Repair is the less destructive first choice when it is available. Treat Reset as a stronger step because it can return an app to its default state and may remove local app data or settings. Check the application’s own sync, backup, account, save-file, or export behavior before resetting anything important. For conventional desktop software, Control Panel > Programs > Programs and Features may instead expose Repair or Change, depending on the installer.

If repair or the application’s supported update path does not help, reinstalling can replace damaged or incomplete application files. Microsoft documents uninstalling through Settings or Control Panel, while Microsoft Store applications can be reinstalled from the Store library. Some built-in Windows applications cannot be removed through the normal uninstall path.

Before uninstalling, preserve local projects, saves, profiles, plug-ins, license information, configuration files, and crash logs when the application does not already synchronize them. Reinstallation is a useful application-level repair step, but it is not proof that Windows itself is damaged, and repeatedly reinstalling an app is unlikely to isolate a background conflict.

If the app still fails, or several applications behave abnormally, a clean boot can test whether another startup application or non-Microsoft service is interfering. Microsoft describes clean boot as starting Windows with only essential drivers and startup programs so background software conflicts affecting apps or games can be isolated.

This is a diagnostic test, not a permanent performance configuration. Microsoft’s procedure requires hiding Microsoft services before disabling the remaining services, disabling enabled startup items, restarting, testing the application, and then restoring normal startup when troubleshooting is finished. If the application works only in the clean-boot environment, re-enable groups of items systematically to isolate the conflicting service or startup app instead of leaving everything disabled indefinitely.

DISM and System File Checker are Windows component and protected-system-file repair tools; they are not generic first-line fixes for every application crash. They become more relevant when multiple Windows features or unrelated applications are malfunctioning, or other evidence points to damaged Windows components.

Microsoft currently recommends running DISM.exe /Online /Cleanup-image /Restorehealth before sfc /scannow when repairing missing or corrupted system files. Let each command finish and read its result rather than assuming that a completed scan found corruption. If one third-party application alone is broken while the rest of Windows behaves normally, its publisher-specific diagnostics remain the more targeted path.

If a single app still fails after its supported update, repair or reinstall path and it also fails in a clean boot, collect the exact version, error text, crash logs and steps that reproduce the problem and take those to the application publisher. Microsoft’s clean-boot guidance similarly directs users toward the program manufacturer when the app still will not run in the isolated environment.

If many unrelated applications and Windows features are failing, shift the diagnosis toward shared system components, drivers, recent Windows changes, storage or memory stability, and Windows recovery options. A full Windows reset or reinstall is an escalation step, not the opening response to one broken app. The goal is to preserve evidence and expand the repair scope only when the observed failure scope justifies it.