Windows 11 Insider Preview Adds Proactive Memory Diagnostics for Crash Triage

Microsoft is quietly testing a small but potentially habit‑changing feature in Windows Search called Copy & Search — a one‑click way to run a web or system search on whatever text is currently on the clipboard — and it’s arriving alongside a separate reliability feature, Proactive Memory Diagnostics, in recent Insider Preview builds. The change is deceptively simple: when you copy text anywhere in Windows, the taskbar Search box will display a subtle “paste gleam” (a small paste icon or glow). Clicking that gleam pastes the clipboard contents into Search and immediately runs the query, removing the need to open Search, paste, and hit Enter. This capability is shipping as part of KB5067109 in Dev (build 26220.6982) and Beta (build 26120.6982) Insider channels and is being rolled out gradually to Insiders who opt into the fastest delivery toggle.

Background: where Copy & Search and Proactive Memory Diagnostics come from​

Microsoft delivered Copy & Search and the companion Proactive Memory Diagnostics as part of the October Insider flight bundled in KB5067109. The update appears in two simultaneous streams: Dev channel build 26220.6982 (tied to 25H2 enablement) and Beta channel build 26120.6982 (24H2). Both builds contain the same experimental features, which Microsoft is enabling gradually through server‑side flags for Insiders who have the “Get the latest updates as soon as they are available” option enabled.
Proactive Memory Diagnostics is a reliability‑focused change that prompts users who experienced a bugcheck (an unexpected restart or blue/green screen) to allow a quick memory scan on the next boot. Microsoft says the scan takes roughly five minutes on average and will notify the user if a memory issue is found and mitigated. The initial flight triggers the behavior on all bugcheck codes while Microsoft studies correlations between crashes and memory corruption; future builds will narrow the triggers. There are explicit device exclusions in this early flight: the experience is not yet supported on Arm64 devices, machines with Administrator Protection enabled, or systems where BitLocker is present but Secure Boot is disabled.

---

What Copy & Search actually does (UX, flow, and edge behavior)​

The user flow in plain terms​

• Copy text anywhere in Windows — a webpage, a chat message, an Office document, a log or error message.
• Look at the taskbar Search box; a paste gleam appears (a minimal paste icon or glow).
• Click the paste gleam; the clipboard text is pasted into Search and the query runs immediately.

That’s it. The interaction removes the two micro‑steps most people take today — opening Search and pasting — and replaces them with one click. The design is intentionally minimal: no new context menus, no extra flyouts, and no persistent UI changes beyond a transient affordance in the Search box.

Visual and accessibility notes​

The affordance is described as transient and click‑driven: it appears only after a copy action and disappears after a short time or if Search is activated another way. Microsoft’s wording and community writeups indicate the control is primarily mouse/touch/pen oriented; keyboard discoverability (e.g., a dedicated shortcut to trigger the paste gleam) isn’t documented in the release notes and may be addressed later. Because the UX is deliberately low‑profile, discoverability and accessibility (screen‑reader labeling, keyboard focus, and announced behavior) are areas to watch while the feature is evaluated.

---

Why Microsoft is doing this: micro‑friction and habitual workflows​

Copy & Search is a classic example of “remove micro‑friction” design: for users who frequently copy short fragments (error codes, commands, quotes, addresses, search terms), the small repeated cost of opening Search and pasting adds up. By shaving a few seconds off those flows, Microsoft is trying to make lookups feel instantaneous and more fluid. The idea is not novel — browsers have had “paste and go” features for years — but integrating it directly with the system Search box ties clipboard usage more closely to Windows’ broader search, discovery, and Copilot experiences.
For everyday users, the benefit is clear: faster lookups, fewer interruptions, and less context switching. For power users and IT professionals, the feature reduces steps during troubleshooting — copying an error string and running a search is now literally a single click — which is particularly handy when debugging device or configuration issues.

---

The technical and rollout details you should know​

• The changes ship in KB5067109 and appear as Build 26220.6982 on the Dev channel and Build 26120.6982 on the Beta channel. Microsoft is rolling features gradually using server‑side toggles, not a hard on/off in every build.
• The paste affordance is called a “paste gleam” in the release notes — a UI term Microsoft uses to describe the small paste icon or glow inside the Search box.
• The Proactive Memory Diagnostics scheduler adds a Windows Memory Diagnostic scan to the next boot when the user accepts the prompt; Microsoft estimates the scan will take around five minutes in most cases. Early telemetry will use all bugcheck codes to trigger prompts.
• Device exclusions for Proactive Memory Diagnostics in this flight include Arm64 devices, systems with Administrator Protection, and devices running BitLocker without Secure Boot. These constraints are likely to reflect implementation gaps and security/compatibility concerns that Microsoft will address before broader rollout.

---

Strengths: why this small change matters​

• Faster, frictionless lookups: Removing the open‑paste‑enter sequence for search is a genuine time saver for frequent lookups.
• Low cognitive overhead: The paste gleam is unobtrusive and avoids creating another prominent UI element; it’s designed for discovery without being intrusive.
• Consistency with browser patterns: Many users already expect “paste and go” behaviors in browsers; putting a similar affordance into the system Search creates a familiar mental model and reduces learning friction.
• Actionable reliability improvements: Proactive Memory Diagnostics gives users a quick, guided path to surface memory issues after crashes, which could reduce recurring instability and improve support flows for both consumers and IT.
• Staged rollout and telemetry: Microsoft is using the Insider Program and server‑side flags to gather data and iterate before exposing the behavior to broad audiences, which should mitigate widespread surprises.

---

Risks and tradeoffs: what to watch closely​

Privacy and accidental exposure​

Any feature that connects the clipboard to a search surface raises privacy concerns. Clipboards often contain sensitive text — passwords (from carelessly copied strings), personal information, or enterprise secrets like internal IPs and tokens. A visible paste affordance in a shared workstation or when screen sharing could make private clipboard contents easier to expose, even if the feature requires an explicit click to run the search. Enterprises and privacy‑conscious users will want to know:

• Does the paste gleam show any clipboard content preview, or is it a generic icon? (The release notes describe only an icon/gleam, not a preview.)
• Is the paste action logged in search telemetry? If so, how is that telemetry protected and can it be disabled in enterprise environments?

These are practical questions administrators should test; Microsoft’s initial description emphasizes a click to actuate the search, but it does not remove the underlying risk that the clipboard is now more tightly coupled to a system search surface.

Enterprise control, policy, and compliance​

Enterprises will want to control whether and how this feature is enabled in managed environments. Key questions for IT teams:

• Can the paste gleam and Copy & Search behavior be disabled via Group Policy or MDM?
• Is the feature subject to the same privacy and telemetry controls as other Search features?
• Does the paste gleam interact with clipboard guardrails (such as Windows Clipboard history restrictions or enterprise clipboard redaction tools)?

Microsoft is rolling this as an experiment for Insiders and has not documented enterprise controls in the release notes. Administrators should plan to validate behavior in a pilot ring and look for MDM or policy hooks in later builds or administrative templates.

Accessibility and keyboard users​

The initial documentation frames the affordance as a click/tap/pen action. Unless Microsoft provides a keyboard equivalent and proper screen‑reader labels, keyboard‑only users and those who rely on assistive technologies may find the feature less useful or inaccessible. Accessibility testing should be prioritized before general availability.

False positives and noise with Proactive Memory Diagnostics​

Proactive Memory Diagnostics will trigger prompts after bugchecks using all bugcheck codes in this early flight. That broad trigger set could lead to noisy or unnecessary scans if transient or unrelated bugchecks occur. While Microsoft intends to refine targeting, IT teams should be prepared for increased diagnostic activity and verify that scheduled scans do not interfere with critical boot flows or automated deployment processes. The current exclusions (Arm64, Administrator Protection, BitLocker without Secure Boot) reflect real implementation limits that may affect how broadly the feature helps in heterogeneous fleets.

---

What IT teams and power users should test now​

• Deploy the build to a small pilot group with varied hardware (x86, Arm64, BitLocker enabled/disabled) to confirm the behavior of both Copy & Search and Proactive Memory Diagnostics in your environment. Verify device exclusions like Arm64 and Administrator Protection behave as documented.
• Validate privacy boundaries: test whether the paste gleam reveals any clipboard preview, how quickly it times out, and whether clipboard contents are stored in search history or telemetry logs.
• Confirm keyboard and assistive technology support: ensure that screen readers announce the paste gleam and that there’s a keyboard focus path for triggering it.
• Check telemetry and logging: determine whether searches initiated via Copy & Search create additional search logs or telemetry events and how these appear in your existing monitoring systems.
• For Proactive Memory Diagnostics, test the scheduled scan behavior after a synthetic bugcheck in a controlled environment, and measure scan duration and post‑scan notifications. Confirm that scheduled scans do not disrupt BitLocker pre‑boot or encrypted volumes under your existing Secure Boot posture.

