Windows 11 Proactive Memory Diagnostics: Post‑Crash RAM Scan at Sign‑in

Microsoft is testing a new, consent-driven feature in Windows 11 that surfaces a sign‑in notification after a crash and offers to schedule a quick, pre‑boot memory diagnostic on the next restart to help detect RAM faults early.

Background​

Memory corruption is one of those failure modes that can masquerade as software bugs, driver faults, or intermittent application crashes. For years Windows has included the built‑in Windows Memory Diagnostic (mdsched.exe) as an offline tool administrators and power users use to triage faulty DIMMs, timing issues, and controller problems. Microsoft’s new feature, called Proactive Memory Diagnostics, integrates that existing tool into the post‑crash user flow so a quick triage pass can be scheduled with a single click after a bugcheck (unexpected restart).
The capability is currently rolling out only to Windows Insiders in early preview builds (appearing in the cumulative update identified as KB5067109 — Dev build 26220.6982 and Beta build 26120.6982). Microsoft frames the experience as an optional, consented check that helps users and support teams reduce the time between a crash and initial hardware triage.

---

What Proactive Memory Diagnostics does — the user flow​

• After Windows detects a bugcheck (a kernel stop error typically visible as a BSOD/GSOD/black screen) and restarts, a dismissible notification may appear at the next sign‑in suggesting a “quick memory scan.”
• If the user accepts, Windows schedules the Windows Memory Diagnostic to run in the pre‑boot environment during the next restart.
• The diagnostic executes a short, default test pass (Microsoft estimates five minutes or less on average for the triage pass), then the system resumes booting to the desktop.
• If the diagnostic detects problems or applies what Microsoft calls “mitigations,” Windows surfaces a follow‑up notification after boot and writes results to the System log for review in Event Viewer.

This model is intentionally lightweight: the goal is to create a low‑friction, consent‑driven first check that rules in or out obvious RAM issues without forcing extended downtime. Multiple outlets and community threads reporting from the Insider release echo the same flow and emphasis on opt‑in behavior.

---

Technical details and what runs under the hood​

The diagnostic engine​

The scheduled test uses the long‑standing Windows Memory Diagnostic (mdsched.exe), which runs outside the full Windows session in a minimal pre‑boot environment. The tool supports three primary test mixes:

• Basic — fast, limited coverage
• Standard — default mix used for general testing
• Extended — deep, exhaustive tests that take significantly longer

Microsoft’s proactive flow schedules a quick/default pass intended to complete rapidly; the company’s public notes estimate the triage pass will take about five minutes or less on average, though actual runtime varies with installed RAM and the specific test mix invoked.

Results and forensics​

Results from the pre‑boot diagnostic are written into Windows logging so technicians can consume them later:

• Look in Event Viewer under the System log for MemoryDiagnostics or MemoryDiagnostics‑Results entries.
• The diagnostic produces the same type of artifacts whether invoked manually or by the proactive flow, which helps when an RMA or warranty claim requires an objective evidence trail.

Platform gating and exclusions​

In the first preview flight Microsoft intentionally set broad telemetry collection and restricted the experience on certain configurations. The current gating includes:

• Not supported on ARM64 devices.
• Blocked when Administrator Protection is enabled.
• Blocked when BitLocker is active but Secure Boot is not present.

Microsoft says the early flight triggers on all bugcheck codes so the team can analyze which codes correlate with memory corruption; that telemetry will let engineering narrow triggers later. These exclusions and the “all codes” approach are explicitly documented in the Insider notes.

---

Why Microsoft is doing this — practical rationale​

Memory faults are frequently invisible to end users and can cause recurring instability or silent data corruption. The current process for checking RAM is often manual and obscure to non‑technical users: you must know about mdsched, schedule it to run at reboot, or boot third‑party tools such as MemTest86 from USB.
By surfacing a prompt immediately after a crash, Microsoft hopes to:

• Reduce time‑to‑diagnosis for failing DIMMs or controller faults.
• Standardize the first triage step across millions of devices by using a built‑in tool.
• Capture diagnostic artifacts close to the failure event to facilitate RMAs or helpdesk escalations.

This pragmatic approach is framed as an accessibility and support‑efficiency win, especially for home users and small support teams that lack dedicated diagnostic rigs.

---

Strengths — what this gets right​

• Low friction: The prompt is dismissible and scheduling occurs for the next reboot, minimizing immediate disruption.
• Built‑in, trusted tool: Using mdsched avoids recommending third‑party utilities and standardizes results for support workflows.
• Faster time to evidence: A quick triage can catch obvious hardware defects before they cause repeated crashes or file corruption.
• Consent model: The flow is opt‑in, preserving user control and avoiding unexpected pre‑boot actions.

---

Limitations, risks, and unanswered questions​

Proactive Memory Diagnostics is useful — but it is not a silver bullet. Several practical limitations and risks merit careful attention.

1) Quick scans are not exhaustive​

A five‑minute triage pass is designed to catch clear, reproducible hardware issues but will likely miss:

• Intermittent faults that appear under sustained load or specific access patterns.
• Timing and signal integrity problems caused by motherboard traces, slot seating, or power delivery that require long‑running stress passes and multiple cycles to reproduce.

Users should treat a “no issues found” result as informative but not definitive; persistent crashes require extended testing and vendor diagnostics.

2) Noise from broad triggering (false prompts)​

Because the initial preview triggers on all bugcheck codes, Microsoft expects a period of noisy prompts where the diagnostic suggestion appears after crashes unrelated to RAM (for example, driver bugs, overheating, or firmware errors). That could lead to:

