Windows 11 Proactive Memory Diagnostics: Quick Post Crash RAM Scan

Microsoft is quietly rolling out a simple but meaningful reliability tool in Windows 11: after an unexpected restart caused by a bug check (commonly shown as a BSOD), the OS can now prompt you to run a quick RAM check — scheduling the built‑in Windows Memory Diagnostic to run on the next reboot — in an effort to catch memory faults before they become recurring crashes or data corruption.

Background​

Microsoft introduced this capability as Proactive Memory Diagnostics in recent Windows Insider Preview builds. The company’s Windows Insider blog explains the experience: if Windows detects a bugcheck, users signing back into the system may see a notification suggesting a quick memory scan. If accepted, Windows schedules the Windows Memory Diagnostic (mdsched) to run before the next boot completes. Microsoft describes the scan as a short triage pass that takes five minutes or less on average, and says that if the diagnostic finds and mitigates a memory issue, a follow‑up notification will appear after reboot.
This rollout is currently limited to Windows Insiders in the Dev and Beta channels and appears in the cumulative update identified as KB5067109 (Dev build 26220.6982 and Beta build 26120.6982). Microsoft intentionally opens the first flight broadly: all bugcheck codes trigger the prompt while telemetry is collected so the engineering team can later refine which crash signatures correlate strongly with memory corruption.
Multiple independent outlets and community forums have mirrored Microsoft’s announcement and described the same set of limits and behaviors. The public messaging from Microsoft and reporting from technical press outlets agree on the core details: the prompt, the scheduled pre‑boot run of the Windows Memory Diagnostic, the typical runtime claim, and the current exclusions (ARM64 devices, systems with Administrator Protection enabled, and BitLocker configurations that boot without Secure Boot).

---

How the new post‑crash memory scan works​

The user flow​

• You encounter a bugcheck (unexpected restart / BSOD) that forces the PC to reboot.
• After signing in, Windows may show a notification recommending a memory scan.
• If you opt in, Windows schedules the Windows Memory Diagnostic to run during the next restart.
• The PC reboots, the diagnostic runs in the pre‑boot environment, and then Windows continues to boot.
• If the diagnostic finds a memory problem — and if Windows is able to apply a mitigation — you receive a post‑reboot notification summarizing the result.

The underlying tool​

The scheduled diagnostic is the long‑standing Windows Memory Diagnostic tool (mdsched.exe). It runs outside the full Windows session in a minimal environment and executes memory tests designed to detect a range of physical RAM errors and corruption symptoms. Historically, Windows Memory Diagnostic is intended as a hardware troubleshooting aid rather than a repair utility; it reports errors that typically require replacement or deeper software/hardware triage.

Flight behavior and telemetry​

Microsoft’s initial flight triggers on every bugcheck code so developers can gather telemetry linking crash signatures with memory corruption. The stated plan is to refine targeting in future builds so that only the most relevant bugcheck types produce the prompt — reducing unnecessary scans on machines that crashed for reasons unrelated to RAM (drivers, overheating, firmware bugs, etc.).

---

What this change means for everyday users​

Immediate practical benefits​

• One‑click triage: Instead of searching the web for “BSOD memory check,” users get a clear, integrated prompt with a single action that schedules a diagnostic at the next reboot.
• Faster detection: Early identification of RAM faults can avoid repeated crashes, prevent file corruption, and reduce the risk of larger system instability. In many warranty scenarios, early detection makes a memory device replacement claim straightforward.
• No extra downloads required: Users no longer need to hunt for third‑party tools or awkward bootable images to get a basic hardware-level memory check.

What users should realistically expect​

• The scheduled scan is a quick triage pass and not a substitute for a full, prolonged memory test. Microsoft describes the experience as taking about five minutes on average; that estimate reflects a default, targeted pass rather than long, exhaustive test runs.
• A negative result from the quick scan (no errors detected) is useful but not definitive. Intermittent faults, temperature‑dependent failures, or issues that appear under sustained stress may not show up in a short pre‑boot pass.
• If a fault is detected, Windows may mitigate the issue in some way, but that phrasing is imprecise: diagnostics typically report bad regions and may allow the OS to avoid allocating those pages, while permanent physical defects usually require module replacement.