---

How this fits into Microsoft’s broader search and AI agenda​

Copy & Search is small but consistent with Microsoft’s broader effort to make Windows more proactive and ambient around user intent: tighter clipboard integration, faster search, and more intelligent, context‑sensitive actions. It complements other moves such as Click to Do, Recall, and Copilot integrations that surface actions or rich results from local and web content. By moving these behaviors into the system Search box, Microsoft is consolidating discovery and action in one place — the taskbar remains the primary surface for quick access to information.
But the tradeoff is that the system search surface now plays a larger role in day‑to‑day tasks and thus becomes a higher‑value target for privacy, policy, and security controls. Enterprise admins should watch how Microsoft exposes management controls and privacy toggles as the feature moves beyond the Insider ring.

---

Reader’s practical takeaways​

• If you’re a Windows Insider and use the Dev or Beta channels with the fastest delivery toggle on, you may already see Copy & Search and Proactive Memory Diagnostics appear on devices running builds 26220.6982 (Dev) or 26120.6982 (Beta). Expect the feature to be staged with server‑side flags rather than an instant, universal enablement.
• For everyday users, Copy & Search reduces friction for searching copied text and should make routine lookups faster without altering long‑standing clipboard behaviors.
• For IT administrators, pilot the feature in a controlled ring, validate privacy and telemetry, confirm keyboard/accessibility behavior, and verify Proactive Memory Diagnostics’ interactions with BitLocker, Secure Boot, and your device protection settings.
• If you have strict compliance or clipboard redaction requirements, flag this feature for policy review: while it’s click‑driven, the tighter integration of the clipboard with Search is a new surface to manage.

---

Final analysis: small feature, outsized implications​

Copy & Search is a textbook example of how modest UX changes can deliver disproportionate productivity gains — shaving small steps from frequently repeated tasks produces a cumulative benefit for many users. Its implementation — a transient paste gleam in the taskbar Search box — is elegantly lightweight, and the staged Insider rollout is appropriate for an experiment that touches both user productivity and privacy.
However, the very simplicity that makes Copy & Search appealing also creates new privacy and enterprise considerations. The clipboard is a porous, frequently used place for sensitive content, and coupling it to the search surface increases the chances of accidental exposure or administrative confusion. Proactive Memory Diagnostics, meanwhile, is a welcome reliability feature but needs careful tuning to reduce noise and ensure compatibility across diverse hardware and firmware setups.
For most users, this is a small, sensible convenience that will make searches faster. For IT and security teams, it’s a prompt to re‑examine clipboard policies, telemetry expectations, and diagnostic workflows. Microsoft’s staged approach and the documented exclusions are encouraging: they show a conservative rollout that prioritizes data collection and refinement before broad availability. The next steps to watch are how Microsoft documents enterprise controls, what accessibility improvements are added, and whether keyboard users receive an equivalent, discoverable activation path for the paste gleam.
Overall, Copy & Search will be judged not on its novelty but on how transparently it balances convenience with control — and how quickly Microsoft provides the administrative tools organizations need to manage a clipboard that’s now even more central to everyday Windows workflows.

---

Source: gHacks Technology News Windows is testing a new Search feature: Copy & Search - gHacks Tech News

Windows 11 will now offer an immediate, one‑click path to check system RAM after an unexpected restart, prompting users to schedule a quick Windows Memory Diagnostic scan the next time the PC reboots.

Background​

Microsoft has begun testing a feature called Proactive Memory Diagnostics in recent Windows Insider Preview builds, surfaced to Insiders in the Dev and Beta channels as part of the cumulative update identified with KB5067109 (Dev build 26220.6982 and Beta build 26120.6982). The goal is to make basic hardware triage for memory faults a native, low‑friction step after a crash (bugcheck) so intermittent RAM problems can be detected and addressed before they cause repeated instability or data corruption.
This change arrives alongside a handful of other small quality‑of‑life updates in the same preview packages — including a new “Copy & Search” quick search for copied text, an adjustable delay option for voice typing, visual adjustments to Device cards in Settings, and refreshed taskbar animations — but the memory prompt is the most consequential for system reliability.

---

How the post‑crash memory prompt works​

The user flow​

• When Windows detects a bugcheck (the kernel event that typically causes a BSOD/GSOD or an unexpected restart), it records the crash and proceeds to restart.
• After the user signs back in, Windows may display a dismissible notification offering to “schedule a quick memory scan” on the next reboot.
• If the user accepts, the OS schedules the built‑in Windows Memory Diagnostic (mdsched.exe) to run in the pre‑boot environment during the next restart. The scan will run, complete, and then allow Windows to continue booting.

Microsoft describes the scheduled pass as a short triage that takes roughly five minutes or less on average on typical systems. The intent is to give users a fast first check without a lengthy outage; it is not positioned as a replacement for longer, forensic memory tests when deeper problems are suspected.

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

The diagnostic invoked by this flow is the long‑standing Windows Memory Diagnostic utility (mdsched.exe), which runs in a minimal pre‑OS environment and performs a series of memory tests to detect physical RAM errors or corruption. Historically, the tool reports faulty memory regions and may allow the OS to avoid allocating those pages but does not physically repair hardware — replacement is often required when persistent errors are found.

---

Why this matters: practical benefits and user impact​

A built‑in, contextually triggered memory check addresses several practical pain points for users and support teams.

• It provides immediate triage after a crash without requiring users to search for tools or create bootable diagnostics.
• Early detection of RAM faults can reduce repeated crash loops, prevent file corruption, and make RMA/warranty claims clearer because diagnostic evidence is captured close to the failure event.
• For many home users, the five‑minute triage pass will be a fast, accessible sanity check before moving into deeper troubleshooting.

From an IT and support perspective, integrating the diagnostic prompt into sign‑in flows should reduce the time help desks spend guiding customers through memory checks and lower the barrier for gathering consistent diagnostic evidence. Enterprises with centralized telemetry and device management will be able to incorporate the new signal into their triage playbooks — provided they accept the feature into managed policies.

---

Technical limitations and exclusions​

The initial flight of the feature is deliberately constrained and includes several platform and configuration exclusions that matter for both consumers and enterprise fleets.

• It is available only to Windows Insiders in the Dev and Beta channels in these preview builds; general availability dates are not specified.
• The prompt is not available on ARM64 devices in the early rollout, leaving Windows on Arm systems out of this convenience for now.
• Systems with Administrator Protection enabled will not show the prompt; this security model restricts certain automated elevated actions.
• Devices that use BitLocker but do not enable Secure Boot are excluded from the experience, because the memory diagnostic runs in a pre‑boot environment and must interoperate with encryption and boot security policies.

Beyond platform exclusions, the initial telemetry strategy is intentionally broad: Microsoft has configured the feature to trigger on all bugcheck codes during early testing, so the team can study which crash signatures actually correlate with memory corruption. That broad triggering will likely be narrowed in future builds to reduce unnecessary prompts for crashes unrelated to RAM (for example, driver or firmware bugs).

---

Strengths of the approach​

• Low friction for users — the prompt is integrated, dismissible, and schedules the scan for the next reboot without forcing an immediate interruption.
• Faster time‑to‑diagnosis — catching RAM faults earlier can prevent data loss, repeated crashes, and prolonged troubleshooting sessions.
• Built on a trusted OS tool — the change uses the existing Windows Memory Diagnostic engine rather than shipping or recommending third‑party utilities, which simplifies support and standardizes results.

These strengths make the feature particularly useful for home users and smaller support operations that lack dedicated hardware diagnostic rigs. The lightweight, automated path should also increase the rate at which hardware‑caused crashes are identified correctly by both users and IT professionals.

---

Risks, caveats and potential problems​

While the feature is promising, there are several important caveats and risks to consider.

• Short scans can miss intermittent or workload‑dependent faults. The advertised five‑minute average is a quick triage pass and not an exhaustive stress test. Problems that appear only under sustained load, high temperatures, or particular memory access patterns may remain undetected. Users should treat a “no issues found” result as useful but not definitive.
• Noise and unnecessary reboots. Because the initial flight triggers on every bugcheck code, machines that crashed for non‑memory reasons may receive a prompt and schedule an unnecessary pre‑boot scan. That behavior could generate user frustration, support tickets, and a modest increase in reboots attributed to the feature rather than the underlying problem.
• Ambiguous “mitigated” messaging. Microsoft’s language suggests the OS might “mitigate” memory issues after the diagnostic runs. That term is imprecise: mitigation could mean quarantining bad pages, avoiding allocations, or reporting for hardware replacement. The exact remediation actions and their permanence are not fully documented publicly, so users and administrators should interpret “mitigated” cautiously.
• Enterprise policy friction. Corporate fleets commonly use BitLocker, Secure Boot policies, and tightened admin controls. The current exclusions and the telemetry used to refine triggers mean the experience will not be universal across managed devices; organizations will need clear guidance and controls to accept, restrict, or audit this behavior in their environments.
• Telemetry and privacy questions. Microsoft has stated data collection will be used to improve trigger accuracy. While diagnostic telemetry is routine for OS engineering, privacy‑conscious consumers and regulated industries may want explicit controls or opt‑outs to understand what crash data is collected and how it is used.

