Windows 11 Insiders Get Quick Memory Diagnostic After Crash

Windows 11 Insiders are now being offered a small but potentially meaningful change to crash recovery: when the operating system detects a bugcheck (an unexpected restart, commonly visible to users as a blue/green/black screen), Windows may prompt you at sign‑in to schedule a quick Windows Memory Diagnostic scan to run during the next boot — a proactive triage step Microsoft says takes “five minutes or less on average” and can find and mitigate memory problems that contributed to the crash.

Background / Overview​

The blue screen of death, bugcheck, or stop error has been a canonical Windows pain point for decades: a dramatic, attention‑grabbing notification that something critical went wrong in the kernel, a driver, or hardware. For many users those screens are bewildering — they show terse error codes such as PAGE_FAULT_IN_NONPAGED_AREA or DRIVER_IRQL_NOT_LESS_OR_EQUAL, but they rarely provide a clear path to resolution unless you’re comfortable reading minidumps, parsing Event Viewer logs, or isolating flaky hardware.
Microsoft is trialing a proactive memory diagnostics feature in the Windows Insider program as part of recent Dev and Beta channel updates. The early flights appear in the cumulative update identified as KB5067109 and in the Dev/Beta build streams (Dev build 26220.6982 and Beta build 26120.6982), and they introduce a user prompt after a bugcheck that recommends running a short memory test on the next reboot.
This is not a full replacement for conventional debugging, nor a cure‑all for every crash type. Instead, it’s a pragmatic triage step that attempts to rule in or out RAM‑related issues quickly, and to gather telemetry that will allow Microsoft to sharpen which crash signatures should trigger the scan in future releases.

---

How the new proactive memory diagnostics works​

The user flow — simple, optional, and pre‑boot​

• After Windows detects a bugcheck and reboots, the next time the user signs in they may see a notification recommending a quick memory scan.
• If the user accepts, Windows will schedule the Windows Memory Diagnostic (the built‑in mdsched pre‑boot test) to run during the next reboot.
• The scheduled diagnostic runs in a minimal pre‑boot environment before the full OS loads, performs a short test pass that Microsoft estimates at five minutes or less on average, and then continues to boot Windows.
• If the diagnostic identifies and is able to mitigate a memory problem, the user receives a follow‑up notification after Windows finishes booting. If not, traditional troubleshooting steps are still required.

Platform and configuration exclusions​

The initial rollout intentionally casts a wide net: Microsoft’s early flight triggers on all bugcheck codes so engineering teams can study crash telemetry and determine which codes correlate most reliably with physical memory corruption. At the same time, Microsoft explicitly excludes several platform/configuration scenarios from this flow in these early builds:

• Arm64 devices — the experience is not currently supported on Arm64 hardware.
• Systems using Administrator Protection — when Administrator Protection is enabled, the prompt will not appear.
• Devices with BitLocker without Secure Boot — the proactive diagnostic will be blocked when BitLocker is configured and Secure Boot is not present.

These exclusions matter: they remove the prompt from some modern devices (Arm64) and from machines with enhanced admin or encryption settings, both common in enterprise fleets.

---

The Windows Memory Diagnostic (mdsched): what it does and what it doesn’t​

Under the hood​

The scheduled job invokes the existing, long‑standing Windows Memory Diagnostic tool (mdsched). That tool runs outside of the full Windows session — in a pre‑boot environment — and performs memory tests that exercise address lines, bit patterns, and data‑path integrity to surface cell‑level or controller problems.
The diagnostic supports several test modes:

• Basic (quick, limited coverage)
• Standard (the default mix of tests)
• Extended (deeper, slower testing)

In the proactive flow Microsoft describes, the system performs a quick/default test intended to complete rapidly, which is why Microsoft reports an average runtime of under five minutes. That short pass is designed as a triage scan — fast enough to be acceptable to most users while catching common, obvious memory failures.

Results and visibility​

• The diagnostic writes results to Windows logs; administrators and users can find test outcomes in Event Viewer under the System log (look for MemoryDiagnostics entries).
• If errors are detected, the diagnostic will report them and Microsoft’s experience says the OS may also attempt to mitigate the problem. The concrete behavior of “mitigation” is worth unpacking (see below).

