Project Zomboid Build 42.21 launch-failure isolation checklist

If reinstalling and removing mods did not restore launching, stop repeating broad changes and identify the first observable stage that fails.

Classify the failure before changing anything else

Define a repeatable symptom and keep launch diagnosis separate from world or mod troubleshooting.

• Record the action used to start the game and the last visible response.
• Note whether a process, window, error, or main menu appears.
• Classify the case as pre-menu launch failure, post-menu loading failure, or unresolved when the boundary cannot yet be observed.
• Keep saves and gameplay behavior outside the launch test unless the main menu is reached.

Capture the build and patch boundary

Tie every result to the installation being tested without presenting the update as the cause.

• Record the displayed branch and exact build before comparing attempts.
• At source-capture time, the official pages identified Build 42.21 as both the Stable and Unstable build.
• The supplied official material does not document this launch failure or attribute it to Build 42.21.
• Recheck the boundary after any later game or branch change.

Turn previous troubleshooting into evidence

Avoid repeating reinstall and mod-removal attempts without learning from them.

• List each completed action in order and record the observed result.
• Mark missing details as unknown instead of reconstructing them from memory.
• Do not treat a reinstall or mod-free attempt as a complete diagnosis.
• Establish a new recorded baseline before making another change.

Run controlled comparisons

Make each new attempt interpretable and reversible.

• Keep the launch action, branch, build, and observation window fixed for the baseline.
• Change one documented variable at a time.
• Record whether the result changed, remained the same, or became unclear.
• Reverse the test change before starting a different comparison.
• Stop when a change is not reversible, the evidence becomes inconsistent, or the next test requires unsupported assumptions.

Build an escalation packet

Give support or a bounded diagnostic review enough context to choose a defensible next test.

• Include the branch, build, launch action, last visible response, and attempt timestamps.
• Preserve exact error text and identify any available user-supplied logs without interpreting unsupported details.
• List reinstall, mod-removal, and controlled-comparison results in chronological order.
• State what remains unknown and request one next test rather than a promised resolution.

Keep this guide distinct from nearby checklists

Resolve overlap with the existing mod-conflict and post-update verification pages.

• Use the mod-conflict checklist when the game launches and a mod combination is the variable under investigation.
• Use the Build 42.21 post-update verification guide after the game opens and world behavior can be tested.
• Use this checklist when launching itself fails or the main menu is never reached.
• Move between guides only when an observed result crosses the relevant boundary.

Decision checklist

• Record the displayed branch and exact build.
• Write down the launch action used for the baseline.
• Describe the last visible response before the attempt stops.
• Classify whether the main menu is reached.
• List reinstalling and mod removal as prior steps with their observed results.
• Repeat one unchanged baseline attempt and timestamp it.
• Change only one reversible, documented variable per comparison.
• Preserve exact error text and any available logs for escalation.

Worked example

A player reports that the game stopped launching after an update and that reinstalling and removing mods did not change the result. They record the displayed branch and build, start the game using the same action, and observe that the main menu is never reached. They timestamp a second unchanged attempt and receive the same visible result. The case is therefore documented as a reproducible pre-menu launch failure, not a save-verification problem. Instead of returning to the mod stack or repeating the reinstall, the player packages the observed sequence, prior actions, exact error text if present, and available logs for the next bounded diagnostic step.

Common mistakes

• Assuming the recent update caused the failure because the timing overlaps.
• Treating a reinstall as proof that every relevant variable was reset.
• Returning to mod-conflict testing before confirming that the main menu can be reached.
• Changing several variables between attempts and losing the comparison baseline.
• Paraphrasing an error instead of preserving its exact text.

Related guides