Windows 11 Insider Proactive Memory Diagnostics After Crashes

Microsoft is rolling a quiet but meaningful change into the Windows 11 Insider builds: after an unexpected restart or BSOD, Windows may now proactively offer to run a memory diagnostic at the next reboot to help determine whether RAM corruption played a role in the crash.

Background​

Memory failures and memory-related corruption are a perennial source of instability on Windows PCs. The line between a hardware fault in a DIMM, an overclocking/XMP/EXPO-induced instability, firmware/BIOS issues, or driver-caused memory corruption is thin, and diagnosing the root cause typically requires time-consuming tests and tools. To help narrow that problem space, Microsoft has introduced Proactive Memory Diagnostics in the Windows 11 Insider Preview (Dev Channel) build 26220.6982. The feature surfaces a notification after a bugcheck (unexpected restart) suggesting a quick memory scan, schedules the familiar Windows Memory Diagnostic tool to run on the next reboot, and — if problems are found and remediated — notifies the user after the system starts.
This is an extension of an older, built-in utility (mdsched.exe) that most users rarely run manually. The new workflow aims to lower the barrier to running the check and collect telemetry during the early flight to better map crash codes to memory corruption. Microsoft is deliberately broad in this initial rollout: the scan can be suggested for any bugcheck code while engineers study which crash signatures reliably indicate memory corruption. Some platform limitations apply: the experience is not available on Arm64 systems and is currently disabled in certain configurations such as systems with Administrator Protection or BitLocker enabled without Secure Boot.

---

What Proactive Memory Diagnostics actually does​

How the flow works​

• After your PC experiences an unexpected restart (a bugcheck/BSOD), Windows may display a notification on sign-in recommending a memory scan.
• If you accept, Windows schedules the Windows Memory Diagnostic (mdsched.exe) to run during the next reboot.
• The scan runs before Windows fully loads and typically completes in around five minutes or less on average, after which Windows continues booting.
• If the diagnostic detects and mitigates a memory-related issue, you’ll receive a follow-up notification after Windows starts.

The underlying tool: Windows Memory Diagnostic (mdsched.exe)​

The proactive feature does not bring a new testing engine — it leverages the existing Windows Memory Diagnostic. That tool runs pre-boot, exercises RAM with a set of read/write patterns, and produces a pass/fail result recorded to the Event Viewer under the System log with the source name commonly labeled MemoryDiagnostics-Results. Advanced test modes exist but are less visible to most users; you can access them during the diagnostic’s pre-boot stage to run extended or specialized tests.

---

Why Microsoft is doing this​

• Faster triage after crashes: Memory corruption can be the root cause or a secondary symptom of many different kinds of crashes. Promptly telling users “we’ll check RAM next reboot” helps eliminate (or confirm) faulty memory early in a troubleshooting workflow.
• Better telemetry to map crash codes: By triggering the diagnostic across a wide set of bugcheck codes during this early flight, Microsoft can collect data that helps determine which BSOD codes are most strongly correlated with underlying memory corruption. Over time this will allow more targeted prompting rather than asking to run a test for every crash.
• Lower friction for non-technical users: Many home users don’t know about mdsched.exe or how to run MemTest86 from USB. A simple toast that schedules a diagnostic removes that friction.

---

The practical limits: what it can and cannot do​

Strengths​

• Convenience and discoverability: For users who otherwise wouldn’t run a memory test, the feature offers an immediate, built‑in option without extra tools.
• Fast first-pass triage: The default scan is designed to be quick (average ~5 minutes) and helps rapidly rule in or out obvious memory errors.
• Better crash data for Microsoft: The broad initial rollout helps Microsoft refine future heuristics so the system asks only when memory corruption is likely.
• Integrated user experience: Because it uses the built-in tool and standard reboot flow, it avoids third-party boot media or complicated procedures for most users.

Important limitations and risks​

