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.
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.
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.
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?).
memtest86 Pro (not Free) can produce the correct blacklist commands for you in its report. Other answers describe the process for doing so manually.
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:
0x10000000 corresponds to 0x10000 in Windows0x00001000 corresponds to 0x1 in Windowsbcdedit /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 onebcdedit /enum {badmemory}, shows the list of marked pages.bcdedit /set badmemoryaccess no prevent the marked pages are used
/ and the command for it to work, so instead of bcdedit / enum {badmemory} it will be bcdedit /enum {badmemory} same for the others
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
Look at this util: https://github.com/prsyahmi/BadMemory
It's very easy to use and supports blocking of address ranges. And you can use full address received from MemTest86 without removing last three digits.
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.
maxmem, since apparently burnmem doesn't limit the max physical address while maxmem does. The Vista and 7 equivalent would be truncatememory. While this is a possible solution, is there a more precise method for cases where the defective memory is in the middle or beginning of the address space and blocking everything after it is not desired?
CAUTION!!! Windows may fail to boot, be ready to rebuild the BCD. For that case use the Command Promt in Advanced Startup Options. I dont know why it wont boot anymore, seems to happen randomly or if u put in too many Adresses into badmemorylist.
bootrec /rebuild bcd
bcdedit /export c:\bcdbackup
attrib c:\boot\bcd -h -r -s
ren c:\boot\bcd bcd.old
bootrec /rebuild bcd
Heres a C++ command prompt Programm that gets a continous memory adress list in a .txt file ready for bcdedit /set badmemorylist or bcdedit /set {badmemory} badmemorylist (didn't work on Win7 for me)
Use bcdedit /set badmemoryaccess 0 to deny access.
You can check with EasyBCD in View Settings -> Detailed. After a restart with check with Rammap if the Physical Address Space vanished.
#include <cstdlib>
#include <iostream>
#include <fstream>
//converts hex into base10
unsigned long convertHexToIntBase10(char* inputHex)
{
unsigned long hexValue = std::strtoul(inputHex, 0, 16);
return hexValue;
}
int main(int argc, char* argv[])
{
if(argc < 3){
std::cerr << "Usage: MemoryPageListHex [Low Memory Adress] [High Memory Adress] in 4k Pages i.e. MemoryPageListHex 1bae50 1bb0e7 for 0x1bae50148 to 0x1bb0e7fe8" << std::endl;
return 0;
}
auto lowAdr = convertHexToIntBase10(argv[1]);
auto highAdr = convertHexToIntBase10(argv[2]);
std::ofstream myfile;
myfile.open ("MemoryAdress4k.txt");
for (auto i=lowAdr; i<highAdr; i++){
myfile << std::hex << "0x" << i << " ";
}
myfile.close();
return 0;
}
Yes. There are boot parameter to control the amount of memory that windows can use. You can only remove from the end of the memory space though. See this msdn article to control boot parameters. The parameters of interest are truncatememory and removememory.
You could try this feature in Windows 7, but I am not sure which chip it will effect, or if it skims the same amount off of each one. I'll have to look around to find that out.
If replacement isn't possible, if you run Linux on the metal and run Windows paravirtualized in a Virtual Machine with something like VirtualBox, you can get the best of both worlds. Boot a Xen kernel up with the argument memtest, the Linux kernel will mark the sectors as bad and make it such that a virutalized guest does not have access to them,
Specifies the number of
memtestpasses to be performed. Each pass selects another test pattern from a given set of patterns. Memtest fills the memory with this pattern, validate memory contents and reserves bad memory regions that are detected.
It's called by providing the argument memtest on the boot. You'll have to do it with whatever kernel runs in dom0 (hypervisor).
memtest= [KNL,X86,ARM,PPC] Enable memtest
Format: <integer>
default : 0 <disable>
You can check out the documentation here.