Where claims or details in public messaging cannot be fully confirmed (for example, the precise remediation steps behind a “mitigated” notification), users should regard those claims as partially unverifiable until Microsoft publishes deeper technical documentation or the feature reaches broader channels. Such unverifiable or vague wording is common in early flights and merits cautious interpretation.

---

Enterprise implications and policy considerations​

For IT administrators, the feature introduces both opportunity and policy questions.

• Opportunity: a native, low‑cost triage step simplifies frontline diagnostics and can reduce mean time to resolution for memory‑related incidents. It can also provide reproducible diagnostic evidence tied to the crash event.
• Policy questions:
• Should the feature be enabled by default for managed devices, or controlled via Group Policy / MDM?
• How does the exclusion for BitLocker without Secure Boot interact with existing encryption baselines?
• Will Administrator Protection or other hardening policies block the prompt in ways that hide the diagnostic from help desk triage?
• How should organizations handle telemetry from this flow; does it require changes to current telemetry or privacy agreements?

Administrators should test the feature in staged environments before broad deployment, document expected behaviors in standard operating procedures, and confirm how the results surface in existing endpoint management and telemetry consoles.

---

Practical guidance for end users and technicians​

• If the memory prompt appears after a legitimate crash, consider scheduling the scan — it is fast and non‑destructive. If the scan finds issues, follow up with extended memory tests and hardware vendor diagnostics.
• If the prompt appears after a crash you know was caused by something else (for example, a driver update or overheating during gaming), the notification is dismissible — use that option to avoid an unnecessary reboot.
• If a quick scan reports no errors but crashes continue:
• Run an extended memory test with the Windows Memory Diagnostic “extended” option or a dedicated tool (such as MemTest86) across multiple passes.
• Update chipset/BIOS/UEFI and device drivers.
• Check for thermal issues and power delivery problems, which can cause transient memory faults.
• For enterprise users, coordinate with IT before accepting the scan. Administrators should decide whether to allow the feature, and if allowed, how to capture or forward diagnostic results to support systems.

---

A technical deep dive: what the quick scan can and cannot detect​

The Windows Memory Diagnostic performs deterministic tests that attempt to expose certain classes of DRAM faults — stuck bits, address line failures, or pattern‑sensitive errors. The tool is effective at detecting clear hardware defects and some logic‑level failures.
However, it is limited in several ways:

• It is less likely to reveal faults that only manifest under sustained heavy load, long‑run thermal drift, or specific access patterns generated by particular applications.
• Modern memory subsystems (with on‑die ECC, multi‑rank configurations, and memory remapping) can mask or relocate errors in ways the pre‑boot quick pass may not fully exercise.
• Intermittent timing or signal integrity issues caused by the motherboard, DIMM seating, or power circuitry may require longer stress testing and hardware service diagnostics to surface reliably.

Consequently, rely on the quick scan as an early triage tool and follow up with full memory stress tests and hardware vendor diagnostics when problems persist.

---

What to watch next​

• Expect Microsoft to refine which bugcheck codes trigger the prompt; the initial “all codes” approach is a data‑collection strategy that will likely be narrowed to reduce noise.
• Look for expanded platform support (ARM64) and clarified behavior for enterprise scenarios (BitLocker / Secure Boot / Administrator Protection) as the preview advances.
• Watch for more detailed public documentation from Microsoft describing what “mitigated” means in actionable terms and whether diagnostic logs are made available to users or administrators automatically. Until that documentation appears, the remediation claim should be treated cautiously.

---

Final assessment​

Proactive Memory Diagnostics is a pragmatic, low‑risk addition to Windows 11’s toolbox that brings a sensible convenience: speeding up basic hardware triage and lowering the barrier for users to verify memory health after a crash. The reliance on the built‑in Windows Memory Diagnostic and the lightweight, optional scheduling model are strengths that minimize disruption and vendor lock‑in.
However, the initial flight’s broad triggering, platform exclusions, and vague “mitigation” language introduce practical limits and potential support overhead. The quick scan does not replace in‑depth memory tests or hardware diagnostics for persistent or intermittent faults, and enterprises will need to evaluate the feature against their security baseline and management policies.
Overall, this is a useful step toward making routine hardware triage more discoverable and standardized on Windows devices. Its real world value will depend on how Microsoft refines triggers, documents remediation semantics, and extends the experience across more hardware and secured configurations in subsequent builds.

---

Conclusion
A small but meaningful usability and reliability improvement has arrived in Windows Insider builds: Windows 11 can now prompt users to run a quick, scheduled Windows Memory Diagnostic after an unexpected restart, helping catch RAM‑related problems early. The feature is best understood as triage, not replacement for extended testing. Users and administrators should welcome the convenience while remaining aware of the tool’s limits, the current platform exclusions, and the need for further documentation on remediation behavior as the preview evolves.

---

Source: PCWorld Windows 11 will prompt for memory scans after a crash

Microsoft is testing a new Windows 11 feature that will offer a one‑click, post‑crash memory check after a Blue Screen of Death (bugcheck), scheduling the built‑in Windows Memory Diagnostic to run at the next reboot as a quick triage step to detect and surface RAM-related faults.

Background​

Microsoft introduced the capability in recent Windows Insider Preview builds shipped via the cumulative servicing update identified as KB5067109 (appearing in Dev as Build 26220.6982 and in Beta as Build 26120.6982). The feature, named Proactive Memory Diagnostics, is being piloted to reduce the time between an unexpected kernel crash and a first‑pass hardware triage that can reveal failing DIMMs, memory controller faults, or other memory path problems.
The core idea is simple: after Windows experiences a bugcheck that caused an unexpected restart, the next sign‑in may show a dismissible notification offering to schedule a quick memory scan for the next reboot. If the user accepts, Windows schedules the established Windows Memory Diagnostic tool (mdsched.exe) to run in the pre‑boot environment, perform a rapid default test pass, and then continue booting while reporting results back to the desktop. Microsoft estimates this scheduled triage pass will take about five minutes or less on average on typical systems.

---

What the feature does — a practical overview​

• After a bugcheck (a BSOD or kernel‑level unexpected restart), Windows records the crash and reboots.
• On next sign‑in, Windows may show a notification recommending a “quick memory scan.”
• If the user opts in, the OS schedules the Windows Memory Diagnostic (mdsched) to run at next restart.
• The diagnostic runs before the full Windows session loads, performs a short triage pass, and Windows finishes booting.
• If the diagnostic finds and can apply mitigations, the user receives a follow‑up notification after boot; detailed results are written to Event Viewer under MemoryDiagnostics entries.

This flow is explicitly framed as triage: a fast, low‑friction check intended to catch obvious and reproducible memory faults quickly rather than replace full forensic diagnostics or vendor stress tests. The initial flight is intentionally broad — Microsoft is triggering the prompt for all bugcheck codes while collecting telemetry to refine which crash signatures actually correlate with memory corruption. That telemetry‑driven narrowing is a stated next step to reduce noisy, unnecessary prompts.

---

Technical details: how the scan runs and what it tests​

The diagnostic used: Windows Memory Diagnostic (mdsched)​

The proactive flow leverages the long‑standing Windows Memory Diagnostic (mdsched.exe). This tool runs outside the full Windows session in a minimal pre‑boot environment and has three primary test modes: Basic, Standard (default mix), and Extended. The Proactive Memory Diagnostics experience schedules a quick/default pass — designed to complete rapidly and catch common, clear memory errors such as persistent cell failures or address line problems. Results are logged to the System log with MemoryDiagnostic entries.

Where results appear and how they can be consumed​

• Desktop notification after boot will inform users of detected issues or mitigations applied.
• Administrators and power users can inspect Event Viewer > System for MemoryDiagnostics results to extract details and timestamps for support or RMA workflows.
• The scheduled diagnostic produces the same kind of log artifacts as an mdsched run invoked manually, making it usable as a diagnostic artifact in support escalations.

Platform and security gating in the early flight​

Microsoft lists several important exclusions for the initial rollout: the prompt is currently not supported on ARM64 devices, on systems with Administrator Protection enabled, and is blocked when BitLocker is active without Secure Boot. These exclusions are consequential for both consumers and enterprise fleets and reflect pre‑boot and boot security interactions with disk encryption and secure boot flows. The company is also rolling this out via staged, server‑side toggles, so not every Insider will necessarily see the feature immediately even after installing the relevant update.

---

Why Microsoft is adding this: intended benefits​

