If one application repeatedly disappears, closes, or returns you to the desktop while the rest of Windows keeps working, start by treating it as an application crash.
Windows can record repeated application crashes in the Application event log. Microsoft identifies Event ID 1000 as the actual application-crash event and notes that repeated Event 1000 and Event 1001 entries can indicate recurring crashing behaviour. [R1]
The important question is not simply “what file name appears in the error?” It is whether the same crash pattern repeats and what changed around the time it began.
Check whether the problem really belongs to one app
Open the application again and repeat the action that caused it to close, if doing so is safe.
Notice whether:
- only this application crashes;
- it crashes during the same action each time;
- several unrelated applications also crash;
- Windows itself freezes or restarts.
If many unrelated applications or Windows itself are unstable, this article no longer describes the whole problem. The cause may be broader than one application's installation.
Look at the crash evidence
For recurring crashes, Windows may record information such as:
- the faulting application;
- the faulting module;
- an exception code;
- the time of the crash. [R1]
These details help narrow the investigation.
But a faulting module is not automatically the component that caused the bug. Microsoft notes in its crash-debugging guidance that Windows DLLs may appear as faulting modules even when they are not the root cause. [R2]
For example, seeing a graphics-related DLL in a crash can make the graphics path worth investigating, but it does not prove that the graphics driver alone caused the application to fail.
Ask what changed
Check whether the crashes began after:
- the application updated;
- Windows updated;
- a relevant device driver changed;
- a plug-in, extension, overlay, or add-on was installed;
- the application's configuration changed.
Microsoft recommends making sure both Windows and the affected application are current before deeper crash analysis. [R1]
Timing is useful evidence, but it is not proof. A crash beginning after an update makes that change relevant; it does not automatically establish that the update is defective.
Repair the app before reinstalling it
Windows provides a Repair option for some applications.
Go to Settings → Apps → Installed apps, open the application's options, and choose Repair if it is available. Microsoft specifically describes Repair as a way to fix some applications that are not running correctly without reinstalling them. [R3]
Not every application supports this option.
If Repair is unavailable or does not solve the problem, Windows may offer Reset, or the application may need to be uninstalled and installed again. [R3][R4]
Before a reset or reinstall, make sure important application-specific files, settings, projects, or locally stored data are backed up if the application does not synchronize them elsewhere.
If it came from Microsoft Store
For Microsoft Store applications, Microsoft recommends a progression that includes closing and reopening the app, updating Windows, checking for app updates, repairing or resetting the app, and reinstalling it if necessary. [R4]
That sequence is preferable to changing unrelated system settings.
What if it still crashes?
If the application still fails after supported repair, update, or reinstall steps, repeated crash evidence becomes more valuable.
Microsoft's advanced crash guidance uses crash dumps for deeper investigation. A crash dump is a snapshot of the process at the time it failed and can contain information needed to identify where the failure occurred. Windows Error Reporting can collect user-mode crash dumps when configured to do so. [R5]
That is normally an escalation step rather than the first thing a user should configure manually.
How do I know it is fixed?
Do not stop when the application launches successfully once.
Repeat the same action that previously caused the crash. If the application stays open and the affected workflow completes normally, that is much stronger evidence that the repair worked.
The goal is not to remove an Event Viewer message.
The goal is to restore the application task that was failing and confirm that the crash does not immediately return.