Quick answer: the Windows Memory Diagnostic Tool is a built-in Windows tool for checking RAM for possible memory errors. Run it if a PC is repeatedly crashing, freezing, restarting unexpectedly, or showing blue screen errors. If it reports memory errors, treat the result seriously. If it reports no errors, do not assume RAM is definitely healthy. Continue troubleshooting if the symptoms persist.

If a Windows PC is crashing, freezing, or producing unexplained blue screens, Windows Memory Diagnostic is a reasonable first test because it is built in, easy to run, and can catch obvious RAM faults. But it is not the final word on memory health. Treat it as a quick triage tool: useful when it finds errors, less conclusive when it does not.

Although Microsoft’s Windows operating system is normally stable and reliable, it is still possible for a system to exhibit issues such as application crashes, freezing, file corruption, random reboots, or even the Blue Screen of Death (BSOD). When these types of problems occur, it is best to begin the troubleshooting process by scanning for malware and installing any available updates. If that fails to resolve the problem however, then the issue could be related to the system’s memory.

Fortunately, Windows 10 and Windows 11 contain a native tool that can help you to test for memory problems.

Use the Windows Memory Diagnostic Tool as a first-pass RAM check

The Windows Memory Diagnostic Tool is similar to third party memory checking tools such as Memtest86, but is native to the Windows operating system. It’s designed to run various diagnostic tests against a system’s memory in order to determine whether a problem exists.

Run the Windows Memory Diagnostic Tool before replacing hardware

There are a few two main ways that you can open Windows memory diagnostic tool. The easiest option is:

• entering the mdsched.exe command at the Windows Run prompt (WIN+R).

‘mdsched’ is name of the executable file used by the tool.

Another option is to:

• enter the word Control at the Windows Command prompt to open the legacy Control Panel.
• Next, type the word “memory” into the Control Panel’s search box.
• Finally, click on the Diagnose Your Computer’s Memory Problems link, found in the Windows Tools section, shown in Figure 1.

Choose when Windows should restart and test memory

When you launch the Memory Diagnostic Tool, you will be greeted with a splash screen, similar to the one that is shown in Figure 2. This screen appears because the tool cannot perform a memory test with the Windows operating system running. As such, the system must reboot.

The startup screen gives you a choice between rebooting now and waiting to check for problems the next time that you restart the computer. If you do choose to restart now, then be sure to save your work and close any open programs prior to rebooting.

Let the memory test complete unless you launched it by mistake

When the computer reboots, Windows will immediately begin running the memory diagnostic test, as shown in Figure 3. During the test, a progress bar will help you to track the test’s progress.

If you have initiated the test by accident, you can abort the testing process by pressing the Escape key. Generally speaking however, it is usually best to let the test complete.

Find Windows Memory Diagnostic Tool results in Event Viewer

When you run Windows Memory Diagnostics Tool, it will check your system for RAM issues and then reboot once the tests have been completed. Sometimes, the test will automatically display the test results after you login, but more often, you will have to open the Event Viewer. The results are displayed within the Windows Logs | System log. You can see an example of the Memory Diagnostics Tool results shown in Figure 3. If you want to see the results in a dedicated window, right click on the log entry and select the Event Properties command from the shortcut menu.

Check the ‘MemoryDiagnostics-Results’ event before drawing conclusions

Although the Windows Memory Diagnostic Tool generally does a good job of detecting memory problems, there may be situations in which problems exist, but are not immediately detected by the tool. In such situations, you may see a result stating, “No errors were detected”.

If you suspect that the machine contains memory issues that are not being reported, then you might consider running a more comprehensive memory test. Doing so is more time consuming than running a standard test, but it may find errors that might otherwise have been missed.

If you want to perform a different type of test, then start the diagnostic process in the usual manner. When the test begins, press the F1 key and you will be taken to the screen that is shown in Figure 4. This screen allows you to choose between running a Basic, Standard, or Extended test. You also have the ability to modify the cache settings and to increase or decrease the pass count.

Treat Windows Memory Diagnostic Tool errors as a serious signal

If the Windows Memory Diagnostic Tool reports that hardware problems were detected, then it does not automatically mean that your Random Access Memory (RAM) is physically defective. There are actually a few different possibilities that may account for the error.

Rule out bad RAM first

Although a “hardware problems were detected” message does not guarantee that there are issues with the system’s memory, bad RAM is quite common. A memory module within your system might have bad cells or failing circuitry.

Disable XMP, EXPO, or other memory overclocking

Sometimes, the tool can report that hardware problems were detected, even if the memory itself is fine. This type of error can stem from overclocking and is very common on systems that use DDR4 or DDR5 memory. If the memory has been overclocked using a tool such as Intel XMP or AMD EXPO, then a situation can occur in which the memory controller cannot reliably access the memory at the overclocked speeds, resulting in memory instability.