Memory corruption is a common but often hidden cause of random crashes, application corruption, and repeated instability. The new prompt aims to deliver several practical benefits:

• Faster triage: A one‑click path to a built‑in memory check reduces the need for users or techs to remember mdsched or hunt for third‑party diagnostics.
• Reduced downtime: Catching failing RAM early can stop crash loops and prevent data corruption or repeated support cycles.
• Standardized evidence: Because the built‑in diagnostic writes system logs, it simplifies RMA and warranty workflows where vendor evidence is required.
• Low friction and consent driven: The scan is opt‑in, scheduled to the next reboot, and positioned as a short triage pass — balancing usefulness with minimal interruption.

These are pragmatic, incremental improvements that, for many end users and smaller support operations, can measurably shorten the path to identifying common hardware causes of instability.

---

Caveats, limitations, and risk profile​

Short scans are not exhaustive​

The advertised ~five‑minute runtime reflects a brief triage pass, not a comprehensive stress or forensic test. Intermittent errors, thermal‑dependent failures, or faults that appear only under heavy sustained load may not be detected in a quick pre‑boot pass. A “no issues found” message therefore should be treated as useful but not definitive. Extended tests (the Extended mdsched mode) or vendor stress tools may still be required when intermittent symptoms persist.

Noise and false positives during the telemetry collection phase​

Because Microsoft is temporarily triggering the prompt for all bugcheck codes to gather telemetry, there is a meaningful risk of noisy prompts. Crashes caused by driver bugs, firmware glitches, or overheating could cause the diagnostic prompt to appear even when RAM is not at fault. That noise can create user confusion, extra reboots, and a temporary uptick in support tickets until triggers are refined. Administrators running critical workloads should be aware of this risk during pilot deployments.

Ambiguous wording around “mitigation”​

Microsoft’s messaging that the diagnostic may “mitigate” issues needs clarification. In practice, the OS can sometimes avoid allocating flagged bad pages or report errors that lead to deeper remediation steps, but the diagnostic itself does not physically repair hardware. Treat any “mitigated” status as an indication the system observed a problem and avoided the failing region, not as a permanent fix for a defective DIMM. This distinction matters for warranty and replacement decisions.

Platform and enterprise exclusions matter​

The early exclusions (ARM64, Administrator Protection, BitLocker without Secure Boot) leave many modern, secure, or enterprise devices out of the immediate benefit. Administrators should validate the behavior against their fleet profiles before relying on it as a first‑line triage tool in production.

Telemetry and privacy considerations​

Public release notes do not fully enumerate the telemetry the feature collects while Microsoft refines triggers. Enterprises and privacy‑conscious users should treat telemetry claims as unverified until Microsoft provides a detailed telemetry/privacy breakdown for the proactive diagnostic flow. Organizations may choose to block or pilot the feature behind policy until telemetry handling is clarified.

---

What this means for different audiences​

Home users and enthusiasts​

• Benefit: A fast, built‑in way to check RAM after a scary BSOD without creating bootable media or downloading tools.
• Caveat: A quick pass might not catch intermittent faults; follow up with longer tests if issues persist.
• Action: If offered the prompt and you have time for a short reboot, accept it — it’s a low‑cost check that can save hours of troubleshooting later.

IT help desks and support teams​

• Benefit: Standardized diagnostic artifacts in Event Viewer simplify triage and RMA paths.
• Caveat: Expect noise during early flights; plan to collect telemetry on prompt frequency and false positives to inform acceptance policies.
• Action: Pilot the feature on representative test devices first, exclude ARM64 fleets if necessary, and prepare playbooks to escalate to vendor diagnostics when short scans are inconclusive.

Enterprises and device managers​

• Benefit: Potential to reduce time to root cause for hardware‑related incidents.
• Caveat: Exclusions and telemetry uncertainty mean this should not be treated as authoritative in its initial state.
• Action: Use Group Policy or Intune policy to control Insider enrollments and testing; monitor Microsoft’s documentation for policy controls that may allow administrators to opt devices out until triggers are refined.

---

How to interpret and act on results​

• If the diagnostic reports errors:
• Review Event Viewer > System for MemoryDiagnostics‑Results.
• Cross‑check with vendor memory test utilities and run extended tests (Extended mdsched or vendor tools).
• Document logs and timestamps for warranty/RMA claims.
• If the diagnostic reports no issues found:
• Consider running a longer Extended test or vendor stress tool if crashes continue.
• Inspect other causes: drivers, firmware/BIOS updates, thermal throttling, and storage corruption.
• If the diagnostic behavior or prompts become noisy:
• Record frequency and bugcheck codes triggering prompts and provide feedback through Insider channels to help Microsoft refine triggers.

---

Recommended pilot checklist for IT teams​

• Identify a representative set of test devices that mirror your fleet’s x86/x64 hardware; exclude ARM64 devices to ensure the feature is present for testing.
• Enroll these devices in the Windows Insider program (Dev or Beta channel) and install the relevant servicing update (KB5067109) to obtain the builds shipping the feature.
• Reproduce crash scenarios in a controlled lab when safe, or monitor naturally occurring bugchecks while measuring prompt frequency and the percentage of scans that find memory issues.
• Validate integration with enterprise imaging, BitLocker, and Secure Boot policies to confirm the prompt behaves consistently in managed configurations.
• Prepare escalation steps to vendor diagnostic suites for any diagnostic artifacts that indicate persistent faults.

---

Practical advice for everyday users​

• When you see the sign‑in notification offering a quick memory scan after a crash, accepting is usually a sensible first step if you can spare a short reboot.
• If you rely on critical services or have unsaved work, schedule the scan for a maintenance window — the scan is opt‑in and scheduled for the next reboot rather than forcing an immediate interruption.
• If the scan finds nothing but problems continue, run Extended memory tests or vendor tools and check for driver/firmware updates. Do not assume a clean short scan rules out memory issues entirely.

---

Analysis: strengths, tradeoffs, and long‑term implications​

Notable strengths​

• Low friction and discoverability: Integrating basic hardware triage into the sign‑in flow lowers the barrier to action for non‑technical users and reduces reliance on third‑party tools.
• Evidence generation: Automatic logging of results into Event Viewer creates consistent artifacts useful for support, vendor RMA, and warranty claims.
• Data‑driven refinement: Microsoft’s telemetry approach — broad initial triggers followed by refinement — is sensible for engineering but requires clear communication to manage expectations and noise.

Potential risks and tradeoffs​

• User disruption and support churn: If prompts are too frequent or misaligned with the root cause, users can become frustrated and support teams will see increased ticket volume.
• Incomplete diagnostics: Short triage passes can provide false reassurance; vendors and admins must continue to rely on deeper tests for definitive results.
• Telemetry and privacy: Without full transparency on telemetry, organizations should be cautious when enabling the feature fleet‑wide.

Long‑term implications​

If Microsoft successfully sharpens which bugcheck signatures correlate with memory corruption, the proactive flow could become a powerful reliability tool that prevents repeated crashes and reduces wasted support cycles. Conversely, if triggers remain noisy or telemetry remains opaque, adoption in enterprise settings will be slow and the feature could be relegated to a convenience for home users rather than a broadly useful IT tool. The success of this experiment hinges on balancing sensitivity (catching real memory faults) with specificity (avoiding prompts for unrelated failures).

---

Quick reference: what to watch for in future releases​

• Whether Microsoft narrows the initial “trigger on all bugcheck codes” approach to a targeted set of crash signatures.
• Updates on telemetry collection and privacy disclosures specific to Proactive Memory Diagnostics.
• Expansion of platform support (ARM64) and adjustments to Administrator Protection/BitLocker gating.
• Introduction of management controls (Group Policy / Intune) to allow enterprises to opt devices in or out of the experience.

---

Conclusion​

Proactive Memory Diagnostics is a pragmatic, user‑centric feature that applies an existing, trusted diagnostic (Windows Memory Diagnostic) in a new, contextually relevant way: right after a kernel crash. For many users, the change will reduce friction and accelerate the detection of clear RAM faults. For IT teams, it promises a standardized artifact to aid triage — provided Microsoft refines triggers and clarifies telemetry handling.
The feature is not a silver bullet. Short pre‑boot scans cannot replace extended stress tests or vendor diagnostics for intermittent or workload‑specific faults. Early adopters should pilot carefully, collect data on prompt accuracy, and treat results as the start of an evidence chain rather than the final verdict. If Microsoft balances sensitivity with specificity and gives admins clear controls, this small UX change could make a measurable difference in day‑to‑day reliability for Windows 11 users.

---

Source: [H]ard|Forum https://hardforum.com/threads/windo...s-after-bsod-to-prevent-future-issues.2044339

Microsoft is testing a new, consent-driven post‑crash diagnostic in Windows 11 that will offer users a one‑click way to schedule a quick RAM check after a Blue Screen or unexpected restart — scheduling the built‑in Windows Memory Diagnostic to run at the next reboot and report back if errors or mitigations are detected.

