Running Windows with defective RAM

Is it possible to run Windows (7, x64) with a defective RAM module? More precisely, is there some way to tell Windows not to allocate a known bad address or block of addresses?

For Linux, there is BadRAM. Is there an existing implementation for Windows? Is that even possible with Windows' kernel (NT 6.1)? Maybe a kernel mode driver?

Bob, there's three parts to your question. I'll address one at a time.

Running Windows with bad memory

It is indeed possible to run Windows 7 with a defective module. Depending on the location of the bad sectors and where the module sits in your DIMM banks, Windows 7 will run like there's nothing as long as it doesn't try to touch the bad portions of the memory. So, ideally you'd move the defective module as far away as possible from bank 0. Naturally, if this is your only module, you are out of luck.

Blocking bad memory sectors in Windows

On x86 (32 and 64 bits) operating systems, memory is managed by the kernel. As you mention, BadMem is able to block bad memory sectors in Linux. It works by instructing the kernel to lock those memory addresses you specified. This effectively stops Linux from ever addressing those addresses when allocating (and deallocating) memory. But in order to do this, BadMem needs to patch the kernel. BadMem is nothing more than a kernel patch that you configure before applying.

Now, you don't have that ability on Windows. You cannot patch the kernel. Developing a kernel mode driver won't do you any good either, since the Windows kernel will never let your driver take precedence over its memory management architecture (understandably so).

For this reason, you cannot instruct windows in any way to not use certain memory addresses. The only way would be for Microsoft to patch the kernel for your case specifically. Unlikely.

The spreading of bad memory addresses

There are not many reasons why a memory module may contain bad addresses. Ultimately it all boils down to an error in the production line, assuming it didn't sustain damage before getting into your computer. Contrary to hard drives there's no movable parts in memory modules, as you well know. So, bad sectors don't tend to spread as is the case with hard drive sectors.

However, memory test software isn't foolproof. It's possible (and common) for it to pass certain addresses that are in fact bad. So bad memory may give the impression of "spreading" as more and more addresses are revealed to be bad. For this reason tools like BadMem reveal their weakness, because naturally they can only handle those addresses you instruct them to.

It's unlikely that anyone can conduct a thorough test of a memory module and identify all bad memory addresses, then lock them and end up with a "good" memory module. The easiest thing to do is to consider a module with bad addresses as a defective module throughout and consequently not to be trusted.

What this means is that, as much as BadMem is an attractive proposition, it in fact isn't a solution to the problem of bad memory. More likely then not you'll still end up with an operating system that tries to read a bad sector and crashes with a stop error. A bad module is a bad module is a bad module.

The Windows BCD (Boot Configuration Data) actually has a {badmemory} object. It seems memory addresses that are "predicted to fail" by ECC memory will be listed here, and not used by the operating system.

The {badmemory} object accepts a BadMemoryList (BCD type 0x1700000a) element, which is a list of integers that can be entered as hex, separated by spaces. I guess it would be possible to manually insert bad memory addresses as found by memtest86 to this element - but I have not tested this. Apparently, it accepts 'page frame numbers, which is the actual address divided by 4096. Unfortunately, these addresses/PFNs may not match those reported by memory diagnostics. Manual editing can be done with Visual BCD Editor.

In any case, faulty memory sticks should be replaced as indicated by the other answers. This is merely a note on a possible way to work around the issue (temporarily?).

I had trouble RAM in a tablet with SoC. Memory is welded or integrated into the SoC and cannot be replaced.

I am in Argentina and the seller is in China, and the shipping costs and time, it makes no sense to send in warranty.

I managed a few hits.

The key to passing the damaged memory parameters are:

1. addresses in memtest86 match addresses used in Windows.
2. must mark full pages of 4KBytes.
3. in memtest 0x10000000 corresponds to 0x10000 in Windows
4. in memtest 0x00001000 corresponds to 0x1 in Windows
5. means: The page number in windows removes the last 3 memtest hexadecimal numbers.
6. means that: windows eliminates zeros in the left.
7. consider 5 and 6, to avoid errors in the page numbers.
8. the correct statement is: bcdedit /set {badmemory} badmemorylist 0xB7 0xB8 0xB9 0xBA to errors in memtest from 0x000B7000 to 0x000BAFFF. Note that you can not put a range of memories, but all pages one by one
9. cannot add pages, all pages should be marked in the same command. If a new page, adds overwrites older. I managed to add 4096 pages in a only command. I haven't tried it more.
10. bcdedit /enum {badmemory}, shows the list of marked pages.
11. bcdedit /set badmemoryaccess no prevent the marked pages are used
12. it is necessary to reboot after marking pages and remove access.

Windows BCD has {badmemorylist} and {badmemoryaccess} objects. You should set the first ({badmemorylist}) to bad memory pages separated by spaces (eg. bcdedit /set badmemorylist 1499543 1434007) and the second ({badmemoryaccess}) to No (bcdedit /set badmemoryaccess No)

Bear in mind that memory page size in windows is usually 4KB

Tested in windows 7 and it works well

You can test your settings with Rammap util (by Sysinternals)

PS i've got that info from "Windows Internals Book" chapter 10

As far as i'm aware, the only way to do this is using the BurnMem command which can artificially limit the amount of RAM windows uses.