---

Technical limitations and current exclusions​

Microsoft notes several important restrictions with the initial flight:

• The feature is only available to Windows Insiders in Dev and Beta channels (builds KB5067109 / 26220.6982 and 26120.6982).
• It is not available on ARM64 devices in this early rollout.
• It will not trigger when Administrator Protection is enabled on the system. Administrator Protection is a security model that limits persistent elevated privileges and enforces just‑in‑time elevation, which can block automatic system operations that require elevated context.
• Systems using BitLocker that boot without Secure Boot enabled are excluded. Because the diagnostic runs in a pre‑boot environment and the pre‑OS environment interacts with disk encryption and boot policies, Microsoft has limited the experience to configurations that satisfy Secure Boot and BitLocker expectations for this early flight.

These exclusions matter to both consumers and IT administrators. ARM64 devices (many Windows on Arm systems) are currently left out, and enterprise fleets heavy on BitLocker and hardened security configurations may not see the prompt until Microsoft further validates the feature across those scenarios.

---

Strengths: why this is a sensible move​

• Tangible reliability improvement: Memory issues are a common cause of spontaneous crashes, file corruption, and application instability. A lightweight, immediate triage step reduces friction for end users to check RAM when a system shows a kernel‑level failure.
• Data‑driven rollout: Microsoft’s broad initial trigger is purposeful: by collecting telemetry across many crash types and hardware combinations, the team can refine triggers and reduce false positives in later releases.
• Integrated, low‑effort experience: Scheduling diagnostics through the OS removes user guesswork and reduces reliance on third‑party or vendor‑specific tools. That lowers the bar for non‑technical users to act when there’s a real underlying hardware fault.
• Helpful to warranty/workflow: Early detection improves customer support workflows and RMA success rates for memory replacements under warranty because the system-generated diagnostic record is an authoritative artifact.

---

Risks, caveats and areas to watch​

• Short scans are not exhaustive. Users may be reassured by a short, “no issues found” result while intermittent or workload‑dependent errors remain undetected. A single short pass cannot replace extended testing with specialist tools.
• Noise and unnecessary reboots. With the initial setting that treats all bugchecks as triggers, machines that crashed for driver bugs, firmware errors, or thermal events could get prompted to run memory scans unnecessarily. That may irritate users and generate support tickets.
• Ambiguous “mitigated” language. Microsoft promises a notification if a memory issue is “found and mitigated.” That word can mean different things: marking bad pages to avoid allocation, instructing the user to replace modules, or performing OS‑level workarounds. The exact mitigation mechanisms are not fully described in public messaging and should be treated cautiously.
• Enterprise adoption hurdles. In corporate environments with BitLocker, Secure Boot policies, and strict admin controls (Administrator Protection or similar), the feature may be blocked or limited. IT admins need clear guidance on how to incorporate this behavior into their triage SOPs and whether it should be allowed in managed fleets.
• Potential privacy/telemetry concerns. Microsoft is explicitly collecting crash and diagnostic telemetry to refine triggers. While this is standard practice for OS‑level diagnostics, organizations and privacy‑conscious users should be aware telemetry may be used to tune trigger rules and study crash‑to‑memory correlations.
• ARM64 gap. As more devices — especially laptops — ship with ARM64 silicon, their exclusion from this diagnostic experience leaves a growing segment of Windows users without the new convenience.

---

What to do when the prompt appears (practical guidance)​

• If you see the memory diagnostic prompt after signing in, accept the scheduled test if:
• You experienced a genuine BSOD or unexpected restart, and
• You want a fast, system‑managed triage step before deeper testing.
• After the reboot, read the post‑scan notification carefully. If the diagnostic reports errors:
• Note the module and error summary.
• Run an extended diagnostic (see next section) and gather logs/screenshots for support or RMA claims.
• Check system vendor warranty and RAM replacement options.
• If the scan reports no errors but BSODs persist:
• Run a longer memory test (extended pass) with a dedicated tool.
• Update drivers (especially chipset and graphics) and firmware.
• Inspect thermal conditions and power delivery, which can trigger transient errors.
• If in an enterprise environment, coordinate with IT:
• Ensure this behavior is acceptable under corporate security policies.
• If necessary, disable the feature via management policies until validated across the fleet.