Background​

Microsoft introduced this experiment as part of recent Windows Insider preview updates distributed under KB5067109. The change appears in Dev‑channel builds as Build 26220.6982 and in Beta‑channel builds as Build 26120.6982, with the public write‑up published on the Windows Insider blog.
The feature — named in Microsoft’s notes as Proactive Memory Diagnostics — aims to reduce the time between a kernel bugcheck and basic hardware triage by surfacing a sign‑in notification after an unexpected restart. If the user agrees, Windows schedules a pre‑boot Windows Memory Diagnostic (mdsched.exe) run for the next restart. Microsoft characterizes the scheduled pass as a short triage step, “taking 5 minutes or less on average.”
This is an early, controlled flight: Microsoft intentionally triggers the prompt for all bugcheck codes during telemetry collection, and the experience is gated on several platform and security conditions in the preview.

---

What this actually does — step by step​

1. Crash detection and sign‑in notification​

After Windows detects a bugcheck (an unexpected restart often visible as a BSOD/GSOD/black screen), the system records the crash and reboots. On the next sign‑in a dismissible notification may appear suggesting a quick memory scan.

2. User consent and scheduling​

If the user accepts, Windows schedules the built‑in Windows Memory Diagnostic to run during the next restart in the pre‑boot environment. This scheduling is opt‑in — the prompt is dismissible and no scan runs without explicit consent.

3. Pre‑boot scan and resume​

On the subsequent reboot the Windows Memory Diagnostic runs before the full OS loads, performs a short default pass (the quick triage), and then resumes booting into Windows. Microsoft’s initial guidance estimates the quick scan will take around five minutes on average, although actual runtime depends on configured test depth and installed RAM.

4. Notification and evidence​

If the diagnostic finds and applies mitigations, Windows will deliver a follow‑up notification after boot. The underlying test writes results to Event Viewer (look for MemoryDiagnostics entries), giving technicians a forensic artifact to use for warranty claims or further triage.

---

Why Microsoft is doing this​

Memory corruption — whether from defective DIMMs, flaky memory controllers, incompatible firmware, or unstable overclocking/XMP settings — is a common but often invisible root cause of crashes, freezes, and data corruption. Historically, running a memory test has required manual action: launching the Windows Memory Diagnostic (mdsched), scheduling it for the next reboot, or booting a third‑party tool such as MemTest86 from USB. Automating the triage prompt immediately after a crash reduces friction for non‑technical users and can accelerate identification of hardware faults before they cause repeated downtime or corrupted files.
For enterprises and support desks, this could mean faster, more consistent evidence collection for RMAs and quicker first‑line diagnosis — if the feature is adopted within managed policies and piloted carefully.

---

Technical details and constraints​

The diagnostic used​

The feature leverages the long‑standing Windows Memory Diagnostic (mdsched.exe) utility — the same pre‑boot tester used by administrators for years. That tool offers Basic, Standard and Extended test mixes; Microsoft’s proactive flow schedules a quick/default pass intended to be short.

Where results are logged​

Results from a Windows Memory Diagnostic run are normally recorded in Event Viewer under Applications and Services Logs → Microsoft → Windows → MemoryDiagnostics‑Results or visible in the System log as MemoryDiagnostic events. Administrators can parse these logs programmatically (PowerShell Get‑WinEvent) for automated ticketing.

Timing considerations​

Microsoft’s “five minutes or less on average” is a practical estimate for the quick triage pass, not a guarantee. Actual test time depends on:

• Amount of installed RAM
• The chosen test mix (Basic/Standard/Extended)
• CPU and platform performance
• Number of passes configured

A short default pass is plausible for modest RAM sizes, but extended diagnostics still require substantially more time; power users and technicians should not treat a quick negative as definitive.

Platform and security exclusions​

In the current Insider flight Microsoft has explicitly restricted the experience. The prompt is not available on:

• ARM64 (Windows on ARM) devices
• Systems with Administrator Protection enabled
• Devices using BitLocker where Secure Boot is not enabled

These exclusions reflect the pre‑boot nature of the test and interactions with boot security/encryption and endpoint protections.

Which Insider builds include it​

The capability is shipped as part of cumulative update KB5067109, appearing as Build 26220.6982 (Dev) and Build 26120.6982 (Beta) in the Insider program; Microsoft is rolling features gradually via server‑side toggles.

---

Practical benefits for everyday users​

• Lower barrier to triage: Non‑technical users are far more likely to run a test when it is presented as a single, integrated action.
• Faster warranty evidence: Early detection increases the chances of documenting faulty RAM before it causes further damage, easing RMA claims.
• Fewer sketchy downloads: A native option discourages users from searching for third‑party RAM testers — some of which can be outdated or bundled with unwanted software.
• Minimal downtime (in many cases): The quick pass aims to finish in minutes and resume the boot process, reducing disruption compared with longer manual tests.

---

Limitations, risks and what Microsoft hasn’t fully specified​

This is triage, not a silver bullet​

The experience is explicitly framed as a first pass — a rapid triage that may catch obvious hardware failures but will not replace full forensic memory validation. Intermittent faults, thermal or stress‑related failures, and subtle timing issues can escape a short scan and require multi‑pass Extended tests or MemTest86 cycles.

“Mitigate” is ambiguous​

Microsoft’s blog says the diagnostic “may find and mitigate” issues, but the company has not published a machine‑readable specification of what mitigation entails in each failure class. In practice, typical mitigations might include blacklisting bad pages from allocation or advising a replacement; they do not repair physical faults. This lack of specificity should be treated as an unverifiable claim until Microsoft documents the exact remediation logic.

Over‑triggering and noise​

Because the initial flight triggers on all bugcheck codes to collect telemetry, many prompts will be false positives for memory‑related causes. Enterprises may see additional helpdesk volume if users treat the quick scan as definitive rather than a first step. Microsoft intends to refine triggers based on telemetry, but early adopters should expect some noise.

Coverage gaps in managed fleets​

Platform exclusions (ARM64, Administrator Protection, BitLocker without Secure Boot) mean many managed endpoints — especially those hardened with security features — won’t see the prompt. IT organizations should not rely solely on this feature for fleet health checks; continue to maintain manual diagnostic flows and vendor test kits.

Event logging and result visibility​

Some users have historically reported difficulty finding or interpreting Windows Memory Diagnostic results in Event Viewer. If the proactive flow is relied upon for RMA evidence, organizations should validate the exact log artifacts produced by the scheduled run and ensure helpdesk tooling parses the correct event source. Microsoft and third‑party documentation provide guidance for locating these logs, but the behavior may vary across Windows builds and configurations.

---

Guidance for IT teams and enthusiasts​

• Pilot before broad rollout:
• Identify a representative set of test machines (x86/x64 profiles).
• Validate behavior under your typical boot security and BitLocker policies.
• Confirm how Event Viewer logs appear and whether they integrate with your ticketing/telemetry pipeline.
• Treat results as triage:
• A single quick pass is a helpful signal, not definitive proof.
• For positive findings, follow with extended tests, per‑module isolation, or vendor diagnostic tools before issuing replacement orders.
• Update runbooks and automation:
• Add parsing of MemoryDiagnostics events.
• Correlate minidump stop codes with memory failures before escalating to hardware RMA.
• Document privacy and telemetry posture:
• Microsoft’s early telemetry collection will be broad; review diagnostic data settings and audit what is uploaded if your organization has strict telemetry policies.
• Communicate to end users:
• Explain the prompt, emphasize opt‑in behavior, and provide simple guidance: accept the scan when convenient, then report results if they indicate hardware faults.

---

How this changes everyday troubleshooting​

For home users and small support teams, the new flow converts an often‑ignored but critical test into a contextual prompt: you crash, you sign in, and Windows offers a quick diagnostic step. That changes the default user behavior for the better — more scans, more evidence, faster identification of bad RAM.
For technicians, it adds another artifact to the triage stack: an Event Viewer entry produced close to the crash timeline that can be correlated with minidumps and firmware logs to find root causes faster. For enterprises, the impact will depend on how Microsoft exposes policy controls (Group Policy, MDM) and whether the company narrows triggers to high‑signal stop codes before wide release.

---

What to watch next​

• Microsoft’s refinement of trigger rules: narrowing prompts to specific bugcheck signatures that most strongly correlate with memory corruption.
• Formal documentation of what “mitigate” means and whether the OS applies any persistent changes after detection.
• Expansion of support to ARM64 and clarifications on Administrator Protection and BitLocker interplay.
• Enterprise controls: Group Policy or MDM settings to allow, block, or customize the proactive memory diagnostics experience across managed fleets.

---

Final assessment​

