Windows Stop Codes While Gaming: Memory Tests, Logs and Minidumps

Choose your symptom

• A stop code or What failed filename is visible — Record it and the time before changing settings.
• VIDEO_TDR_FAILURE, memory or WHEA code — Choose the matching investigation, not an assumed broken part.
• The memory test completed without a notification — Read its dated System-log result.
• No minidump is present — Record that fact and review configured dump handling.

STEP 1: Record the code, time and preceding changes

1. Photograph the Stop code and any What failed filename if available. If it disappears too quickly, inspect Event Viewer → Windows Logs → System after recovery for BugCheck or WHEA-Logger entries near that time.
2. Record game/version, scene, date/time and recent Windows, GPU-driver or peripheral changes. Preserve important files if failures repeat, and do not deliberately crash the PC again to obtain a clearer photo.

Result and next action: Unknown code is a valid observation. A filename on the screen does not by itself prove that file or device caused the failure.

STEP 2: Choose checks relevant to the code and timing

1. VIDEO_TDR_FAILURE: record GPU/driver version and whether a driver change preceded it. MEMORY_MANAGEMENT or IRQL_NOT_LESS_OR_EQUAL: consider memory diagnostics and recent drivers/devices. WHEA_UNCORRECTABLE_ERROR: use manufacturer hardware guidance, cooling checks and documented standard settings. None of these labels alone identifies a part to replace.
2. On a stable Windows 11 system, review Settings → Windows Update. If a driver update immediately preceded the issue, record the old/new versions and follow the driver guide’s supported rollback route. Change one item and compare only while safe; stop if system failures recur.

Result and next action: Do not reset firmware or remove several drivers at once. If Windows itself remains unstable or hardware diagnostics report errors, use manufacturer support.

STEP 3: Read the memory-test result and preserve dump evidence

1. Save work and close apps before opening Windows Memory Diagnostic. Choose Restart now and check for problems only when ready. After the diagnostic and return to Windows, inspect Event Viewer → Windows Logs → System for the dated MemoryDiagnostics-Results entry.
2. Read the result text. No detected errors means this test found none, not that every memory-related cause is excluded. If it reports hardware problems, preserve the result and contact the PC manufacturer. If the entry cannot be found, report the result as unavailable.
3. If small dumps were created, open %SystemRoot%\Minidump in File Explorer and note the .dmp filenames/timestamps near the incident. Follow the support provider’s submission instructions; do not upload memory dumps to a public forum without reviewing the destination and privacy implications.

Result and next action: Keep observations, result text and dump availability together. Missing files or notifications are not clean bills of health.

Match the event to the incident

1. Record code, time and recent changes first. In the System log, inspect the failure interval and next boot. A BugCheck entry may identify a code and dump path; keep nearby WHEA records too.
2. Kernel-Power 41 can accompany an unclean restart and is not a standalone power-supply diagnosis. For its interpretation, use the linked shutdown guide. Repeated incidents justify preservation and support rather than repeated reproduction.

A code points to an investigation, not a verdict

1. VIDEO_TDR_FAILURE (0x116): inspect the GPU in Device Manager → Display adapters → its Properties → Driver, recording version/date and the displayed filename. The code concerns failed graphics timeout recovery; drivers, settings and hardware conditions can be involved.
2. MEMORY_MANAGEMENT (0x1A): record recent memory settings/devices and a diagnostic result. The code describes a serious memory-management error, not automatic proof that a RAM module needs replacement.
3. IRQL_NOT_LESS_OR_EQUAL (0xA): review recent driver/device changes and memory diagnostics. Compare one documented, reversible change; disconnect a newly added nonessential peripheral only using its safe removal/shutdown instructions.
4. WHEA_UNCORRECTABLE_ERROR (0x124): preserve WHEA details and use manufacturer diagnostics. Cooling and nonstandard tuning can matter. If you changed overclock/undervolt settings, follow the manufacturer’s route back to standard rather than guessing firmware values.
5. Another code, or none captured: keep the dated events and dump availability for support. Do not select a fix simply because a search result mentions a similar filename.

Find the result even if the notification disappears

1. Save files and close the game/apps. Search Start for Windows Memory Diagnostic; Windows+R → mdsched.exe is another entry point. Schedule the restart when ready and allow the diagnostic to complete.
2. After signing in, open Event Viewer → Windows Logs → System. Use Find for MemoryDiagnostics-Results and select the entry matching your test time. Read General rather than assuming any older entry belongs to this run.
3. Record the exact result and test date. An error needs manufacturer assessment; no detected error has the limited meaning described in Step 3. A missing entry is an unavailable result. Do not repeat disruptive tests endlessly to manufacture a reassuring result.

Preserve a minidump and choose a private submission route

1. Small crash dumps normally use %SystemRoot%\Minidump. Note relevant .dmp names/dates and keep a separate investigation copy if permitted, leaving the originals intact. If the event specifies another location, inspect that location instead.
2. If no file exists, review View advanced system settings → Advanced → Startup and Recovery → Settings → Write debugging information. None disables dump saving. Consult manufacturer/support guidance before changing the format; available space and the failure itself also affect whether a dump is written.
3. A dump contains crash-time memory information, and even a small dump can expose details you would not want public. Ask the official support provider where and how to submit it. This guide does not require installing a debugger or publishing the file.

Build a useful support record

1. Include PC model, Windows version, GPU/driver, game/version, scene/time/frequency, code and filename, relevant event text, memory-test date/result, and dump presence/name.
2. List changes made before the first failure and comparisons already tried. State whether it happens only in one game or also in other games/normal work. Redact personal paths and identifiers from any public screenshot.

Protect saves and keep changes reversible

• Stop repeated crash reproduction and preserve important data.
• A code, filename or negative memory test is not a complete hardware diagnosis.
• Keep crash dumps off public sites unless you deliberately reviewed what and where you are sharing.