---

When a quick scan isn’t enough — recommended follow‑ups​

• Run an extended Windows Memory Diagnostic pass: You can launch the tool manually (search for “Windows Memory Diagnostic” or run mdsched.exe) and choose the extended test mode. Extended passes increase detection coverage but take much longer depending on RAM size.
• Use MemTest86 or comparable bootable tools: MemTest86 runs outside of Windows with thorough patterns and stress tests, often exposing intermittent errors that brief passes miss. It’s the industry standard for deep RAM fault hunting.
• Swap modules or test one stick at a time: If possible, remove and test RAM sticks individually or try known‑good modules in the system to isolate failing DIMMs.
• Check for ECC behavior: On servers or ECC‑capable systems, confirm whether ECC logged corrected errors that may indicate early degradation even when diagnostics show no uncorrectable errors.
• Collect logs and dmp files: BSOD minidumps and system event logs help pinpoint whether crashes are memory‑corruption related or stem from drivers or other subsystems.

---

Enterprise and security considerations​

• BitLocker and Secure Boot interplay: The pre‑boot diagnostic runs before the OS fully loads and interacts with boot and disk‑encryption technologies. Microsoft’s initial restriction that BitLocker configurations without Secure Boot are excluded suggests caution when mixing disk encryption and pre‑OS diagnostics. Enterprises using BitLocker should validate the experience in a lab before broad rollout.
• Administrator Protection interaction: Systems with Administrator Protection limit persistent elevated actions and require explicit user authorization for admin tasks. Because scheduling and running a pre‑boot diagnostic may require elevated behavior or changes to boot flow, Microsoft excluded these systems from the early flight. IT teams must evaluate how the feature fits into zero‑trust or least‑privilege architectures.
• Group Policy / MDM control expectations: Administrators will expect policy knobs (via Group Policy or Intune) to control whether post‑crash memory diagnostics are allowed on managed devices. Microsoft’s messaging indicates this is early flight behavior; formal enterprise management controls may appear as the feature matures.

---

How Microsoft could improve the feature as it matures​

• Narrow triggers to crash signatures with a high correlation to memory corruption, reducing unnecessary prompts.
• Add enterprise policy controls to centrally permit/deny post‑crash scans across managed fleets.
• Provide clearer messaging about what “mitigation” means in practical terms (e.g., OS page avoidance vs. hardware replacement).
• Offer a diagnostic mode selector in the prompt (quick triage vs. extended test) with time estimates so users can make informed choices before scheduling a longer test.
• Expand support to ARM64 and to BitLocker/Secure Boot permutations after adequate validation.

---

Final assessment​

This is a pragmatic, low‑friction feature that addresses a common pain point: unexplained BSODs and the sometimes‑arcane process of checking RAM. By integrating a one‑click scheduling experience for the existing Windows Memory Diagnostic, Microsoft reduces friction for casual users and helps surface hardware faults faster. The feature’s strengths are its simplicity and alignment with real‑world troubleshooting workflows.
At the same time, it’s important to keep expectations measured. The initial quick scan is a triage tool — not a definitive hardware cure. The broad initial trigger set will likely create noise until Microsoft refines the correlation between crash types and memory faults. Enterprises must test the interaction with BitLocker, Secure Boot, and Administrator Protection before entrusting the feature to large fleets.
For PC enthusiasts and admins, the new behavior is a welcome convenience. For everyone, the sensible approach is to treat the post‑crash memory scan as a first step: accept the prompt when prompted, but follow up with extended tests and vendor‑level diagnostics if crashes continue. The net effect should be fewer mysterious restarts and a clearer path from a blue screen to a hardware replacement — which is a practical win for system reliability.

---

Source: TechPowerUp Windows 11 Will Start Memory Scans After BSOD to Prevent Future Issues