Proactive Memory Diagnostics is a practical, low‑friction reliability feature that addresses an old Windows pain point with a sensible, opt‑in approach. It leverages existing, trusted tooling (the Windows Memory Diagnostic) and improves discoverability for a critical hardware test. For average users it will likely reduce the time to detect failing RAM and discourage unsafe third‑party downloads. For IT teams it offers a new signal for triage — provided they pilot and validate the experience against vendor diagnostics.
That said, the feature’s current telemetry‑first rollout and platform exclusions introduce noise and coverage gaps. The promise that Windows will “mitigate” memory issues is useful but currently imprecise; organizations should demand clearer documentation and enterprise policy controls before adopting the feature as a formal step in support playbooks. Until triggers are refined and mitigation behavior is transparent, treat results as triage evidence to be followed by vendor‑grade verification.

---

Accept the scan when convenient, use the Event Viewer MemoryDiagnostics entries to capture evidence, and follow up with Extended tests or MemTest86 when the quick pass indicates problems or crashes persist — this combination preserves speed without sacrificing diagnostic rigor.

---

Source: PCMag Australia Windows 11 Will Soon Offer Memory Scans After a Blue Screen of Death

Microsoft has added a lightweight, consent-driven RAM triage step to Windows 11 Insider builds that prompts users to schedule a quick Windows Memory Diagnostic after a bug check (BSOD) and reboot — a small but pragmatic change that could shorten time‑to‑diagnosis for memory-related crashes while raising important questions about scope, accuracy, and enterprise manageability.

Background​

Microsoft introduced the new Proactive Memory Diagnostics flow in the Windows Insider Preview updates distributed as KB5067109, appearing in Dev channel Build 26220.6982 and Beta channel Build 26120.6982. The capability surfaces a dismissible sign‑in notification after Windows records an unexpected restart due to a bug check, offering to schedule the built‑in Windows Memory Diagnostic (mdsched.exe) to run in the pre‑boot environment on the next reboot. Microsoft describes the scheduled pass as a short triage pass that typically takes “five minutes or less on average.”
This change is positioned explicitly as a first-pass triage rather than a replacement for extended forensic tests. It’s intended to reduce friction for non‑technical users and support teams by automating the common, sensible step of running a RAM check right after a crash — a step that many casual users simply never take. Early reporting and community threads picked up the announcement and reiterated the same core details: opt‑in prompt at sign‑in, scheduling of the Windows Memory Diagnostic for the next reboot, and the “≈5 minute” average runtime claim.

---

How the new post‑crash RAM check works​

The user flow (simple and optional)​

• After Windows experiences a bug check and restarts, the next sign-in may show a notification recommending a quick memory scan.
• If the user accepts, Windows schedules the Windows Memory Diagnostic to run during the next reboot (pre‑OS).
• The diagnostic runs a short/default test pass, the system continues booting, and Windows will notify the user if issues were found or mitigated.

Technical surface details​

• The scheduled diagnostic invokes the long‑standing mdsched.exe (Windows Memory Diagnostic) tool, running it in a pre‑boot environment so the test is not influenced by loaded drivers or the full OS.
• Results are recorded to standard locations such as Event Viewer (MemoryDiagnostics‑Results) and surface as a post‑boot notification if the tool reports findings.
• In this early flight Microsoft intentionally triggers the prompt for all bugcheck codes while they gather telemetry, with plans to refine triggers to crash signatures that correlate strongly with memory corruption in future builds.

---

Why this matters: practical benefits​

Faster, lower‑friction triage​

For many home users and small support desks, running a RAM diagnostic is a hurdle — it’s relatively obscure, requires a reboot, and takes time. A one‑click prompt that schedules the test for the next reboot removes friction and can produce an actionable data point immediately after a crash. That can:

• Reduce time spent on driver/OS reinstall cycles when the root cause is physical memory.
• Provide earlier evidence for RMA/warranty claims by capturing diagnostics close to failure.
• Decrease helpdesk calls by giving users a standard, documented first step.

Multiple community analyses and previews highlight that the approach is pragmatic: use the OS’s built‑in tooling to make a standard triage step discoverable and low‑friction.

Built on an existing, well‑understood tool​

The flow uses the existing Windows Memory Diagnostic rather than shipping a new binary or recommending third‑party tools. That makes behavior predictable for IT teams and for users who may already be familiar with mdsched’s Basic/Standard/Extended mixes. The short scheduled pass is explicitly a triage run, not an exhaustive extended test.

---

Limits, caveats, and important technical realities​

The “five‑minute” estimate is conditional​

Microsoft’s “five minutes or less on average” is a reasonable expectation for a short default pass on modest RAM sizes, but it is not a firm guarantee. Actual runtime depends on:

• Total installed RAM
• CPU and platform performance
• The diagnostic test mix (Basic/Standard/Extended)
• Number of passes configured when the tool runs

For large memory configurations (32 GB, 64 GB, or higher) or when extended diagnostics are selected manually, test time can grow substantially. Treat the quick pass as a screening check, not an exhaustive validation.

Triggers are intentionally broad in early flight​

Microsoft has set the early flight to trigger on all bugcheck codes to collect telemetry and determine which crash signatures most reliably indicate memory corruption. That strategy is sensible from an engineering perspective but will create noise: many crashes (driver bugs, storage faults, overheating, firmware issues) have nothing to do with RAM. Microsoft plans to narrow triggers later, but in the initial preview the prompt may appear for non‑memory crashes.

“Mitigation” is ambiguous — treat claims cautiously​

Microsoft’s language that the diagnostic may find and “mitigate” memory issues is vague. Typical diagnostic “mitigations” can include:

• Identifying and logging faulty regions so the OS can avoid allocating them
• Marking pages as bad in low‑level boot configuration or reporting to telemetry

These are not hardware repairs; persistent uncorrectable errors usually require module replacement. The exact remediation steps the OS takes (and whether they are automatic or advisory) are not fully spelled out in public documentation and should be considered ambiguous until clarified. Flagging this wording as imprecise helps set expectations: a successful mitigation in a triage pass is not synonymous with permanent repair.

Platform and security exclusions​

In the initial Insider flight Microsoft is gating the experience in several ways:

• Not available on ARM64 devices (Windows on Arm).
• Disabled on systems with Administrator Protection enabled.
• Blocked on devices that use BitLocker but do not have Secure Boot enabled.

These exclusions reflect pre‑boot complexity around encrypted volumes, boot security, and privileged scheduling; they matter for enterprise fleets that commonly use BitLocker or hardened admin policies.

---

Interaction with modern memory kits: XMP, EXPO, overclocked RAM​

XMP/EXPO are essentially factory overclock profiles​

Memory vendors ship modules with XMP (Intel) or EXPO/DOCP (AMD) profiles that allow modules to run at advertised higher-than‑JEDEC speeds by applying predefined timings and voltages. In practice, these profiles are vendor-validated settings that can be more aggressive than JEDEC defaults. Manufacturers and motherboard vendors explicitly treat XMP/EXPO as overclocking-like behavior and warn users about potential instability and warranty implications.

Why XMP/EXPO sometimes causes memory instability​

• XMP/EXPO settings can push the CPU’s integrated memory controller and platform interconnect beyond nominal JEDEC parameters.
• Variability in motherboards, CPU memory controllers, DIMM silicon, and board power delivery means not every system will be stable at a given XMP/EXPO profile.
• Industry reporting and vendor notices show cases where aggressive memory profiles contributed to instability and, in rare cases, hardware stress that required vendor warnings.

This matters because Proactive Memory Diagnostics may surface faults that only manifest with XMP/EXPO enabled. A quick triage run could help identify an unstable profile early, but users and technicians should interpret findings in the context of whether a memory profile is active. If faults appear after enabling XMP/EXPO, the correct step can be to revert to JEDEC defaults or manually tune voltages/timings rather than assuming a bad DIMM out‑of‑the‑box.

---

Enterprise considerations and management​

Policy controls and telemetry​

Enterprises will need:

• Group Policy/Intune controls to opt in or block the post‑crash scan.
• Clear documentation about what telemetry is collected and how crash-to‑memory correlation data is used.
• Test plans to validate interaction with BitLocker, Secure Boot, and Administrator Protection.

Microsoft’s early flight excludes certain managed configurations, but IT teams should expect Microsoft to add management controls before general availability. In the meantime, pilot testing on representative hardware is essential.

Impact on support workflows​

• Helpdesks should update runbooks to include the proactive scan as an initial step, while emphasizing that a negative quick pass is not definitive.
• If the quick scan reports errors, IT should collect logs (Event Viewer MemoryDiagnostics‑Results, minidumps) and then escalate to extended tests or vendor diagnostics as appropriate.
• For large fleets using BitLocker without Secure Boot or ARM64 devices, the prompt won’t appear; alternative triage workflows must be documented.

---

Practical guidance for technicians and everyday users​

