PC Games Crashing to Desktop: What to Check at Startup, During Loading and After Long Sessions

First check whether only the game closed

This guide covers a game closing and returning to the Windows desktop. A frozen image, the entire PC switching off or restarting, and a blue screen with a stop code need different checks. The related guides below are labeled Japanese where no English edition exists.

Record the game and version, crash time, time since launch, full on-screen error, save slot and in-game location. Compare the same action if safe, but copy saves first if corruption is suspected.

Launch, loading or a long session: where to start

Timing alone does not establish a cause. File damage can affect launch, mods can affect loading, and driver failures can occur after long play. Choose your next check based on the records and the results of each test.

Step 1: Record the failure and time

1. Record when the desktop appeared, whether it was at launch, loading or how many minutes into play, and whether the same action reproduces it. Investigate power loss, automatic restarting and blue screens with their separate guides.
2. Use the Windows crash-history instructions below to look for the target game at that time. If no entry is found, record “no matching record.” Do not infer a cause from the module name alone.

Step 2: Try one check that fits when the crash occurs

1. At launch: disable mods in their manager and compare. Separately turn Steam Overlay off under the game’s Properties → General. Do not overwrite a save that depends on mods.
2. During loading: copy saves first, then compare another save or new game. In Steam, use Properties → Installed Files → Verify integrity of game files. This can restore files modified by mods.
3. After a long session: compare Task Manager’s Memory and Dedicated GPU memory in the same scene. Close unnecessary apps normally if available memory is running low; lower textures one step if VRAM is tight. If temperature also rises, check cooling and airflow.

Step 3: Compare under the same conditions, then choose the next check

1. Use the same save, scene and similar duration before and after the change. Record the crash time, elapsed play time and the one item changed. If it does not help, restore that setting before trying the next candidate.
2. If one game still fails and it began after an update, compare the GPU driver version and change date. If several games fail, inspect whole-PC history and the manufacturer’s diagnostics rather than repeatedly reinstalling games.

If there is no error message, check Windows crash history

For example, if Game.exe stopped at the matching time and only the game closed, prioritize its updates, mods and save data. A module such as KERNELBASE.dll does not establish the cause or instruct you to replace that DLL. If multiple games or Windows itself fail, also investigate the PC.

1. Press Windows + R, enter perfmon /rel and press Enter. In Reliability Monitor, select the red failure marker on the day the game closed. If the game has a stopped-working entry, open its technical details and record the time, application name and problem-event name.
2. If absent, right-click Start → Event Viewer → Windows Logs → Application. Check errors near the crash time and confirm the game executable matches. Application Error event 1000 and nearby Windows Error Reporting event 1001 may provide clues.
3. Record the faulting application, faulting module, exception code and time from General. An error from another app or a warning recorded hours apart does not establish what caused the game to crash. If nothing matches, record “no matching record” and continue timing-based comparisons.

One reported recovery: check Steam extensions separately from game mods

On October 3, 2026 (Japan time), one user reported being able to play the Steam version of Monster Hunter Wilds after temporarily disabling third-party Steam-client extensions. It had closed before the title screen. Closing OBS, switching Steam Overlay off, verifying files, confirming administrator-mode overrides were off, and updating the GPU driver followed by restarting had not resolved it. A read-only check then found extra DLLs loaded into the Steam process from its installation root.

A file being present and a file actually loaded into a process are different facts. The case did not verify loading into the game process and did not prove one particular DLL was the cause. Do not delete by filename; stop if you do not recognize the installation. Windows DLLs with the same names in System32 are outside the scope of this check.

Before a change, copy and verify settings and saves. With an extension that redirects saves, also check external cloud storage and custom destinations. Do not proceed if important data cannot be preserved. Check only the target game, and stop without overwriting if a sync conflict or missing-save warning appears. Keep the working state; do not re-enable additions just to provoke a recurrence.

The linked Wilds case documents the DLL names, read-only check, reversible pause and reported result. Do not apply the same cause or a supposed success rate to other games.

Read the Wilds pre-title crash recovery case

Compare results and decide what to do next

Example: “Before: the game closes within five minutes every time I load the same save. Change: mods disabled only. After: the same scene runs for 20 minutes without closing.” This is a sample record, not a measured result. If it does not recur, do not declare a permanent fix; compare again during normal play. When asking for help, include the game and version, crash time, application name and exception code from the Windows record, and the checks you have tried.

Preserve saves and avoid speculative DLL fixes

Do not overwrite a mod-dependent save without first preserving it. Do not replace a DLL just because it is named as a faulting module or download files from unknown sources. Preserve saves and settings, then change one item at a time.