I'm asking this question because I was having memory problems (BSODs, MemTest errors), which seem to have stopped after I switched the faulty stick from SLOT3 to SLOT4 (as labeled in my motherboard).

Does Windows tend to use the SLOT1 first, and then SLOT2, SLOT3, SLOT4, etc. according to how the motherboard decides to map the memory? For example, if I have 4 sticks of 2GB each, and I'm not using more than 2GB of RAM at a given moment (say I'm just staring at my desktop, or listening to music), do the other 3 sticks remain inactive while Windows only uses the first stick (SLOT1)?

  • 3
    Your guess would mean the hardware was failing to take advantage of its dual-channel memory controller to get twice the bandwidth for sequential access to a big array, for example. (Or for anything at all if only SLOT1 was in use). That's why HW does fine-grained interleaving. – Peter Cordes Jan 25 at 21:04
  • 20
    It's much more likely the stick just wasn't fully seated, and swapping sticks fixed that issue. – Joel Coehoorn Jan 25 at 22:56
  • I'd just like to add that Windows 10 already does something to mitigate "bad" ram. My current PC has had issues booting, seemingly due to ram, and different configurations of my 32Gb resulted in up to 16Gb (2 sticks) being marked as "hardware reserved" in Task Manager, and left me with 16Gb usable. Be sure to check Task Manager and see if this is happening to you. – Andrakis Jan 27 at 5:16
  • @Andrakis I just opened task manager and it shows 40.9 MB as hardware reserved, which is basically nothing compared to the 8 GB I currently have. Also, I doubt those 40.9 MB are due to bad RAM, since I tested the RAM (after reseating) in MemTest and it showed no errors. Could it be that Windows somehow "detected" those 40.9 MB as being "faulty" at the moment it had a BSOD, and then kept it even after the problem was fixed? Or is it just a normal feature of my old motherboard (no integrated GPU tho)? – user3670722 Jan 27 at 6:12
  • No, that amount is fine. Windows will reserve some for hardware, that is normal. The problem is when several gigabytes is marked as reserved. In my case I had 16Gb, the 2 bad 8Gb sticks, marked as hardware reserved. This helped narrow down which sticks were bad, as I swapped them around until the issue went away. I think it's just a good idea to check that too (and yours is fine.) – Andrakis Jan 28 at 14:33

It doesn't work that way. The OS doesn't even know about these numbers.

The motherboard (bios) organizes the strips into 1 or more blocks of memory that are handed over to the OS. The ordering isn't necessarily in the sequence of the slot-numbers.. It is possible to SLOT4 strip of RAM will actually hold address 0 and that the highest address is at the end of the strip in SLOT2.
Also (multi-channel RAM) it is possible that slots are used in pair (or even triplets) with them memory used interleaved: odd memory rows coming from SLOT1 and even rows from SLOT2.

And to make it even more complicated. Any modern OS uses virtual memory. How this virtual memory space is allocated on top of the physical memory is mostly handled by the MMU (Memory Management Unit) which is part of the hardware (CPU and/or Northbridge chip depending on which particular CPU we are talking about). How the MMU shuffles memory around to present it to the OS can vary a lot.

To further complicate matters Windows will spread its usage over the entire RAM space. Uses the lowest part for the OS and interrupts, but drivers and other hardware related stuff (like video-buffers) typically get allocated at the end of the RAM space with programs somewhere in the middle.

TL:DR: There is no general rule determining how a RAM slot eventually gets used by the OS. The numbers on the motherboard are just there to tell the user in what order the SLOTS must be filled. They don't mean anything to the OS.

On any modern OS (not just Windows) you can't have the OS avoid part of the physical RAM in order to work around the bad spot. (Like physical hard-disks do by mapping out the bad blocks.) You will have to physically remove the bad RAM stick or avoid putting a good stick in a bad slot.
And working out which stick or slot is the bad one can be a major problem as you can't really tell from the outside if you have a bad stick or a bad slot.
The only way to test that is to try the sticks, one at a time, in a known good motherboard.

  • So according to what you said about the ordering of the addresses being random, I was probably mistaken by thinking the stick in SLOT3 was the faulty one. I came to that conclusion after matching the failing addresses (as reported on MemTest) to the DMI data shown in MemTest (all of the failing addresses matched SLOT3). – user3670722 Jan 25 at 11:38
  • But what I still don't understand is, why did the errors disappear after I took out the RAM and put it back? I remember finding exactly 50 errors before reseating them, after about 4 hours of testing/3 passes. But after I reseated all of them, I tested them individually (one by one for 3 passes each), and them I tested them all together, also for 3 passes. Took me almost 12 hours of testing but NO ERRORS. Were the errors being caused because of bad seating on the slot and/or dust? I remember one of the sticks being VERY dusty for some reason. – user3670722 Jan 25 at 11:39
  • 11
    On any modern OS (not just Windows) you can't have the OS avoid part of the physical RAM in order to work around the bad spot Not true; if you know the physical address of a bad bit (e.g. from memtest86+), you can boot Linux with an option that has a list of bad addresses, or something like that. (How to blacklist a correct bad RAM sector according to MemTest86+ error indication?). Older docs document a badram= kernel command-line (aka boo) option: Automatically memtest and then boot – Peter Cordes Jan 25 at 21:06
  • 2
    Virtual memory is fully controlled by the OS: it sets up the page tables, makes any changes to them when needed, and in general can exactly map virtual and physical addresses one to another. So the shuffling of memory space by the MMU is irrelevant here. – Ruslan Jan 26 at 8:01
  • 1
    @PeterCordes I know this can be done with Linux and my statement "Any modern OS" isn't factually correct, but it is not something the average user should ever do. The badram feature in Linux is more like a last ditch attempt to keep a server in operation until the replacement RAM has arrived. Servers also usually have ECC RAM which makes the RamTest method of determining what to map out far more reliable. I really can't recommend to do this with a consumer motherboard and without the additional backing of ECC RAM. – Tonny Jan 26 at 12:41

Most likely the act of removing and reinserting the DIMM fixed the problem, not the swap of places.

DIMM contacts carry frequencies in the GHz range, where really strange things happen. It is not random that contacts are often gold plated. "Reseating" a DIMM will move the point of contact by fractions of a millimeter and may easily move a contact's quality from "just not good enough" to "just good enough"

  • 2
    It would be easy enough to test -- move the DIMM back to its previous position and see if the problem re-appears. If it doesn't, that suggests that the reinsertion was the fix, not the swap. – Jeremy Friesner Jan 27 at 1:22
  • @JeremyFriesner Even better: Swap them around, so that the same positions are occupied by the same sizes as original, but different specimens. This helps with a tolerance-high-low issue. – Eugen Rieck Jan 27 at 5:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.