Proactive Memory Diagnostics in Windows 11: Quick Post Crash Scan

Microsoft is piloting a new post‑crash diagnostic in Windows 11 that prompts users to run a quick memory scan after a Blue Screen of Death (BSOD), scheduling the built‑in Windows Memory Diagnostic to run on the next reboot and report results back to the desktop.

Background​

Microsoft has begun flighting a feature internally called Proactive Memory Diagnostics as part of recent Windows Insider Preview builds. The experience surfaces a sign‑in notification after the system detects a bugcheck (an unexpected restart or BSOD), asking whether the user wants to “scan memory to find problems.” If the user accepts, Windows schedules the Windows Memory Diagnostic (mdsched.exe) to run during the next system restart; the test is intended to be a short triage pass that completes in roughly five minutes on typical systems and will notify the user after boot if it detected and mitigated memory issues.
This behavior is currently only available in Insider Preview channels and is described as an early flight: it triggers on all bugcheck codes while telemetry is gathered to determine which crash signatures actually correlate with memory corruption. The initial rollout also has platform and configuration exclusions: the prompt does not appear on ARM64 devices, nor on systems with Administrator Protection enabled, and it is blocked when BitLocker is active without Secure Boot.

---

What the feature does — a concise technical overview​

• After Windows detects a bugcheck (a kernel, driver, or other critical failure that forced an unexpected restart), the OS may show a desktop notification at sign‑in recommending a memory scan.
• If the user chooses to schedule the scan, Windows sets the Windows Memory Diagnostic (mdsched) to run during the next boot cycle.
• The scheduled diagnostic runs in a minimal pre‑boot environment and performs a quick/default test pass intended to take about five minutes on average.
• When the diagnostic finishes, Windows completes booting and will surface a follow‑up notification if the tool reported errors or applied mitigations.
• The flight is intentionally broad initially: every bugcheck is a trigger so Microsoft can analyze telemetry and refine which bugcheck codes should prompt a scan in future builds.

Why Microsoft is doing this​

Memory corruption—whether from defective DIMMs, faulty memory controllers, or unstable settings introduced by overclocking or XMP profiles—is a common but sometimes invisible cause of intermittent crashes, freezes, and data corruption. The new prompt is a pragmatic attempt to shorten the time‑to‑diagnosis: rather than requiring users to know about mdsched or to manually invoke third‑party tools, Windows can offer a lightweight triage step right after an abnormal reboot.
The feature aims to serve three practical goals:

• Rapid triage — surface and catch simple memory faults early.
• Reduce support friction — help end users and technicians eliminate RAM problems before more invasive hardware swaps or diagnostics.
• Telemetry-driven targeting — gather real crash-to‑memory correlation data so prompts can be made smarter and less noisy over time.

---

What the Windows Memory Diagnostic actually is — and what it is not​

The Windows Memory Diagnostic is an established built‑in tool that runs outside the full Windows session in a pre‑boot environment. It performs several test mixes (Basic, Standard, Extended) to exercise memory cells and the memory path.
Key technical facts about the diagnostic:

• It runs in a minimal, pre‑boot context (so it can test RAM without interference from loaded drivers).
• The test mixes range from fast/basic checks to much more comprehensive extended tests that can take many times longer than a quick pass.
• Results are normally visible after boot as a desktop notification or can be retrieved from the Event Viewer under the System log with the source MemoryDiagnostics‑Results.
• The built‑in diagnostic is useful for quick detection of clear and reproducible memory faults, but it is not a silver bullet; it may miss intermittent faults or errors that only appear under sustained heavy load or specific access patterns.

Because of those limits, the Windows Memory Diagnostic provides a good first screen but is not a substitute for more exhaustive tools (for example, dedicated bootable memory testers that run multiple extended passes) when diagnosing stubborn or intermittent memory failures.

---

Strengths — why this is a practical step forward​

• Low friction for users: The prompt appears at sign‑in and schedules the scan for the next reboot, keeping the user in control and minimizing surprise downtime.
• Fast initial triage: The expected average runtime (roughly five minutes) makes the check reasonable to run even on a workday reboot, increasing the chance that users will accept the scan.
• Reduces “unknown cause” support calls: Many BSOD reports are rooted in hardware memory problems; an automated prompt can reduce unnecessary driver or OS reinstallation troubleshooting cycles.
• Telemetry enables refinement: Starting broad (all bugcheck codes) but then narrowing based on observed correlations is a pragmatic way to avoid both false negatives and excessive noise.
• Built on existing tooling: The feature reuses the mature Windows Memory Diagnostic rather than shipping a new binary, lowering the risk associated with deploying untested code.