• Not a silver bullet: The Windows Memory Diagnostic is a useful first step but is not as thorough as dedicated tools like MemTest86 (which supports multiple algorithms and long multi-pass testing). A quick Windows scan can miss intermittent or very subtle errors.
• False negatives and false positives: The tool can fail to detect transient faults or report issues that are actually caused by driver corruption, CPU cache issues, or platform firmware quirks. Conversely, it can flag errors that are symptomatic rather than causal.
• Interrupting users: If a user accepts the scan, the next reboot will include a diagnostic step that delays the startup by minutes. That can be disruptive for users who need immediate access to their environment.
• Security and compatibility boundaries: The proactive experience is disabled on Arm64 devices and on systems with Administrator Protection or BitLocker without Secure Boot. That means a segment of devices — including some enterprise-secured machines — will not receive the prompt.
• Unclear automatic “mitigation”: Microsoft’s messaging claims the system can “find and mitigate” memory issues. The exact mechanics of mitigation are not spelled out; there is no public evidence that Windows can physically repair faulty DRAM. Mitigation may mean isolating bad pages, preventing allocation to failing addresses, or prompting the user to replace hardware. This detail is not fully verifiable at this time and should be treated with caution.

---

Compatibility, BitLocker, and pre-boot constraints​

The diagnostic runs before Windows fully loads. That pre-boot execution has security implications because BitLocker-protected volumes may be locked until a user unlocks them. Microsoft’s current rollout explicitly disables the proactive diagnostic on systems running BitLocker without Secure Boot. The practical reason is that pre-boot operations must not break disk encryption workflows or create opportunities for attackers to tamper with the boot flow. Secure Boot provides a chain-of-trust that can make certain pre-OS diagnostics safer to run.
Administrator Protection and other enterprise hardening can also block the prompt to prevent noisy diagnostics on managed systems or those with stringent reboot policies. The Arm64 exclusion is likely due to platform differences in pre-boot environments, tooling, and the need for additional validation on those architectures.

---

How to run the Windows Memory Diagnostic manually (and what to expect)​

For power users or admins who prefer to run diagnostics on their own schedule:

• Press Windows + R, type mdsched.exe, and hit Enter.
• Choose one of the two options:
  1.) Restart now and check for problems (recommended) — the system will reboot immediately and run the test pre‑OS.
  2.) Check for problems the next time I start my computer — the test will be scheduled for the next boot.
• After the test completes and Windows boots, open Event Viewer:
• Launch eventvwr.msc, navigate to Windows Logs → System, and look for an entry from MemoryDiagnostics-Results to see the outcome of the test.

Tips:

• If you have multiple memory modules, test them one at a time to isolate a faulty stick.
• Use the Extended test if you suspect subtle or intermittent errors, but expect the test to take much longer.
• If Windows Memory Diagnostic returns no errors but crashes persist, follow up with a long, multi-pass test such as MemTest86 from bootable USB and examine kernel crash dumps with debugging tools.

---

Interpreting results and follow-up actions​

• No errors reported: This does not guarantee the system’s memory is perfect. Intermittent faults, marginal timing errors, or platform-specific issues (like XMP/EXPO timings, memory voltage/PHY instability, or subtle CPU-NB problems) can evade quick tests. If crashes continue, try:
• Reseating modules and testing one DIMM at a time.
• Disabling XMP/EXPO and running memory at JEDEC default speeds.
• Updating motherboard BIOS/UEFI and chipset drivers.
• Running a longer MemTest86 session (many hours, multiple passes).
• Analyzing minidumps (MEMORY.DMP and minidump files) with WinDbg or tools like BlueScreenView to correlate crash stacks with physical drivers or modules.
• Errors reported: Replace the failing RAM module(s) or, if under warranty, collect vendor diagnostics and initiate an RMA. Before calling an RMA, verify that the module is properly seated and try the module in another slot to identify whether the problem is the RAM or the motherboard slot.
• Mitigated message from Windows: If Windows reports that it found and mitigated an issue, treat the result as a pointer: back up critical data, plan for hardware replacement, and run additional tests. The nature of mitigation is not transparent; assume that mitigation reduces immediate risk but does not necessarily restore full reliability.

---

Where proactive diagnostics fit into a BSOD troubleshooting workflow​

• Preserve logs and crash dumps: collect MEMORY.DMP and minidump files, and note the bugcheck code reported on the BSOD.
• Accept the proactive memory scan (or run mdsched.exe manually) to exclude clear RAM errors.
• If the memory scan is clean, examine crash dumps to identify driver stacks, check for recent driver or firmware updates, and test with default memory timings and voltages.
• If the scan reports errors, isolate the faulty module, reseat or replace it, and re-run diagnostics to confirm the fix.
• Use extended third-party memory tests and firmware updates as needed if instability persists.

---

Why this is useful for both users and Microsoft — and where caution is needed​

