- 01First distinguish the kind of failure
- 02Record the last normal action
- 03Preserve the useful context
- 04Use Give Feedback when the game opens
Based on the linked sources and original analysis. No first-hand playtesting is claimed.
What the developer has actually recommended
A September 5 Steam thread reports game crashes followed by whole-system restarts. The publisher asked the player to use Give Feedback in the game so logs could be sent, and to include a contact address for follow-up. Developer Danga suggested Low graphics, which disables volumetric fog, as a possible way to reduce the problem. The reply mentioned a previous case involving possible heat or power limitations, not a confirmed diagnosis for every player.
Use those statements at their proper scope. Low is a documented setting to try if the game is stable enough to reach its menu. Give Feedback is the supported reporting route named in the discussion. Neither statement proves that all crashes share one cause, that your hardware is faulty, or that a particular repair will solve the issue.
This page provides an original workflow for describing the failure and gathering useful context. It does not claim to have reproduced the crash or examined your logs. The aim is to preserve what happened, make a small number of appropriate checks, and give support a report it can investigate without requiring you to guess the internal cause.
First distinguish the kind of failure
A game closing to the desktop is different from a frozen image, an operating system error, or the computer restarting. Record which event occurred. If an error message appeared, copy its exact wording or capture it when practical. If there was no message, say that rather than inventing one from a similar online report.
Also note whether audio continued, whether the game still responded to input, and whether the operating system remained usable. These are observations, not diagnoses. They help separate a game process ending from a wider system interruption. A broad description such as everything crashed leaves those important distinctions unresolved.
If the whole computer repeatedly restarts or powers off, stop repeatedly provoking the condition as a game test. Preserve the information you already have and seek appropriate system or device support as well as reporting the game context. A restart is not an ordinary frame-rate problem, and this article should not be used as a substitute for hardware assessment.
Record the last normal action
Write what you were doing just before the failure. Include the chamber or room name, whether you were loading, opening a menu, moving, or performing a particular puzzle interaction, and roughly how long the session had been running. An approximate duration is useful when clearly labeled approximate.
Avoid turning the last action into a cause prematurely. A crash after entering a room does not prove the room caused it. Still, that timing gives the developer a place to begin. The strongest report describes the sequence plainly and leaves room for investigation rather than naming an engine defect or a memory leak without evidence.
If the failure has occurred more than once, compare the events. Were they in the same scene, after a similar duration, or during different activities? State the number of occurrences you actually observed. Do not write always if it happened twice under conditions you have not fully compared.
Preserve the useful context
Record the storefront, demo or full-game entry, operating system, graphics device, processor, memory, and any local build information the client exposes. These details help the developer match the report to an environment. If a field is unknown, leave it unknown until you can check rather than guessing from the computer's brand.
Include the graphics preset and any relevant setting values you changed. A report made after experimenting should say which configuration was active at the time of the failure. Otherwise support may interpret your current settings as the settings that produced the original event, even though they differ.
Keep a short timeline if you make several checks. It can say that the first failure occurred on one preset, you then updated the game, and a later attempt behaved differently. The order matters because it shows which changes preceded which observations. A list of all settings you ever tried does not provide the same information.
Use Give Feedback when the game opens
If you can reach the game and its feedback option, use the route the publisher named. Explain the failure type, the last normal action, and the environment. The publisher says the feedback route sends logs that may help. Do not assume that the logs alone explain your intent or the exact moment you noticed the problem.
Include a contact address if you want a follow-up, as requested in the support reply. Keep the report focused on the issue and avoid adding unrelated personal information. A useful contact detail helps the developer ask for a specific additional observation without requiring you to publish that information in a public discussion.
If the issue is a repeatable pause rather than a crash, the separate performance thread asks for feedback while the lag is occurring. For a crash that has already closed the game, explain that timing when you reopen it. Do not claim that a particular previous log was attached unless the feedback interface or developer confirms it.
If the game cannot reach its menu
Use the official contact listed on the game's website, hello@hewhowatches.com, to explain that the in-game reporting route is unavailable. State whether the game fails before a window appears, during loading, or after reaching the title screen. Those stages are more useful than the single phrase will not launch.
Start with a concise report and the information you can verify. Do not attach every file from the installation or send a large archive of unrelated system data. Wait for a request for specific additional material when the needed files or paths are not documented. The researched sources do not establish a current retail log or save path to copy here.
If a storefront shows an error, preserve that message separately from any game error. A missing-download or client problem can occur before the game process runs. Naming the layer where the failure appears helps avoid treating a storefront installation issue as if it were a puzzle-engine crash.
Check for an available game update
Use the storefront's normal update mechanism and let pending downloads or installation work finish before comparing behavior. This is general support practice, not evidence that a particular He Who Watches update fixes your crash. Record whether an update was available and whether the symptom changed afterward.
Do not assume that the newest announcement describes every local build change, and do not invent a version number from the date. If the client exposes an identifier, use it. Otherwise provide the update date and storefront you can actually see. Accurate incomplete information is preferable to a label that support cannot match.
An update that changes puzzles or menu text should not be advertised as a crash hotfix unless the developer says so or a carefully described observation supports the narrower result on your machine. Keep the question of installation freshness separate from the question of whether the issue has been resolved.
Try Low only as a controlled comparison
The developer's Low-graphics suggestion is a reasonable small test if the game remains stable enough to use. Note the previous preset, select Low, and return to ordinary play or a short comparable scene. Record whether the original symptom returns. Do not repeatedly force a system restart merely to compare presets.
If Low helps, describe the result as a local workaround under the observed conditions. You do not need to infer whether fog, load, heat, or another factor explains it. The developer can use the change in behavior without you supplying a speculative hardware diagnosis.
If Low does not help, that is useful information too. Include it in the report with the failure type and timing. A negative test does not mean the developer's suggestion was unreasonable; it means your case needs more evidence. Avoid cycling through many unrelated settings after the first focused comparison has failed.
Verify Steam files when the symptom fits
Valve documents a file-verification check through the Steam library's game Properties and Installed Files area. This can be appropriate for missing or damaged installed files. It is general Steam troubleshooting, not a demonstrated fix for this game's reported restart issue. Use the client interface rather than manually deleting installation content.
Let verification finish and note what the client reports. If files are reacquired, record that fact without assuming it proves they caused the failure. Then compare the original symptom under a normal launch. If nothing changes, include that result in support notes instead of rerunning verification indefinitely.
Do not confuse verifying the installation with validating your puzzle progress. It does not establish a solution to a room or prove that an old walkthrough should match a new layout. Keep the check tied to technical symptoms such as missing files or launch failures, where it has a clear purpose.
Avoid destructive guessing
The available developer replies do not instruct players to delete saves, remove configuration folders, edit the registry, or use undocumented launch commands. Do not make those actions the default response to an uncertain crash. They can erase useful state or create a second problem without explaining the first.
Similarly, do not disable system protections or download a third-party fixer because a search result promises a universal solution. Use the game, storefront, and device support channels relevant to the observed failure. A narrow verified instruction is more useful than a dramatic procedure with no clear connection to the symptom.
If support later requests a specific file or change, keep a record of the instruction and preserve relevant data as appropriate. The point is not to avoid every change. It is to make changes for a stated reason and retain enough context to tell whether they helped.
Capture a small, meaningful example
If the failure can be observed without provoking a dangerous or disruptive system event, a short recording or screenshot can clarify the report. Show the error message or the action that immediately precedes the problem. Explain what the viewer should notice. A long unannotated session can hide the relevant moment.
Keep private desktop content out of the capture and mark late-game material when sharing publicly. You can often show the technical behavior without revealing an entire secret route. If the scene itself is a spoiler, say so before the image or video rather than placing the answer in the title.
Do not claim a reproduction is minimal unless you have actually narrowed it. It is fine to say that you observed the crash after several actions and do not know which matters. That honesty prevents support from assuming that a single visible input is the complete trigger.
Write expected and actual behavior separately
Expected behavior describes what you thought should happen: the room should load, the menu should close, or the game should remain open after an ordinary move. Actual behavior describes the visible failure. Keeping them separate makes the report understandable even if the developer does not share your interpretation of the puzzle state.
When the expectation comes from a guide, include the link and date. A mismatch with an old room layout may be a version issue rather than a crash. When the expectation is basic application behavior, say so plainly. There is no need to decorate a straightforward report with technical terminology you cannot substantiate.
Add what you tried and the outcome of each step. Updated game, still closes at loading is useful. Tried everything is not. A concise list of real checks saves time by showing which obvious comparisons are already complete and which remain untested.
Follow up with new evidence
If the developer asks for a particular test or log, respond to that request directly. Keep the original report reference so the new information stays attached to the same issue. Starting several unrelated threads can split the context and make it harder to see how the behavior changed over time.
If the problem stops after a change, report what changed and how long or under which conditions you have tested since. Avoid declaring a universal fix after one successful launch. A narrower statement that the game has completed several normal sessions on Low is both useful and honest if that is what you observed.
If it returns, update the same account of the issue with the new conditions. A recurrence does not erase the earlier improvement; it adds information about its limits. That distinction can help support identify whether the change reduced frequency, affected only one scene, or was unrelated.
Decide when to stop testing
Once you have a clear failure description, basic environment details, and the results of a few appropriate checks, send the report. You do not need to diagnose the game yourself before asking for support. More tests are worthwhile only when they answer a specific remaining question or follow a relevant instruction.
If the machine itself is unstable, prioritize that broader problem and avoid repeated game launches that trigger it. If the game alone closes but your system is otherwise usable, preserve the report and wait for a targeted next step rather than replacing your installation repeatedly. The response should fit the failure you actually have.
A good report is a small piece of evidence: what happened, where, under which setup, and what changed when you tried a documented step. That is enough to begin a productive investigation while keeping speculation, unrelated tweaks, and unnecessary file changes out of the way.
Turn a vague report into an actionable one
A report saying the game crashes sometimes leaves several essential questions unanswered. You can improve it without technical speculation by adding the failure type, the stage of play, the approximate frequency, and the last normal action. For example, distinguish a return to the desktop during loading from a whole-system restart after a long session. These are report patterns, not events claimed to have occurred on your machine.
Then add the environment and the small set of checks you actually completed. State whether you used the full game or demo, which storefront supplied it, and which graphics preset was active. If you tried Low or Steam verification, report the outcome of each separately. Do not write that all fixes failed when you performed only one check.
Explain whether the behavior is repeatable under a known sequence or merely recurrent over time. A repeatable failure gives support a sequence to attempt. A recurrent failure still matters, but its trigger remains uncertain. Labeling the difference helps the developer decide whether to ask for a reproduction, logs, or more information about the session.
If an error message is available, preserve its exact wording instead of paraphrasing it into a cause. An unfamiliar code can be more useful to support than a confident summary that it means a graphics problem. If you did not capture the message, say that and describe what you remember without manufacturing the missing detail.
End with the current state. Can you launch the game now? Does the issue remain after the documented setting comparison? Is the in-game feedback route accessible? These answers tell support what kind of next step you can actually perform. A request to submit from the menu is not useful if your report already explains that the menu never appears.
Keep the original report and later follow-ups connected. When a new observation arrives, add it with its date and conditions instead of rewriting the past as though you knew the cause from the beginning. That preserves the investigation's useful sequence: symptom, check, result, and the next question. It also makes a later successful change easier to evaluate honestly.
The improved report does not need to be long. It needs to expose the facts that were hidden inside the word sometimes. Clear scope and a few observed details can save more time than a page of guessed engine explanations, and they give the developer a sound basis for requesting the next piece of evidence.