• If prompted by the post‑crash notification, accept the scheduled scan if you can afford the reboot delay — it’s a low-cost, high‑value triage step.
• After the reboot, if Windows shows a follow‑up notification, open Event Viewer → Windows Logs → System and filter for MemoryDiagnostics‑Results to view the report.
• If the quick pass reports errors:
• Reseat the DIMMs and confirm proper seating and slot population.
• Update BIOS/UEFI and chipset drivers; memory-related bugs are sometimes fixed in firmware.
• Run extended memory tests (Windows Memory Diagnostic Extended mode or MemTest86 for multiple multi‑hour passes).
• If errors persist, prepare documentation and diagnostics for RMA/warranty claims.
• If the scan reports no errors but crashes continue:
• Don’t assume memory is healthy; intermittent faults or workload‑dependent failures can escape a short pass.
• Run extended multi‑pass tests and examine minidumps (WinDbg, BlueScreenView) to correlate crash stacks with potential faulty subsystems.

---

Risks and potential unintended consequences​

• False reassurance: A negative quick scan could lull users into thinking hardware is fine, delaying deeper investigations into intermittent faults.
• Noisy prompts: With the initial “all bugcheck codes” strategy, many users will see prompts for crashes unrelated to memory, which may frustrate users and support teams until triggers are narrowed.
• Boot interruptions: Scheduling pre‑boot diagnostics can add time to reboots; organizations that rely on ultra‑fast boot windows should consider policy controls to avoid unexpected delays.
• Coverage gaps: ARM64 systems and BitLocker-without-Secure-Boot setups are excluded in the preview, leaving modern device segments without this convenience until support expands.

---

What Microsoft should clarify next​

• Precisely define what “mitigate” entails when the memory diagnostic reports issues: automatic page avoidance, boot configuration changes, or simply guidance to the user?
• Publish clear enterprise management knobs (Group Policy / Intune) to allow admins to control prompt behavior, mandatory/optional test depth, and telemetry sharing.
• Narrow and document the crash signatures that will trigger the flow once telemetry analysis is complete.
• Release developer/IT documentation describing where logs land, expected Event IDs, and programmatic APIs for helpdesk integration.

Community analysis and previews identified these items as necessary next steps for the feature to be broadly useful across consumer and enterprise contexts.

---

Reading the signals: how to interpret diagnostic outcomes​

• Positive result (errors found): Treat as credible evidence of memory-path problems. Follow up with extended tests, module swaps, and vendor diagnostics. If confirmed, proceed with warranty/RMA.
• Negative result (no errors): Use as a hint, not proof. Escalate to extended multi‑pass tests if crashes persist or correlate with specific tasks or workloads.
• Recurrent crashes despite clean memory tests: Focus on drivers and firmware, thermal and power delivery issues, storage corruption, or motherboard/slot problems. Memory faults are only one member of a longer root‑cause analysis sequence.

---

Final assessment​

Proactive Memory Diagnostics is an incremental but meaningful addition to Windows 11’s reliability toolbox. By surfacing the Windows Memory Diagnostic at a moment when it’s most useful — immediately after a bug check — Microsoft reduces friction for a standard diagnostic step and gives users and support teams a fast, native way to rule in or rule out RAM as a potential cause of crashes. The feature’s strengths are its low friction, use of a trusted built‑in tool, and telemetry-driven approach to refining triggers.
At the same time, the feature is a triage aid, not a silver bullet. The quick pre‑boot pass is limited in coverage; the “mitigation” language is vague and needs clarification; and the initial “all bugcheck” telemetry strategy will create noisy prompts until Microsoft narrows triggers. Enterprises will rightfully ask for management controls, detailed documentation, and clarity on telemetry. Users relying on aggressive XMP/EXPO profiles should be particularly attentive: those profiles act as factory overclocks and can surface the exact intermittent behavior that a quick diagnostic may or may not detect, depending on test depth.
For now, Windows Insiders can test the feature in KB5067109 (Build 26220.6982 / 26120.6982), and everyday users should consider the new prompt as a useful first step in crash triage — accept it when convenient, follow up with extended tests if problems persist, and treat a single quick pass as informative but not definitive.

---

Conclusion
A one‑click RAM check after a BSOD is exactly the kind of practical usability improvement that addresses a real user pain: making a routine hardware triage step discoverable, painless, and native to the OS. If Microsoft sharpens trigger accuracy, documents mitigation semantics, and provides enterprise controls, Proactive Memory Diagnostics can become a small but reliable defender against recurring crashes and subtle data corruption. Until then, treat it as an efficient screening tool — welcome, useful, and limited, but far better than doing nothing after the next unexpected restart.

---

Source: Tom's Hardware New Windows 11 feature aims to diagnose crashes — will check RAM after BSODs to look for problems

Microsoft’s latest Insider preview quietly adds a small but practical reliability feature to Windows 11: after an unexpected restart or bugcheck, the operating system can now prompt you at sign‑in to schedule a quick RAM scan that runs automatically on the next reboot, using the built‑in Windows Memory Diagnostic. This “Proactive Memory Diagnostics” flow is rolling out to Insiders in the Dev and Beta channels as part of the KB5067109 preview packages (Dev build 26220.6982 and Beta build 26120.6982), and is explicitly framed as a lightweight, consented triage step rather than a replacement for forensic memory testing.

---

Background / Overview​

Memory faults are an uneasy category of PC failures: they can cause random crashes, silent data corruption, and intermittent behavior that’s difficult to reproduce. For years Windows has included the Windows Memory Diagnostic tool (mdsched.exe) that runs in a pre‑boot environment to check installed RAM, but most ordinary users never run it because it requires scheduling a reboot or creating a bootable USB for third‑party tools.
The new Proactive Memory Diagnostics feature stitches that existing capability into the post‑crash user flow. After Windows detects a bugcheck (the kernel stop error typically shown as a BSOD, GSOD, or black screen), the next time you sign in the OS may display a dismissible notification asking whether you want to schedule a “quick memory scan” for the next restart. If you accept, Windows schedules the Memory Diagnostic to run before the OS loads, performs a short triage pass (Microsoft estimates about five minutes on average), then continues to boot and notifies you of results if an issue was found and mitigated.
This change is already being observed in community reporting and forum threads from Insiders who installed the KB5067109 preview; multiple outlets confirm the same basic behavior and the initial platform exclusions.

---

What the feature actually does​

The user flow (simple and optional)​

• Windows records a bugcheck and restarts.
• On the next sign‑in, a toast‑style suggestion may appear recommending a “Quick memory scan.”
• If the user opts in, Windows schedules the Windows Memory Diagnostic (mdsched.exe) to run during the next reboot.
• The diagnostic runs in the minimal pre‑boot environment, executes a short test pass (the proactive flow is tuned for speed), then Windows continues booting.
• If the tool detects issues and can apply mitigations, the user receives a post‑reboot notification; the scan’s results are recorded to the Windows Event Log for inspection.

What runs under the hood​

The scheduled test leverages the long‑standing Windows Memory Diagnostic utility (mdsched.exe). That tool supports several test profiles — typically Basic, Standard, and Extended — and is designed to run outside the full Windows session so driver and OS activity cannot mask hardware faults. Microsoft’s proactive flow chooses a quick/default pass intended to be completed rapidly (≈ five minutes on many systems), rather than the Extended tests that can take much longer. Results are written to Event Viewer under MemoryDiagnostics‑Results so technicians can consume the artifacts during troubleshooting.

---

Verified specifications and limits​

• Availability: Rolling to Windows Insiders in the Dev and Beta channels via the cumulative packages identified as KB5067109 (Dev build 26220.6982 and Beta build 26120.6982).
• Runtime guidance: Microsoft describes the proactive triage pass as taking “five minutes or less on average.” Actual time will vary with installed RAM capacity and platform.
• Tool used: The scheduled action invokes Windows Memory Diagnostic (mdsched.exe).
• Logging: Diagnostic outcomes are expected to appear in Event Viewer (System log entries such as MemoryDiagnostics or MemoryDiagnostics‑Results), though community reports show occasional inconsistencies in logging behavior; some users have to search Event Viewer manually to find results. Treat Event Viewer as the canonical location for the record.
• Platform gating / exclusions in the initial flight:
• Not supported on Arm64 devices.
• Blocked when Administrator Protection is enabled.
• Blocked when BitLocker is active but Secure Boot is not present.
• Microsoft is intentionally triggering the prompt for all bugcheck codes during this early flight to gather telemetry and later refine which crash signatures correlate with memory corruption.

---

Why Microsoft is doing this — practical rationale​

The logic behind Proactive Memory Diagnostics is straightforward: a fast, low‑friction triage step reduces the time between a crash and an initial hardware check. For many consumers and small support desks, telling a user to “run a memory test” is a non‑starter — they either don’t know about mdsched, or they avoid it because it interrupts work. Surfacing a one‑click option immediately after a crash can:

