# Bad RAM, one shared DLL, and badmemorylist

Published 2026-08-14 · Windows, BSOD, RAM, MemTest86, bcdedit · https://home.tigran.manukyan.dev/notes/bad-ram-badmemorylist.html

**TL;DR:** Random Windows blue screens with no WHEA errors came from one bad chip on non-ECC DDR4. Identical ILLEGAL_INSTRUCTION crashes in one shared DLL across processes pointed to a bad physical page, MemTest86 confirmed it, and `bcdedit /set {badmemory} badmemorylist` fenced the pages off.

Two months of random blue screens, each with a different stop code: corrupt PTEs, critical process died, list entry corruption, page faults. Plus a few hard resets with no bugcheck at all. No WHEA errors anywhere.

## Two wrong assumptions

- **"No WHEA events, so it isn't RAM."** Consumer non-ECC memory has no error detection. A flipped bit never reaches WHEA.
- **"Crashes come in bursts, not a gradual curve, so it isn't hardware."** One bad cell causes a burst the moment a busy page lands on it, and goes quiet when the page moves.

## The tell

Three unrelated services crashed with `ILLEGAL_INSTRUCTION` at the same offset in the same shared DLL, and the DLL on disk hashed clean. Windows maps one physical copy of a DLL's code into every process. If that one frame is bad, every process decodes the same garbage. A reboot moved the page and the crashes stopped.

## Confirming it

Windows Memory Diagnostic found errors within the first pass. MemTest86 found 3,278 errors over 4 passes, even at a slow stock speed. Only 12% came from the row-hammer test, so it wasn't a borderline timing issue. 148 bad addresses fell into 16 pages in three clusters, and always the same two bits. That's one chip.

## Fencing it off

Windows can refuse to use specific page frame numbers:

```
bcdedit /set {badmemory} badmemorylist 0x5EF3E0 0x5EF3E1 ...
bcdedit /enum {badmemory}
```

I padded each cluster to a 16-page block, 48 pages in all, which costs nothing you'd notice. Two things to know:

- `/set` replaces the whole list. To add pages later, repeat all the old ones.
- Write down where the clusters are. If a later crash lands outside them, the chip is getting worse and the list isn't enough. Mine did, two months later, so a new stick is on the list.