Limitations and false negatives​

• A short, five‑minute scan is a triage, not an exhaustive analysis. Systems with large amounts of RAM or intermittent faults may require a longer or repeated Extended test to reveal elusive errors.
• Many causes of BSOD are not hardware RAM faults — drivers, kernel bugs, storage corruption, CPU microcode or chipset firmware bugs, and complex software races can produce crash codes that look like memory errors but are root‑caused elsewhere.
• The Windows Memory Diagnostic tool is not infallible: community reports going back years show cases where the diagnostic does not run, returns no result, or hangs. On some systems the pre‑boot environment interaction with firmware features (Fast Boot, UEFI quirks) can interfere with execution.

Given those constraints, the proactive flow should be seen as an automated first‑pass triage, not as a definitive fix.

---

What “mitigate” likely means — and what’s still uncertain​

Microsoft’s blog language says the scan will “attempt to both find and mitigate any possible memory issues that lead to the system crash.” That phrasing is deliberately pragmatic, and the technical reality is nuanced.

• Operating systems and diagnostic tooling can sometimes work around defective memory by blacklisting or reserving known‑bad page ranges so the kernel avoids allocating them. Windows supports a bad‑memory list persisted in boot configuration (BCD) in order to keep the OS from using failing pages — a practical workaround in scenarios where memory is soldered or module replacement is not immediately possible.
• Third‑party tools and other OS ecosystems already use bad‑page blacklists as a temporary mitigation (for example, MemTest86 can produce bad‑page lists that kernels or bootloaders can use to exclude problematic regions).
• In other words, “mitigate” can mean: identify faulty page frames and instruct the boot configuration to avoid them so the system becomes stable enough to boot and let the user recover data or replace hardware.

What remains unclear and therefore should be considered a caution:

• The public documentation for the proactive flow does not fully describe the exact automatic actions taken in every case, nor whether mitigation is always applied automatically or only suggested to an admin/technician.
• It is not guaranteed that the short triage pass will detect intermittent or subtle memory errors, nor that blacklisting will be adequate for severe or widespread hardware failures.

Because the mitigation behavior touches boot configuration and low‑level error persistence, organizations should treat any automatic mitigation as an interim step and follow up with hardware replacement or deeper testing where appropriate.

---

Strengths — why this matters for everyday users​

• Faster, user‑friendly triage. For users who see a BSOD and don’t know how to run diagnostics, the prompt converts a technical procedure into a one‑click option, reducing friction for early detection.
• Reduced wasted time. A five‑minute diagnostic on reboot is a low‑cost step that can rule out physical memory as the cause, saving hours otherwise spent chasing software or driver fixes.
• Data to improve OS logic. By initially triggering on all bugcheck codes, Microsoft can collect telemetry on which crash signatures actually correlate with memory corruption, enabling smarter, less noisy prompts in future builds.
• Potential to prevent data loss. If the diagnostic successfully blocks bad pages and restores stability, users who would otherwise repeatedly crash and risk data corruption may get a better recovery path.
• Built‑in, no‑cost testing. The diagnostic uses existing, native tooling (mdsched), so it does not require additional downloads or third‑party utilities.

---

Risks and limitations — what to watch for​

• False sense of security. If the prompt leads users to believe a single quick scan “fixed” the problem, they may neglect further diagnosis. Some driver‑related or firmware bugs can reappear despite a clean memory test.
• Missed intermittent faults. Intermittent memory errors are notoriously hard to catch with a single quick pass. A short test can return false negatives on systems that need extended, multi‑pass analyses.
• Excessive noise. Because the initial flight triggers on every bugcheck, users may be prompted after crashes that have nothing to do with RAM. That can create unnecessary reboots or checks that don’t help root cause analysis.
• Pre‑boot and encryption complications. The exclusion of systems with BitLocker without Secure Boot reflects real technical constraints: running pre‑boot diagnostics on encrypted volumes can be complex and may require different unlock workflows. Likewise, Administrator Protection and Arm64 exclusions will leave some devices without the benefit of the prompt.
• Enterprise policy friction. Organizations that expect centralized control over diagnostics and remediation need to know the prompt won’t appear on systems where Administrator Protection is enabled — which may be by design for security — but could also complicate fleet‑wide triage.
• Tool reliability concerns. The Windows Memory Diagnostic tool has a long track record, but community reports of hangs, failures to run, or missing results mean the experience may not be flawless for all hardware/firmware combinations.