Consider CPU memory controller instability

Even if the memory has not been overclocked, instability tied to the CPU memory controller can mimic the symptoms of bad RAM.

Do not overlook motherboard or firmware problems

Although it is far less common than the other issues that have been discussed, a defective motherboard can cause a system to exhibit symptoms mimicking those of bad RAM. This can occur as a result of a motherboard being equipped with bad DIMM slots or a board that is experiencing voltage regulation problems. BIOS bugs can also sometimes cause a system to behave in a way that makes it appear that the memory has gone bad.

Test memory modules and DIMM slots separately

If the Windows Memory Diagnostic Tool is reporting hardware errors, then there are several steps that you can take to troubleshoot the process. First, try powering off the system and reseating the Dual In-line Memory Modules (DIMMs). It may be that the memory modules are loose, especially if the system has undergone recent upgrades.

If reseating the memory fails to resolve the issue, then try resetting the BIOS to its default values. You should also disable any overclocking tools, thereby allowing the memory to run at its native speed.

If you are still experiencing issues, you might attempt to test the memory modules one at a time. It may be that only a single module has gone bad. If however, you receive errors for each module that you test, then it may be that the DIMM slot on the motherboard has gone bad. You should retest the modules within a known good system.

Finally, if you are still having trouble diagnosing the issue, then try using a third party tool such as Memtest86 to confirm your results. A third party tool may provide you with additional information or it may be able to confirm that memory is actually good.

Use the Windows Memory Diagnostic Tool for triage, not final proof

Windows Memory Diagnostic is a good first check when a Windows PC starts crashing, freezing, or behaving unpredictably, but it should not be treated as a complete hardware validation tool. If it finds errors, act on them. If it finds nothing but the symptoms continue, keep investigating rather than assuming RAM is cleared. The safest default is to use it as triage but not a definitive answer.

Frequently asked questions

The post How to Use Windows Memory Diagnostic Tool and How Much You Can Trust the Result appeared first on Petri IT Knowledgebase.

If you want to stream local media, this free and open source media server is just as good as Plex. But if you rely on remote access or live TV, prepare to tinker.

---

Mirco Gerling: The Supermarket Team That Self-Destructed Trying to Help Everyone

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

 

"They tried to help, and finally, it... it self-destructed the team." - Mirco Gerling

 

The team was the supermarket of the organization. Cloud systems, versioning, developer machines, hardware — if another team needed infrastructure, this team built it. And when other teams asked, the answer was always the same: "We will try, we will try." Mirco watched what happened next play out in slow motion. The team escalated their overload to management. Management responded the way management often responds — sent in temporary help. The reinforcements solved problems quickly and left. But every system they built became permanent maintenance work for the original team. The pile grew. The team shrank. People left for other teams, or left the organization entirely. The escalation that was supposed to save them became the signal that broke them. As Mirco puts it: running to the higher level "sends a signal that self-organization or self-management does not work." Sometimes the help is the harm.

 

In this segment, we refer to the dynamic of team self-organization and how it can break down under pressure.

 

Self-reflection Question: When your team is overwhelmed, what does the act of escalating tell management about your ability to self-manage — and is that the signal you want to send?

Featured Book of the Week: The Kanban Maturity Model

In this episode, Mirco also recommends two books that shaped his thinking on process and estimation. The first is #NoEstimates by Vasco Duarte, which inspired Mirco to drop story-point estimation in some teams and simply count completed tickets per sprint. The second is the Kanban Maturity Model — a book Mirco uses to run workshops where teams discover their current level of process maturity. "The highest level says that you have a standardized process, and the result is always the same for the same type of work," he explains. Most teams start at level zero, but that's the point: knowing where you stand is the precondition for knowing where to go next.

 

[The Scrum Master Toolbox Podcast Recommends]

🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥

Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.

 

🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.

 

Buy Now on Amazon

 

[The Scrum Master Toolbox Podcast Recommends]

 

About Mirco Gerling

 

Mirco is an experienced Scrum Master in the public sector. With a strong IT background, he has spent 25 years developing software and driving agile transformations. Passionate about innovation and teamwork, Mirco brings expertise and dedication to every project.

 

You can link with Mirco Gerling on LinkedIn.

Download audio: https://traffic.libsyn.com/secure/scrummastertoolbox/20260714_Mirco_Gerling_Tue.mp3?dest-id=246429

Vibe coding, left alone on the dance floor without any steps, shimmy, or syncopation, lacks the rhythm it needs to be a productive part of the software application development lifecycle (SDLC).

This is why technology vendors have begun to apply additional context controls — along with human governance and clearer visibility services — to natural language programming. The vibes are just better.