• User confusion and unnecessary reboots.
• Increased support tickets while triggers are refined.

Administrators piloting the feature should expect a spike in prompts and plan communication accordingly.

3) “Mitigation” is ambiguous​

Microsoft’s notes state that the diagnostic may “mitigate” issues. The practical meaning of that term is currently unclear:

• In practice, Windows can avoid allocating pages known to be faulty or mark regions as bad, but the diagnostic cannot physically repair hardware.
• A reported “mitigated” status should be interpreted as evidence the OS observed a problem and worked around it, not as a permanent hardware fix.

Microsoft will need to clarify precisely what “mitigated” actions the OS performs and whether any automatic remediation is applied. Until then, treat mitigation notices as diagnostic flags for follow‑up.

4) Enterprise and security considerations​

The feature is gated on Administrator Protection and BitLocker/Secure Boot configurations, reflecting legitimate pre‑boot security interactions. For managed fleets:

• Enterprises will want Group Policy / Intune controls to opt devices in or out, or to manage how results are reported back to helpdesk systems.
• The current preview does not appear to include fully documented management controls; IT teams should pilot carefully and await Microsoft’s enterprise guidance.

5) Telemetry and privacy questions​

Collecting crash telemetry to determine which bugcheck codes correlate with memory faults is the stated plan, but organizations and privacy‑conscious users may want transparency about:

• Exactly what crash metadata is collected and how it’s associated with diagnostic prompts.
• Whether diagnostic logs are uploaded automatically to Microsoft or only stored locally (current public notes emphasize local Event Viewer logs, but telemetry collection of crash signatures is part of the refinement step).

Until Microsoft publishes detailed telemetry documentation for the feature, treat telemetry‑driven refinements as something to watch.

---

Practical guidance — what to do when the prompt appears​

If you see the Proactive Memory Diagnostics notification after signing in, consider the following guidance:

• If the crash is known to be caused by a recent driver change, thermal event, or software update, you may dismiss the prompt and address the primary cause first.
• If the crash was unexplained, accept the scan — it’s quick and non‑destructive.
• After the diagnostic finishes, inspect results in Event Viewer:
• Open Event Viewer → Windows Logs → System and search for MemoryDiagnostics or MemoryDiagnostics‑Results entries.
• If the quick scan reports errors or mitigations, follow up with deeper testing:
• Reboot and run the Extended profile in Windows Memory Diagnostic, or
• Boot a dedicated tool like MemTest86 and run multiple full passes, or
• Test modules one at a time in known‑good slots/boards to isolate a bad DIMM or slot.
• Update BIOS/UEFI, chipset drivers, and firmware; unstable firmware and aggressive XMP/overclock settings can create symptoms that mimic defective RAM.

This triage ladder—quick scan, extended test, vendor diagnostics, hardware swap—remains the appropriate path for robust isolation and resolution.

---

For IT and support desks — deployment and policy thinking​

• Pilot the feature in a controlled group before broad roll‑out; expect extra prompts during the telemetry collection phase.
• Request Microsoft‑provided management controls (Group Policy, CSP/Intune options) to:
• Enable/disable the prompt.
• Control whether diagnostics run automatically or require explicit acceptance.
• Route diagnostic outcomes back into centralized ticketing or telemetry pipelines.
• Advise helpdesk staff to interpret proactive diagnostic results as first‑pass evidence and to escalate to extended testing when intermittent or workload‑specific faults persist.

Until Microsoft ships explicit management knobs, organizations should document local policies for end users (for example, whether users should accept the prompt or contact support first).

---

How this compares to third‑party approaches​

Third‑party memory testers such as MemTest86 remain the gold standard for exhaustive validation: they can be configured for long multi‑pass runs and deliver per‑module isolation. The value of Microsoft’s proactive approach is discoverability and convenience: it reduces the friction for first‑line triage and ensures diagnostic artifacts are captured close to failure events without requiring users to download, boot, or create external media. However, for warranty/forensic certainty, vendor tools and extended stress passes will still be necessary.

---

What to watch next​

Key items to watch as the preview evolves:

• Whether Microsoft narrows triggers from “all bugcheck codes” to a curated subset that better correlates with memory corruption.
• Expanded platform support (ARM64) and clearer behavior for BitLocker/Secure Boot / Administrator Protection scenarios.
• Publication of formal enterprise controls (Group Policy / Intune) and telemetry/telemetry‑privacy documentation.
• Clarification of “mitigation” semantics and whether Windows will automatically avoid allocating bad pages or simply report findings for manual remediation.

Microsoft’s early notes and community reporting make the feature’s intent and mechanics clear, but several implementation details that matter to administrators and power users remain to be published.

---

Final assessment​

Proactive Memory Diagnostics is a pragmatic, low‑risk addition to Windows 11’s troubleshooting toolbox: a short, consented, and integrated memory check surfaced immediately after a kernel crash that can accelerate the discovery of obvious RAM faults and produce standardized diagnostic artifacts for support. The approach capitalizes on an existing, trusted diagnostic engine and reduces friction for non‑technical users.
That said, its real‑world value depends on Microsoft’s refinement of triggers, improved documentation around mitigation and telemetry, and enterprise management controls. In its present early flight, expect noisy prompts and platform exclusions; treat scan outcomes as triage evidence, not final verdicts. When used as intended—with follow‑up extended testing and vendor diagnostics where appropriate—this feature should measurably shorten the path from unexplained crash to confirmed hardware resolution for many users.

---

Source: VideoCardz.com Windows 11 adds Proactive Memory Diagnostics to detect RAM issues after crashes - VideoCardz.com