---

Practical guidance — what users and admins should do​

If you see the prompt: a recommended checklist​

• Accept the scheduled scan if you can afford a reboot — it’s quick in most cases and can eliminate RAM as a suspect.
• After boot completes, check for the follow‑up notification. If the OS reports a mitigation or error, don’t assume the problem is solved — schedule further verification.
• View the Windows event log: open Event Viewer → Windows Logs → System, and filter for MemoryDiagnostics entries to see detailed results.
• If errors are reported:
• Reseat memory modules and retest.
• Test individual DIMMs one‑by‑one to isolate a failing module.
• Run a longer third‑party test such as MemTest86 (bootable ISO) for multiple passes and more exhaustive coverage.
• Update BIOS/UEFI and chipset drivers, as memory issues can sometimes stem from firmware or memory controller bugs.
• If modules are under warranty, arrange replacement sooner rather than later.

For power users and technicians​

• Understand that the proactive flow uses mdsched; you can run the same tool manually and select Extended mode when deeper testing is needed.
• If a mitigation action is applied (bad pages blacklisted), inspect the boot configuration with bcdedit or equivalent tooling to see which regions are reserved, and plan hardware replacement accordingly.
• Don’t skip minidump analysis: if the bugcheck recurs, use minidump parsing tools to inspect call stacks and driver involvement — memory failures are one of many root causes.

For IT administrators and fleet managers​

• Be aware of the exclusions — devices with Administrator Protection or BitLocker without Secure Boot will not show the prompt. That may be acceptable for locked‑down environments, but it removes an automatic triage option.
• Consider documenting how your helpdesk should respond if users accept a proactive scan and it reports an issue. A short internal playbook reduces confusion and escalates faulty hardware quicker.
• Test the behavior on representative hardware before broadly communicating it to end users. Controlled rollouts will surface firmware edge cases and pre‑boot compatibility problems early.

---

What Microsoft should (and likely will) improve​

Based on how Microsoft described the flight and on historical usability patterns, the sensible next steps for the team would include:

• Narrowing trigger criteria so prompts appear only when telemetry shows a strong correlation between crash signatures and memory corruption.
• Adding clearer messaging in the prompt about what the diagnostic can and cannot do, and what follow‑up steps a user or IT should take if the scan reports issues.
• Supporting Arm64 and addressing BitLocker/pre‑boot scenarios so the feature can help a broader set of modern devices.
• Providing richer enterprise controls so IT can opt in or out, or push longer tests for high‑risk or unsupported hardware.

---

Final analysis — useful step, not a silver bullet​

The proactive memory diagnostics pilot is a pragmatic and user‑friendly attempt to move routine crash triage one click closer to mainstream Windows users. For the majority of non‑technical users, offering an automated short memory check after a serious crash reduces the friction of hardware diagnosis and can quickly clarify whether RAM is a likely cause.
That said, the feature is only as valuable as its precision and follow‑through. Microsoft’s decision to open the flight broadly (all bugcheck codes trigger prompts) makes sense from a telemetry and engineering perspective, but it also increases the risk of prompting for irrelevant crashes. The diagnostic’s five‑minute short pass is useful as a first filter but cannot replace extended testing or thorough debugging for intermittent or complex failures.
Administrators and power users should treat the proactive scan as a helpful triage tool: accept it when prompted, but follow up with deeper tests and driver/firmware checks if instability persists. Organizations should evaluate the exclusions — Arm64, Administrator Protection, and BitLocker without Secure Boot — when planning support processes.
In short: this is a sensible, incremental improvement to Windows’ crash recovery toolkit. It will catch straightforward memory faults more quickly and reduce needless troubleshooting. It will not, and should not, be marketed as an automatic cure for all BSODs. The best outcomes will come when Microsoft refines the trigger logic, improves transparency about mitigation steps, and adds more robust enterprise controls so the feature works smoothly across the full diversity of modern Windows hardware.

---

Source: HotHardware Windows 11 Is Testing A New Trick To Thwart Annoying BSOD Crashes