A toolset for platform engineering & development teams 

As such, the agentic SDLC company Port introduced its Port AI Builder service on Tuesday, which the company believes has all the, ahem, right moves. The agentic SDLC platform and toolset for platform engineering and development teams combines domain expertise with context-aware development controls, natural language, and built-in human-in-the-loop review and approval. 

Co-founder and CEO of Port, Zohar Einy, tells The New Stack that his mission is to get away from the notion of “promoting agentic chaos or vibe coding slop” these days. Rather, Einy says, Port is all about “enabling context-aware development with domain expertise and governance” so that what teams build can actually run reliably. 

“The recklessness factor today isn’t building with AI — it’s not building with AI while your competitors do,” Einy says. “Port forces clarity through its Plan Mode function to drive versioned, audited, human-approved code. Junior engineers with Port have more oversight than senior engineers used to, so they stay accountable.”

In Plan Mode, the agentic service drafts a plan, asks clarifying questions, and waits for approval before building. When it does, plans are versioned and saved for traceability and governance.

Coding is no longer about syntax memorization

Illustrating just how software engineering has changed in the agentic era, Einy says that the real skill now is reading code and understanding design, not exhibiting “depthless skills in syntax memorization” or other more traditional coding abilities. 

“We stopped thinking quality assurance had to be manual. Now we benefit from AI validation — including services for architecture — made possible when agents have full-stack context, previous architecture decisions, coding patterns, service level agreements, and operational data.”

Port is context-aware; it reads the actual stack from an organization’s governance layer, including its team structures, so it builds from a point of organizational reality — not templates — to ensure that it’s hardened from day one. The platform’s Context Lake enables it to know each enterprise’s organizational context, tooling, and governance controls, so that agentic workflows are produced that fit the stack and processes and run reliably.

“Validation happens via human-in-the-loop review or AI agents that pressure-test the solution,” says Einy. “We stopped thinking quality assurance had to be manual. Now we benefit from AI validation — including services for architecture — made possible when agents have full-stack context, previous architecture decisions, coding patterns, service level agreements, and operational data.”

Einy highlights his firm’s existing Agentic SDLC Platform, which already provides the context lake, workflow orchestration, agent management, and governance that enterprise teams need to operationalize an AI-SDLC. 

On top of that foundation, the new AI Builder lets teams build and run production-grade agentic workflows, for use cases like autonomous resolution (e.g. when a developer raises a Jira ticket to track bugs, regression testing, cross-functional code dependencies and so on), or for AI cost management and engineering performance tracking.

Inspired by Claude, Cursor & Lovable

The port team cites Claude, Cursor, and the lesser-known AI-powered app builder Lovable as focal points of inspiration for developing its platform. The organization wants engineers to embrace the fact that prompt-driven development is moving from application code into platform engineering itself, a proposition made by Jim Mercer, program VP for software development and DevOps IDC.

“Once engineers can define agentic workflows in plain language and run them across the lifecycle, the real differentiator becomes context and governance at scale. Port’s agent-based SDLC capabilities reflect this shift,” said Mercer.

“Technical debt comes from bottlenecks and slow decisions, not from speed in the face of governance. Humans create debt when they’re overwhelmed. AI with oversight removes the bottleneck and keeps the judgment.” – Einy.

AI-assisted onboarding & open agnosticism

Port also offers AI-assisted onboarding, where purpose-built AI automates and simplifies setup and ongoing management while maintaining governance and operational consistency. The technology is described as open and agnostic; developers can build natively in Port or plug in existing agents, but all remain governed and visible in one place.

Questioned on whether the rapid cadence of vibe coding might lead teams to bypass traditional levels of specialized engineering governance and ultimately degrade software quality, creating technical debt cycles, Port CEO Einy remains resolute.

“Technical debt comes from bottlenecks and slow decisions, not from speed in the face of governance. Humans create debt when they’re overwhelmed. AI with oversight removes the bottleneck and keeps the judgment,” Einy confirms.

While talk of context lakes for agentic direction has been prevalent this year, there appears to be a more navigable path being laid out now. At the risk of too many boating analogies, we’re seeing more points on the compass now that governance and organizational context are driving versioned, audited, human-approved code. All we need now is to make sure the software shipping lanes stay open.

The post “Vibe coding slop”: Port’s CEO on the problem with ungoverned AI dev appeared first on The New Stack.

We spent the week at AI Engineer World’s Fair in San Francisco, on stage and on the floor. Here’s what we heard, and where we think it lands for anyone building with agents.

The SDLC is being rebuilt in public

This week at AIE felt like a synthesis of what’s been playing out in developer tools for the last few years, for anyone who’s been watching. The software development lifecycle is reshaping itself into an AI-native SDLC, and the industry is naming the new jobs and developer concerns that come with this rapid transformation.