• Reduce time‑to‑diagnosis for failing DIMMs or memory controller issues.
• Capture diagnostic artifacts close to the failure event, helping RMAs and helpdesk workflows.
• Lower the barrier for non‑technical users to perform a sensible first triage action before deeper interventions.

This is framed as a triage capability, not a full forensic replacement for tools like MemTest86. The proactive scan is optimized for speed and discoverability, not exhaustive fault‑coverage.

---

Strengths: what this gets right​

• Low friction: The one‑click scheduling model removes the most common friction point — knowing what to run and when. For casual users, that’s the main reason diagnostic steps are skipped.
• Native tooling: Using the built‑in Windows Memory Diagnostic ensures wide availability and consistent logging semantics, avoiding the risk of third‑party or unsigned boot tools.
• Telemetry‑driven targeting: Microsoft’s plan to start broad and refine the triggers using crash telemetry is reasonable; it helps avoid prematurely constraining the signal set and allows the team to reduce noisy prompts over time.
• Support value: For helpdesk and RMA workflows, getting a quick, timestamped memory test after a crash provides a useful piece of evidence early in the investigation.

---

Risks, unknowns, and practical limits​

• Limited coverage vs. specialized tools: A quick pre‑boot pass is inherently less comprehensive than vendor stress tests or bootable tools like MemTest86. MemTest86 documentation and practical guides show that a thorough memtest can take hours to days depending on RAM capacity and number of passes; for intermittent faults, multiple passes across extended time are often required. In short: a five‑minute scan can catch obvious, persistent faults but won’t reliably detect subtle intermittent errors.
• Vague “mitigations” wording: Microsoft’s messaging promises that “if a memory issue is found and mitigated, you will see a notification post‑reboot,” but the early notes do not enumerate exactly what automatic mitigations may be applied. One plausible mitigation is blacklisting bad page frames or ranges, but the company has not published exhaustive behavior for every failure mode — administrators should treat any automatic mitigation as an interim stability fix, not a permanent cure. This remains an area that requires clarification.
• False reassurance: A negative result from the quick scan could lull users into believing RAM is healthy when intermittent or load‑dependent faults simply escaped the short pass. The proactive flow should be treated as a prompt for deeper investigation when crashes persist.
• Noisy prompts in early flight: Because Microsoft is initially triggering the prompt on all bugcheck codes to gather telemetry, many users will receive suggestions for crashes unrelated to memory. That will likely generate noise and user fatigue until triggers are refined.
• Enterprise management and telemetry concerns: Enterprises will ask for Group Policy/Intune controls to suppress or mandate behavior, and for transparency about what telemetry is collected when a proactive memory diagnostic is scheduled or run. At present, Microsoft’s public notes do not list enterprise controls for this preview flight. IT teams should exercise caution deploying preview packages across managed endpoints until management knobs are available.
• Logging inconsistency reports: Community troubleshooting threads show some users not seeing MemoryDiagnostics‑Results entries consistently in Event Viewer after running mdsched. That inconsistency needs investigation and documentation because Event Viewer is the canonical place support teams will look for evidence.

---

How to use this feature and what users should do next​

If you’re a Windows Insider and see the “Quick memory scan” prompt, consider the following practical approach.

• If the crash was a one‑off and you don’t need immediate uptime, accept the scan to eliminate an obvious hardware cause. The scheduled pre‑boot pass is usually short (≈ five minutes on average), but expect runtime to scale with RAM.
• After the reboot, check for a post‑boot notification. If the diagnostic found issues, collect any evidence (screenshot of the notification) and check Event Viewer for MemoryDiagnostics entries. If results aren’t visible, use a targeted Event Viewer query for MemoryDiagnostics‑Results to find the record.
• If the quick test reports errors:
• Reseat the DIMMs and verify slot population.
• Update UEFI/BIOS and chipset drivers.
• Run extended memory tests (either the Extended mode of Windows Memory Diagnostic or a multi‑pass MemTest86 session) to confirm and isolate failing modules.
• If errors persist across slots, gather RMA paperwork and vendor diagnostics.
• If the quick test reports no errors but crashes continue:
• Don’t assume memory is fault‑free; run extended multi‑pass tests and examine minidumps (WinDbg or BlueScreenView) to correlate crash stacks.
• Consider other culprits: drivers, firmware, power delivery, XMP/EXPO memory profiles, undervolting or ECO power modes. XMP/EXPO-style one‑click memory speed profiles are a frequent source of intermittent instability on consumer hardware, and undervolting or aggressive ECO modes can destabilize the memory controller.

---

A short how‑to: manually run and review Windows Memory Diagnostic​

• Run the tool:
• Open Start, type mdsched.exe and press Enter.
• Choose “Restart now and check for problems” or “Check for problems the next time I start my computer.”
• After the test completes and Windows boots, open Event Viewer:
• Press Win+R, type eventvwr.msc and press Enter.
• Under Windows Logs → System, filter by the source MemoryDiagnostics‑Results or search for MemoryDiagnostics entries.
• If the Event Viewer entry is missing, some community reports suggest re‑running the search or using the wevtutil query command to enumerate entries — results may sometimes be logged differently depending on configuration. If no results appear at all, use bootable MemTest86 for a follow‑up.

---

For IT admins and power users: what to watch for​

• Management controls: ask Microsoft for Group Policy or Intune settings to disable the prompt, force an organizational default, or limit the test depth. The absence of such controls in the preview is a blocker for many managed fleets.
• Telemetry and privacy: administrators should want details on what telemetry is emitted when the prompt triggers and what crash data is associated with scheduled scans. Microsoft’s initial targeting strategy (all bugchecks) will produce broad telemetry that the company intends to refine, but enterprises should still request explicit telemetry documentation.
• Boot windows: scheduling pre‑boot diagnostics increases reboot time; mission‑critical systems that expect near‑instant reboots should have a policy to opt out of automatic scheduling or limit tests to maintenance windows.
• Logging and evidence: verify that MemoryDiagnostics‑Results entries land where your helpdesk expects; inconsistent logging can complicate RMAs and escalation. If Event Viewer results are not reliable, buildplaybooks to capture screenshots and to preserve minidumps and system logs immediately after the event.

---

How this compares to MemTest86 and other third‑party tools​

• Coverage and depth: MemTest86 and other vendor stress tools are designed for extended, exhaustive testing and can run multiple, customizable passes across the entire address space. Real‑world guidance for MemTest86 shows a single pass can take from tens of minutes to multiple hours depending on RAM size and system performance; multiple passes are recommended to catch intermittent faults. The Windows Memory Diagnostic’s quick pass is not intended to replace these longer tests.
• Convenience vs. assurance: Proactive Memory Diagnostics trades depth for accessibility. That’s a reasonable trade if the goal is to increase first‑pass triage among mainstream users, but power users and technicians should still run extended vendor tools for warranty‑level evidence.

---

What Microsoft should clarify next​

• Precisely define what “mitigate” means when a memory issue is detected — automatic page avoidance, BCD modifications, or merely guidance to the user.
• Publish enterprise controls (Group Policy/Intune) for behavior — including opt‑out, forced runs, or specifying test depth.
• Document where logs and Event IDs will appear, and publish any APIs or diagnostic hooks helpdesks can use.
• Narrow triggers properly and publish the refined crash‑signature mapping so users only see the prompt when memory corruption is a plausible root cause.

---

Final assessment​

Proactive Memory Diagnostics is a pragmatic, well‑scoped improvement: small, incremental, and likely to help a meaningful number of users and support workflows by reducing friction for a sensible, built‑in triage step. Its strengths are immediacy, native tooling, and the potential to accelerate hardware diagnoses that otherwise drag on. At the same time, it carries important limits: the short pre‑boot pass cannot and should not be treated as a definitive test for intermittent faults, the “mitigation” semantics are underspecified, and the initial “all bugcheck” trigger strategy will produce noise until telemetry proves out. Enterprises will require management controls and telemetry transparency before adopting preview packages widely.
For consumers and home users, the new prompt is a welcome nudge: accept it when you’ve just experienced a BSOD and prefer to quickly check whether memory is a likely suspect. If the scan finds nothing and crashes persist, escalate to extended testing with MemTest86 or vendor diagnostics and investigate firmware, driver, or power delivery causes — particularly if you use XMP/EXPO profiles, aggressive overclocking, or ECO/undervolting modes, which commonly introduce subtle instability.
This isn’t a headline‑grabbing feature, but it’s an example of pragmatic reliability engineering — a useful quality‑of‑life improvement that reduces the friction between problem and diagnosis. The real test will be whether Microsoft refines triggers, documents mitigation behaviors, and provides enterprise management controls as the feature graduates from Insider flighting to general availability.

---

Source: Club386 Windows 11 adds Proactive Memory Diagnostics to detect RAM-related crashes | Club386