---

Limitations and risks — what to watch out for​

• Not a comprehensive test: The quick scan is a triage pass. It may not detect intermittent errors or faults that only occur under specific stress patterns; persistent BSODs still merit extended testing with specialized tools.
• Potential for noisy triggers: Because the initial flight triggers on all bugcheck codes, many reboots unrelated to RAM faults could prompt scans. That could create user confusion or lead to unnecessary reboots on machines that crashed due to driver bugs, overheating, or other causes.
• Platform exclusions complicate coverage: The feature is intentionally not supported on ARM64, Administrator Protection, or BitLocker without Secure Boot. In enterprise fleets with widespread BitLocker use, the prompt will simply be unavailable; administrators must account for that gap in their triage playbooks.
• False sense of resolution: A short scan that returns no errors might reassure a user but still leave underlying causes unresolved. Care must be taken not to overinterpret a negative check as proof of hardware health.
• Telemetry and privacy questions: While the feature relies on crash telemetry to be refined, users and admins should be conscious of how diagnostic telemetry is collected and used. There is limited public detail about what exact crash context is tied to the proactive flow; this should be considered when deploying at scale.
• Boot interruption risk: Scheduling diagnostics and pre‑boot tests introduces additional boot time. On systems that rely on fast boot and uptime guarantees, this could be problematic if not accounted for in maintenance windows.

---

Platform and enterprise implications​

Limitations that matter to administrators​

• BitLocker without Secure Boot: Pre‑boot diagnostics must interact with the system before Windows unlocks encrypted volumes. To protect keys and integrity, Windows restricts some pre‑boot tools unless Secure Boot is enabled; when BitLocker is used without Secure Boot, the proactive flow is disabled.
• Administrator Protection: Systems with additional admin protections or hardened pre‑boot environments may block scheduling of pre‑boot utilities.
• ARM64: The initial flight excludes ARM64 devices; organizations running ARM‑based Windows systems should not expect this triage to appear.

Recommended enterprise approach​

• Pilot on a controlled group of non‑encrypted, non‑ARM64 machines to observe behavior and telemetry impacts.
• Update support documentation and runbooks to include the new proactive memory prompt as an early triage step.
• Communicate to helpdesk staff that a negative scan does not rule out all memory problems; extended testing may still be needed.
• Coordinate with hardware vendors to understand warranty and RMA implications if the prompt suggests replacing memory modules.
• Evaluate privacy and telemetry settings to align with organizational policy and regulatory obligations.

---

Practical user guidance — what to do when prompted​

• Before running any diagnostic, save your work and back up critical files. A pre‑boot scan will restart the machine.
• If you accept the prompt, allow the scheduled scan to run during the next reboot. Expect a short delay (average five minutes) but understand that actual duration depends on installed RAM and the test configuration.
• After reboot, check for a follow‑up notification. If no notification appears, open Event Viewer → Windows Logs → System and look for the most recent record with the source MemoryDiagnostics‑Results to view the report.
• If the diagnostic reports errors:
• Power down and reseat memory modules (remove, clean contacts, and reinstall).
• Test modules individually by leaving a single DIMM installed and rerunning diagnostics to isolate faulty sticks.
• Reset BIOS/UEFI to default memory settings; if XMP or manual overclocking is in use, revert to JEDEC/default timings and retest.
• If errors persist, replace the failing module(s) and test again.
• If the diagnostic reports no errors but crashes continue:
• Run a longer Extended memory test with multiple passes.
• Use a third‑party bootable memory tester that supports multi‑pass stress (recommended for elusive faults).
• Run driver and software triage: enable Driver Verifier and examine DMP files and Event Viewer for non‑memory root causes.
• Check motherboard BIOS/UEFI updates and run power supply/motherboard health checks.

---

Step‑by‑step: how to run a deeper memory diagnosis manually​

• Open an elevated Command Prompt or Run dialog.
• To schedule the built‑in Windows Memory Diagnostic for an immediate check at the next reboot, run:
• mdsched.exe and choose “Restart now and check for problems” OR
• mdsched.exe /r to restart and run immediately.
• When the Memory Diagnostic starts, press F1 to access options and select the Extended test, set the pass count to multiple passes, and disable cache options as needed for exhaustive checking.
• Allow the test to complete; extended tests can take hours depending on RAM size.
• After Windows restarts, check Event Viewer → Windows Logs → System and filter for MemoryDiagnostics‑Results to see detailed findings.

---

Comparing quick scans and exhaustive testing: when each is appropriate​