The proof was in the track list: Evals, Context Engineering, Harness Engineering, Memory, Sandbox & Platform Engineering, Inference, plus a whole thread on “software factories.” Two years ago most of these phrases were far from being thought of as categories. Now each one is a discipline with its own sessions, its own vocabulary, and its own crop of companies on the expo floor built to solve that single problem.

So what were most talks about? A little bit less of “can agents and AI do this,” and more of “given this way of building, what decisions and trade offs do we need to think about?” Evals, loops, harnesses, context, memory, isolation, cost. None of this is brand-new, but it’s all getting a whole new level of mindshare, as developers work out the new shape of creating software with AI. Even the model labs spent much of their stage time on how you build with the model: the integration API, the harnesses, the ergonomics, rather than the model itself. 

The job we care most about: securing where agents run

Of all those emerging disciplines, sandboxing is the one that hit critical mass this year. There was a full track dedicated to sandbox and platform engineering, and the sessions inside it were still working out what a sandbox should even be: full VM, lightweight runtime, Kubernetes, something purpose-built. Talks focused on concerns such as running agentic sandboxes at scale and comparing isolation technologies head to head. 

This is the job Docker showed up to talk about, across three sessions.

Give agents more freedom by giving them less surface

Our EVP of engineering, Tushar Jain, gave the mainstage talk: “Unlock Agent Autonomy: The Runtime for AI-Native Systems.” The actors have changed – agents read and write whole codebases, spawn subagents, install dependencies, and call APIs across laptops, CI, cloud, and org boundaries, often unsupervised. Teams leaning into this shift are moving fast, but most organizations still won’t let agents run autonomously, not because the model isn’t capable, but because trust isn’t there yet. This thinking draws on a concept security researcher Simon Willison has written about, the “lethal trifecta”: any useful agent tends to end up with access to private data, exposure to untrusted content, and the ability to act in the outside world, all three, by design. No prompt or policy doc gets rid of that. The durable fix lives one layer down, at the runtime, which is where we spent the last decade: isolation, network policy, trusted images, credentials. Agents are just the next workload.

An agent doesn’t have to be malicious to be dangerous

Rowan Christmas, a staff product manager at Docker, made the risk concrete. In “YOLO Mode, Safely: microVM Sandboxes for Any Agent,” he ran a coding agent on his own laptop with nothing but read access, and no sandbox or unusual permissions. Within a few minutes it had pieced together a surprising amount about his online banking activity from what it could passively see. A destructive command like rm -rf is the obvious fear, but the mundane can bring risk: read access, plus untrusted content, plus the ability to act, is already enough to do damage. An agent doesn’t have to be malicious to expose you. It just has to be able to see. The alternative Rowan showed puts each session in its own Docker sandbox based on a microVM, with a boundary you define across filesystem, network, and tools. It can run Claude Code, Cursor, Codex, or whatever you’re driving.

Once an agent can install packages, run Docker, and reach the network, which describes most genuinely useful agents, a hardware boundary buys you something you can’t easily bolt on later. And where much of the scale conversation is cloud-first, built for fleets of agents running server-side, Docker’s approach starts first on the laptop the developer already uses, because that’s where most people actually run agents today. (We go deeper on the reasoning in “Why microVMs” and our comparison of sandboxing approaches, including what the isolation costs you, because it isn’t free.)

Nobody’s reviewing what your agents just installed

The third talk covered the tool layer. Jim Clark, a principal software engineer on our MCP team, spoke about “Who Approved That MCP Server? Governing the Tool Layer,” and opened with a line that got knowing laughs: “shadow MCP”. Developers install MCP servers faster than security can review them, and an unvetted server is a direct line to your data. That worry was all over the event, not just our session. Jim’s demo put every server behind one org-managed catalog, vetted, signed, default-deny on anything unapproved, with the policy enforced live on stage.

Where this leaves us

So how does it come together? An agent is only as trustworthy as the boundaries around it, and those boundaries live in three places: what it builds on, where it runs, and what it can reach. Miss any one of them and the other two won’t cover for you. A hardened image dependency is no help if the agent can still read your whole filesystem unsandboxed, and a locked-down sandbox is no help if the agent can call an unvetted MCP server straight out of it.

That was the case Docker made all week: harden what agents build on, isolate where they run, control what they can reach, and govern all three from one place. We think this is the part that has to be solved first, because it’s where AI-native developers will start building the apps of the future.

Further reading: 

• Docker Sandboxes run standalone (brew install docker/tap/sbx)
• Docker AI Governance ties sandbox and MCP policy into one console.
• MCP Catalog, Toolkit, and Gateway are in Docker Desktop today
• Docker Hardened Images are a drop-in change to your FROM line