From a user-experience perspective, the proactive prompt lowers a key barrier: many home users and even some IT professionals do not routinely run hardware diagnostics. The result should be fewer machines wasting time chasing unrelated causes when a faulty DIMM is truly the culprit.
From Microsoft’s engineering perspective, the broad initial data collection will help the company learn the telemetry patterns that indicate memory-induced crashes versus those that are driver- or firmware-driven. This will let future builds ask only for the tests that matter, reducing noise for users.
However, several caveats must be kept in mind:

• The built-in tool is a first-line diagnostic, not a definitive proof of memory health.
• Automatic prompts after any crash could create alert fatigue; if users receive the suggestion often for crashes unrelated to RAM, the experience risks becoming ignored.
• The precise meaning of “mitigated” is ambiguous in Microsoft’s messaging. Users should treat mitigation as a helpful step but not a guarantee that the system is fully repaired.
• The feature’s unavailability on Arm64 and certain secured configurations limits reach and means the experience will behave differently across user populations.

---

Security, privacy, and telemetry implications​

The early flight is explicitly designed to collect data to help Microsoft refine when to suggest memory tests. That data collection raises two main concerns:

• Telemetry scope: The company intends to correlate bugcheck codes with memory diagnostic outcomes. Users and administrators should consider what telemetry their devices are already configured to send and whether additional diagnostic metadata will be gathered during this flight.
• Enterprise policy control: Organizations that use group policies, Administrator Protection, or BitLocker may already be restricting the experience to avoid unplanned pre-boot operations. IT teams should verify their existing policies and, if necessary, update configuration baselines if they want to enable or suppress the proactive prompts for managed fleets.

For home users, the telemetry burden is likely similar to other Insider experiences: the point is to gather diagnostic linkage, not user data. Still, anyone concerned about data collection during Insider flights should consult their telemetry settings and Insider Program preferences before enabling Dev Channel builds.

---

Recommendations for users and administrators​

• Home users with intermittent crashes: Accept the memory scan if offered; it’s quick and may save hours of troubleshooting. If it reports errors, plan to test modules individually and replace defective RAM.
• Power users and enthusiasts: Use the proactive prompt as a convenience, but rely on extended, multi-pass tests (MemTest86) and crash dump analysis for stubborn or subtle issues.
• Enterprise administrators: Keep the feature off managed devices unless you have a plan to coordinate reboots and verify telemetry. Ensure BitLocker and Secure Boot policies are configured consistently with your security posture.
• People who overclock or use XMP/EXPO: If you experience instability, run diagnostics with XMP/EXPO disabled. Many memory-related crashes are profile-induced and will disappear at stock timings.

---

What to watch for next​

• Expect Microsoft to refine the heuristics: the current flight intentionally triggers on all bugcheck codes to collect a robust dataset. Future releases should narrow triggers to codes strongly linked to memory corruption.
• Look for clearer documentation on what “mitigation” means in practice. Users need to know whether Windows is only isolating addresses, disabling pages, or taking more substantive actions.
• Watch for broader platform support. Arm64 and enterprise scenarios are excluded in the initial rollout; Microsoft may expand support after validating pre-boot workflows on those platforms.
• Monitor community feedback for false positives/negatives and for whether the prompt becomes a nuisance. User telemetry and Insider feedback will drive whether the feature stays as-is, is refined, or is disabled.

---

Conclusion​

Proactive Memory Diagnostics is a pragmatic, user-friendly step toward faster and clearer diagnosis of memory-related stability problems in Windows 11. It leans on an existing built-in tool and integrates it into crash recovery workflows, which should help many users rule out or confirm RAM issues without third-party boot media or lengthy setup. At the same time, the feature is an early flight with limitations: it’s not a replacement for deep, multi-pass memory tests, it’s not yet available on all platforms, and the claimed “mitigation” behavior is not fully documented. Users should welcome the convenience while retaining healthy skepticism: confirm results with extended testing, investigate crash dumps, and follow standard troubleshooting practices for overclocking, BIOS/firmware updates, and driver validation. For IT teams, the change underscores the importance of coherent BitLocker and Secure Boot policies, and for everyday users, it’s a small but useful nudge toward cleaning up one of the most common — and most stubborn — causes of unexpected Windows restarts.

---

Source: Wccftech Windows 11 Will Start Triggering Proactive Memory Diagnostics At Reboot To Find Memory-Related Bugs