• Quick, built‑in scan (proactive flow): Best as a first‑line triage to catch obviously faulty modules or to rule out gross memory failure shortly after a crash.
• Extended built‑in scan / multiple passes: Appropriate when intermittent issues persist and the quick scan is inconclusive.
• Third‑party bootable testers: Use when extended built‑in tests are negative but suspicion remains. These tools typically run continuous multi‑pattern tests and are more likely to surface rare or timing‑sensitive errors.

---

Troubleshooting checklist for builders and overclockers​

• Revert XMP and manual overclocking to default profiles and retest.
• Verify that all voltage and timing settings in BIOS/UEFI are within manufacturer recommendations.
• Update motherboard BIOS/UEFI to the latest stable firmware that addresses memory compatibility.
• Test each DIMM in multiple slots to rule out slot or motherboard DIMM‑socket faults.
• If crashes are workload‑dependent (e.g., heavy rendering or gaming), run stress‑testing tools that exercise memory intensively alongside extended memory tests.
• Consider ECC memory for systems that require high reliability; non‑ECC DIMMs may be more susceptible to silent corruption in some edge cases.

---

Privacy, telemetry, and what remains unclear​

The proactive diagnostic relies on crash detection and telemetry to refine which bugcheck signatures should prompt scans in future releases. While the basic behavior and exclusions are documented in the initial flight notes, some questions remain that administrators and privacy‑conscious users should flag:

• The proactive flow uses telemetry to correlate crash types with memory corruption patterns, but details on the exact telemetry payload (e.g., whether any memory contents or kernel addresses are sent) are not fully public in the early documentation.
• It is not explicitly documented whether the proactive prompt alters or increases diagnostic telemetry beyond the default crash and telemetry policy on a device.
• There is no clear published Group Policy or enterprise control (at the time of the initial flight) to centrally enable/disable the prompt across managed fleets; organizations should pilot first and watch for policy controls in later builds.

These items should be treated as cautionary until explicit enterprise policy controls and telemetry details are published in broader documentation.

---

Recommended rollout plan for IT teams​

• Inventory: Identify machines where the prompt will be disabled by the current configuration (ARM64, BitLocker without Secure Boot, Administrator Protection).
• Pilot group: Turn on the Insider flight for a small, non‑critical pilot set of devices that are not encrypted or highly secured.
• Telemetry monitoring: Use existing monitoring to track how often the prompt fires, how frequently it finds errors, and whether prompts correlate with subsequent hardware replacements.
• Update support scripts: Add steps to the helpdesk script to capture Event Viewer MemoryDiagnostics‑Results, to guide users through reseating DIMMs, and to escalate to extended testing when needed.
• Policy and communication: Prepare communications for end users explaining what the prompt is, why it appears, and what actions to take (back up, accept scan, and what the results might mean).
• Scale gradually: Only expand beyond the pilot after confirming that the prompt identifies meaningful faults, isn’t generating excessive noise, and that privacy/telemetry behavior aligns with policy.

---

Final analysis — is this a net positive?​

The proactive memory scan prompt is a practical, low‑risk step that addresses a real pain point: memory faults are a leading root cause of unexplained system instability, and getting simple, actionable diagnostics into the hands of users sooner is a net positive for both consumers and support teams. By leveraging the existing Windows Memory Diagnostic infrastructure and making the flow consent‑driven and scheduled for the next reboot, Microsoft’s approach is conservative and user‑friendly.
That said, the early flight’s broad triggering across all bugcheck codes, exclusions on secure systems, and the limited scope of a short diagnostic mean this is a triage tool rather than a comprehensive fix. IT teams should pilot and incorporate it into a broader diagnostic playbook that includes extended memory testing and platform‑level checks. Users should treat a single quick scan result—positive or negative—as an initial data point, not a final verdict.
In short: this is a helpful addition to the Windows reliability toolbox that will likely reduce time‑to‑diagnosis for many RAM‑related failures, but it must be used as part of a disciplined troubleshooting workflow that recognizes both its strengths and its limits.

---

Conclusion​

A prompt to run a short memory scan after a BSOD is a sensible, usability‑focused move that helps bridge the gap between cryptic crash dumps and practical hardware triage. For most users, it will be a useful, low‑friction first step. For power users and IT administrators, it should be treated as an early triage tool that complements — but does not replace — deeper diagnostics, controlled testing, and hardware validation. Implemented thoughtfully, this proactive diagnostic can shorten repair cycles and make Windows 11 systems measurably more resilient in the face of elusive memory faults.

---

Source: bangkokpost.com New system Windows 11 to prompt memory scans after Blue Screen errors