Announcement

**David (PassMark)** · Apr-03-2023, 12:08 AM

As per the badmemorylist details on this page. MemTest86 Pro (v9 or later) supports automatic generation of badmemorylist command strings from detected errors in the HTML report, that can pasted directly in the Command Prompt without needing to manually calculate page numbers by hand.

We don't have a description for doing it by hand. But I remember that it wasn't trivial, was very poorly documented and may well not work anymore anyway (since Win10 build 2004, when Microsoft broke it). Likely it would take us several hours to work out if what you are doing is correct or not.

However I also came across another project Badmemory which claims to have a device driver solution that does work (sometimes). We've never tested this solution however and it seems to have it's own code signing issues.

**Haroldimos** · Apr-04-2023, 12:21 AM

Thank you for responding to my post!

I have done more research and I believe I have figured out how to manually enter the page frame numbers correctly.

The following sources have useful information on how to correctly convert memory addresses reported by memtest86 into the page frame numbers used in bcdedit:
https://www.memtest86.com/blacklist-ram-badram-badmemorylist.html
https://thecomputerperson.wordpress....am-in-windows/
https://www.xf.is/2018/06/22/blackli...es-in-windows/

Example 4 from my other post is the only format that would blacklist the correct memory range I listed in my post, but trying to blacklist that entire memory range would need thousands of page frame numbers needing to be entered into bcdedit and might be too many to work. Thankfully the entire memory range listed in my post was not in error; only a few memory addresses actually had errors. I figured out how to manually retrieve all the individual memory addresses with errors, instead of trying to use the entire address range. Each page frame number is composed of many individual memory addresses totaling 4KB of memory in size. I only needed to use two page frame numbers to blacklist the individual memory addresses that I had errors in.

Here is my guide on how to manually get the list of page frame numbers that needs to be blacklisted:

Memtest86 free version that I use in this guide can be downloaded here:
https://www.memtest86.com/download.htm

Here is a short video describing how to use memtest86:
https://www.memtest86.com/tech_creating-window.html

Here is a more detailed guide on diagnosing errors and how memtest86 works:
https://www.youtube.com/watch?v=F4iopcL5vxo

The html test results and the text log file mentioned in the guide are located on the removable drive that memtest86 is installed on, they are in the directory: Drive\EFI\BOOT\

How to find the individual memory addresses in error (instead of a range) using memtest86:
Every time memtest86 runs a test, there is an option to save the test results as an html file, but this doesn't list every individual memory address in error, it only lists a range with the lowest and highest addresses in error, and also the last ten errors reported. By default memtest86 also creates a text log file in the same directory as the html test results every time it runs. This text log file contains every individual memory address that had errors, but the addresses are spread out throughout the very long text log file. Every line of this text log file that contains a memory error address will have the phrase [MEM ERROR - Data] in that line. After opening the text log file in notepad you can either click the edit menu and then click find, or press Ctrl+F, this will open the find menu to search notepad. Enter [MEM ERROR - Data] in the find window and click find next, this will let you quickly find all the individual memory addresses that had errors in the test. Continue clicking find next to find each memory address that had errors until you reach the end of the text log file. Each line of the log file will only contain a single memory address which will be located after the word Address: , the memory address listed here will not include the typical prefix of 0x before the address. Ether copy and paste or type out the addresses with errors into a separate text file and save them. Some of the same addresses may repeat throughout the log, you only need to write down each individual address once (don't write multiple copies of the same identical address). Make sure the text log file used to do this is from a test done with the same ram configuration in the same dimm slots, removing/changing the ram sticks or the slots they are in could change the memory addresses errors are reported in. Following the steps in this paragraph will give you a list of each individual address that had errors in the test; this list of individual addresses with errors could be significantly smaller than the total number of addresses in-between your lowest and highest reported addresses with errors in the html test result file, that is because there may be addresses that have no errors in-between your lowest and highest reported error addresses (this is good because the fewer individual addresses that need to be blacklisted, the easier it will be to enter their page frame numbers into bcdedit).

The difference between individual memory addresses reported by memtest86 and page frame numbers used by bcdedit:
Memtest86 will report memory addresses in a format that looks like this: 0x48D80C30 (without the 0x prefix if using the guide in my previous paragraph). Each page frame number used by bcdedit contains many of these individual memory addresses reported by memtest86. For example, to block the individual memory address 0x48D80C30, you will need to use the page frame number 0x48D80, this page frame number will block all the individual memory addresses in-between 0x48D80000, and 0x48D80FFF. Each page frame number will always include the exact amount of individual memory addresses needed to occupy four kilobytes of memory.

To convert the individual memory addresses reported by memtest86 into the page frame numbers used by bcdedit, follow these steps:
Step 1 - If using the memtest86 text log file to get individual addresses, add the prefix 0x to the beginning of each individual address. If you are not using the text log file or your addresses already start with the prefix 0x, skip this step (do not add the prefix 0x a second time if it is already there). For example, this step would convert 48D80C30 into 0x48D80C30 (if you were already starting with 0x48D80C30, you would skip this step).

Step 2 - If the individual memory address has any zeros that come after the prefix 0x, but before another number other than zero, remove them. If there are no zeros that come after the prefix 0x, but before another number other than zero, than skip this step. For example, this step would convert 0x00001000 into 0x1000, but would not change 0x10000000.

Step 3 - Remove the last three digits (regardless of whether or not they include any zeros). For example, in this step, 0x1000 becomes 0x1, 0x10000000 becomes 0x10000, 0x48D80C30 becomes 0x48D80.

Step 4 - Repeat steps 1 through 3 for each individual memory address. This step may turn individual memory addresses that were different, into the same page frame number (this is good because the fewer page frame numbers the easier it will be to enter them into bcdedit). Don't write/keep multiple copies of the same identical page frame number. For example, following these 4 steps would convert both 0x48D80C30, and 0x48D807E2 into the same page frame number (0x48D80).

Tip: If you have a lot of individual memory addresses with errors, it may be faster to use these four steps to convert them directly from the log text file the first time you write them down, instead of writing them, then converting them, then writing them again.

For example, here are some individual memory addresses from memtest86 before and after following the previous four steps to convert them into page frame numbers used by bcdedit:
individual memory address ------- page frame number
48D80C30 ---------------------------- 0x48D80
0x48D80C30 ------------------------- 0x48D80
0x48D807E2 ------------------------- 0x48D80
0x08D807E2 ------------------------- 0x8D80
0x00D8A7E2 ------------------------- 0xD8A
00001000 ----------------------------- 0x1
0x00001000 -------------------------- 0x1
0x10000000 -------------------------- 0x10000
0x48D89C30 ------------------------- 0x48D89

My personal results after following the steps in this guide:
After finding the individual memory addresses using the memtest86 text log file, and then converting them into page frame numbers using the previous four steps, there were only two page frame numbers I had to blacklist with bcdedit. My memory address error range in the memtest86 html test result was lowest error address 0x46D80234 (1133mb), highest error address 0x48D80C30 (1165mb). It would have taken thousands of page frame numbers to fully cover that whole range, but using this guide I was able to find there were only two page frame numbers that I really needed to block. Of course this is only my experience, you may find significantly more page frame numbers that need to be blacklisted. If you have a relatively small amount of individual memory addresses with errors, or many of the addresses are close enough together to be in the same page frame numbers, and those individual memory addresses in error are consistent in multiple tests, there is a good chance following this guide may also help you fix your errors.

Blacklisting your page frame numbers:
The following commands all require administrator command prompt to work. To open the command prompt as administrator, type cmd into the windows start menu, right click the command prompt and select run as administrator, and select yes if prompted to allow making changes to your device.

In administrator command prompt, run the following command:
bcdedit /set {badmemory} badmemorylist PFN1 PFN2 PFN3 ...
PFN=page frame number. For example, the page frame numbers I needed to blacklist were 0x46D80 and 0x48D80. The page frame numbers in your command will be different than mine, but for example, the command I used was: bcdedit /set {badmemory} badmemorylist 0x46D80 0x48D80. This command will add your page frame numbers to the badmemorylist (blacklist), but the badmemorylist is disabled by default. Before enabling the badmemorylist, make sure your page frame numbers have been entered correctly and successfully added to the list. If you have entered any page frame numbers incorrectly or want to delete the page frame numbers you have added to the badmemorylist, use the following command to delete them: bcdedit /deletevalue {badmemory} badmemorylist

In administrator command prompt, run the following command:
bcdedit /enum {badmemory}
This command will list all the page frame numbers you have successfully added to the badmemorylist section (if your page frame numbers aren't showing up here, make sure you have entered the previous command with the page frame numbers correctly).
The bcdedit /enum {badmemory} command will also show a section called badmemoryaccess that will either say yes or no. If you want the page frame numbers listed in the badmemorylist section to be blacklisted, the badmemoryaccess section should say no (this setting means there is no access to the bad memory you have listed).

In administrator command prompt, run the following command:
bcdedit /set {badmemory} badmemoryaccess no
This command will turn on blacklisting for the page frame numbers you have entered, and prevent Windows from accessing them.
This command can easily be reversed to stop blacklisting the page frame numbers you entered without having to delete the page frame numbers, just replace the no at the end of the command with yes like this: bcdedit /set {badmemory} badmemoryaccess yes

In administrator command prompt, run the following command again:
bcdedit /enum {badmemory}
Make sure that the badmemoryaccess section says no. Also make sure the badmemorylist section correctly lists all your page frame numbers. If anything is incorrect in these sections refer to the previous commands to fix it, if everything is correct, move on to the next step.

Restart your computer for the blacklist to take effect. If you change any of these commands after you restart, you will need to restart again for them to take effect (except for the bcdedit /enum {badmemory} command, this doesn't change any settings, it only lists the current settings).

Testing to confirm everything is working correctly:
There are two ways to test that everything is working correctly, the first is to open administrator command prompt, and enter the bcdedit /enum {badmemory} command again. Make sure that the badmemoryaccess section says no. Also make sure the badmemorylist section correctly lists all your page frame numbers. If anything is incorrect in these sections refer to the previous commands to fix it.

The second way to test that everything is working correctly is using rammap. It is a free tool by microsoft that can be downloaded here: https://learn.microsoft.com/en-us/sy...wnloads/rammap. Just download the program, extract the zip folder, open RAMMap.exe, and select yes if prompted to allow making changes to your device. The program doesn't need to install, it will just run. The way rammap is used to check if your blacklist is working isn't very intuitive. Once opened rammap will show different usage sections along the top bar, showing the amount of ram being used in kilobytes for each section. There is a section for bad ram, and you might expect this bad ram section to display your blacklisted ram, but on my computer this bad ram section is empty with no ram listed in it. Instead, the way I used rammap to confirm the blacklist changes, was through the total ram section. At the bottom of the total ram section, the largest number displays the total amount of ram accessible to Windows in kilobytes. Each page frame number takes up exactly 4 kilobytes. So for each page frame number you added to the blacklist, your total ram will be reduced by 4 kilobytes. For example, I only needed to blacklist 2 page frame numbers; 2 x 4 kilobytes = 8 kilobytes. After blacklisting my total ram was reduced by exactly 8 kilobytes just as predicted for my 2 page frame numbers. Just multiply the number of page frame numbers you blacklisted by 4 to get the exact number of kilobytes your total ram should be reduced by. If you blacklisted 3 page frame numbers, your total ram would be reduced by exactly 12 kilobytes, and so on. The blacklisted memory can quickly and easily be disabled and re-enabled without deleting the blacklisted page frame numbers from badmemorylist; This is useful to quickly confirm the correct change to the total kilobytes of ram accessible to windows before and after blacklisting. To disable the blacklist, use the command bcdedit /set {badmemory} badmemoryaccess yes and restart your computer, to re-enable the blacklist, use the command bcdedit /set {badmemory} badmemoryaccess no and restart your computer. This yes and no state of badmemoryaccess can quickly be checked with the bcdedit /enum {badmemory} command. You can use rammap in this method to test and confirm the correct amount of memory has actually been blacklisted.

Everything in this guide is working as described to the best of my knowledge as of April 3rd 2023, using Windows 10 Home version 22H2 OS build 19045.2728, MemTest86 Free version 10.3 build 1000, and RAMMap version 1.61

That's everything, thanks for reading my guide! This topic of manually blacklisting memory is very poorly documented. Hopefully this helps someone like me who was just trying to figure out how all this works and get their computer to stop crashing. Anyone can feel free to post this guide wherever they want, and feel free to modify or update it if anyone has better, more detailed, or more accurate information.

**David (PassMark)** · Apr-04-2023, 01:51 AM

Thanks for taking the time to document the process.

As there was some reports of Windows Memory Diagnostics overwriting the entire PFN list via scheduled tasks it would be interesting to come back in a couple of months a see if the settings stuck.

Testing on Win11 would also be interesting.

Most interesting of all would be to see if it fixed your BSOD?

**Haroldimos** · Apr-06-2023, 02:38 AM

Your Welcome, hopefully it helps someone!

I ran Windows Memory Diagnostic manually before I found out about memtest86. I have never seen Windows Memory Diagnostic run automatically as a scheduled task before, (it is obviously possible that I just didn't notice it if it did happen). I will try to remember to post a reply here in a couple months to confirm whether or not this happens to me, and if it does, whether or not it overwrites my PFN list.

If I tried to do a major Windows version update (like Windows 11), without being able to remove my faulty ram causing the errors (because it is soldered to my motherboard), it is possible the new Windows install could be corrupted because of the bad ram. This could be avoided by transferring my SSD into a different computer that is known to be working without hardware errors, before doing the Windows update, and then transferring my SSD back to my computer after the Windows update. My laptop also has BitLocker encryption on my SSD, so I would have to disable it before transferring my SSD. Also, I actually like Windows 10, and I don't currently have access to another working laptop that can accept my SSD. So I don't plan on updating to Windows 11, and likely will not be able to test this. Although, I do agree, it would be useful to confirm if this method of blacklisting PFNs still works in Windows 11. If anyone who reads this can confirm whether or not blacklisting PFNs with bcdedit still works in windows 11, please reply here with your results.

I have not had any BSOD errors since I blacklisted the PFNs I had errors in (although as of writing this it has only been 2 days since I blacklisted the PFNs). I will try to remember to reply here in a couple weeks to confirm whether or not I have had any new BSOD errors (before blacklisting my PFNs that had errors, I was getting 1 BSOD error every 2 days on average).

I will note that even though I haven't had any new BSOD errors, I have had some smaller errors such as certain drivers occasionally stopping working, most of these errors were not noticeable in use, I am only aware of them because I have been checking Windows Reliability Monitor (which can be found by typing view reliability history into the Windows start menu search bar). I believe these errors are caused by programs and drivers that were corrupted by my bad ram during updates that happened before I blacklisted my PFNs with errors.

I have used the System File Checker (SFC) tool, and the DISM tool in Windows to confirm that none of my system files are corrupt (I completed these tests with no errors) (Microsoft has a guide on how to use these tools here: https://support.microsoft.com/en-us/topic/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system-files-79aa86cb-ca52-166a-92a3-966e85d4094e#:~:text=The%20sfc%20%2Fscannow%20comm and%20will,the%20Windows%20operating%20system%20fo lder.)
I have also checked my SSD using the chkdsk command (it had no errors), and I have run a Windows security full scan and a Microsoft Defender offline scan to test for malicious software (no threats were found on my computer).
I believe the errors I am still having are caused by corrupted drivers, programs, and files that are not checked or repaired by the previous tools. I will likely have to manually update, replace, or repair any suspected drivers and programs until my errors stop. As I said before, most of these errors haven't been noticeable in use, and none of them have caused a BSOD or unexpected shutdown.

I have also found another program to help test ram, it is called MemTest and is made by HCi Design. This program does not give detailed error information like MemTest86, but it is still very useful because it can be run inside Windows. With windows running the unused ram that is available for testing will be smaller, but because Windows is running, the PFNs you have blacklisted will be inaccessible to Windows. This means you can directly test for memory errors that could happen with Windows running and your PFN list actively blacklisted. You can even use this in combination with RAMMap's physical pages tab to confirm that MemTest (by HCi Design) is testing the memory address ranges where you have PFNs blacklisted (RAMMap is not live, to refresh it press F5). (RAMMap can be downloaded here: https://learn.microsoft.com/en-us/sy...wnloads/rammap). I used MemTest by HCi Decign in this way to confirm that I had successfully blacklisted the correct PFNs. (MemTest by HCi Design showed no memory errors when I tested this way with my PFN list blacklisted).

**David (PassMark)** · Apr-06-2023, 04:48 AM

I believe the errors I am still having are caused by corrupted drivers, programs

Maybe. Once installed, executable files shouldn't corrupted themselves on disk (at least not due to bad RAM). These files are basically read only once installed.

Bias, of course, but our Windows based BurnInTest software is a better choice for testing RAM in Windows.

**Haroldimos** · Apr-06-2023, 10:43 AM

"I believe these errors are caused by programs and drivers that were corrupted by my bad ram during updates that happened before I blacklisted my PFNs with errors."

I had ongoing BSOD errors caused by faulty ram for over a month before I blacklisted the PFNs with errors. I did windows updates, installed multiple programs, and updated several drivers during that time while my ram was having errors (I didn't know the errors were caused by bad ram at the time). Sorry if that wasn't clear, I meant that I believe the files were corrupted WHILE they were being installed and updated, not later on.

I was not aware that your BurnInTest software tested ram in windows like that (I had not looked into it before), I will have to give it a try, thanks.

**Haroldimos** · Apr-18-2023, 01:06 AM

It has been two weeks since I blacklisted my PFNs that had errors. I have NOT had a single BSOD, unexpected shutdown, or program crash since I blacklisted the PFNs.

(Before I blacklisted the PFNs that had errors, on average, I had one BSOD that would cause an unexpected shutdown every two days, and programs crashing at least once every day.)

I am posting this to confirm the method in my guide above, is currently working, and can be used to successfully blacklist bad PFNs.

**Haroldimos** · Jun-14-2023, 04:28 PM

This is a second update.

It has now been 2 months since I blacklisted my PFNs that had errors.

I still have NOT had a single BSOD, unexpected shutdown, or program crash since I blacklisted the PFNs.

(Before I blacklisted the PFNs that had errors, on average, I had one BSOD that would cause an unexpected shutdown every two days, and programs crashing at least once every day.)

Using the command bcdedit /enum {badmemory} , I can confirm that the PFNs are still successfully blacklisted, and that windows is still successfully blocking access to the bad memory.

I am posting this to confirm the method in my guide above, is currently working, and can be used to successfully blacklist bad PFNs.

**Kael** · Jul-08-2023, 05:18 PM

Thanks! My wife has a LENOVO with 4GB soldered RAM. BSOD every 15-20 min. I followed Haeoldimos's excellent instructions and her machine is now usable. I scripted a one liner to process the memtest86 (10.5 Pro) log file to extract the page numbers. The standard UNIX utilities grep, sed and sort are required. If you don't have those you can get a full UNIX-like shell by installing Git For Windows (https://gitforwindows.org/) which provided a BASH-shell in the start menu.

Here is the one-liner (use the actual name of your log file):

Code:

grep 'MEM ERROR' MemTest86-#########-######.log | sed 's/^.*Address: /0x/' | sed 's/...,.*//' | sort -u

In my case this yields:

Code:

0x3696E6
0x3696E7
0x36B6E6
0x36B6E7

I then put these in a file, on a thumbdrive and followed Haeoldimos's instructions above, using the pages identified i.e. :

Code:

bcdedit /set {badmemory} badmemorylist 0x3696E6 0x3696E7 0x36B6E6 0x36B6E7
bcdedit /set {badmemory} badmemoryaccess no

**Frestho** · Jul-13-2023, 04:36 PM

Haroldimos, I want to thank you for writing the most detailed guide I've seen on this issue. I made an account just to reply to this thread. Your guide is what helped me determine how to parse the error data to blacklist the correct page number.

I still have a small question though which is similar to what you asked in the first post. My lowest error address is 0x28C920060 and my highest is 0x28C9ABFA0. So I blacklisted the page number 28C9 and everything on my computer is so much smoother! Who knew that some kilobytes of bad RAM would not only cause crashes, but also significant performance issues? I have no idea how that works. Anyways, I was wondering how blacklisting 28C9 compares to blacklisting 28C92, 28C93, ..., 28C9A. Obviously I don't care about saving a few kilobytes of RAM, but for educational purposes I want to know which one is preferrable. I did 28C9 because it was much simpler to type and perhaps there's some errors below the detected lowest error and highest error as my test stopped midway due to how many errors there were!

**Kael** · Jul-19-2023, 07:03 PM

Frestho,
You haven't you haven't translated the addresses to pages correctly. Review Step 3 of Haroldimos's detailed instructions.
For instance, the page of your lowest address is 28C920 not 28C9. You remove the last 3 digits of the address to find the page.

**Haroldimos** · Aug-14-2023, 11:07 PM

Kael and Frestho,

Thank you both very much for the kind words, I am glad my guide actually helped someone to fix their computer.

Kael,
Thanks for writing that code, it should make finding all the addresses much faster. I am not familiar with how this code works. Does it find the addresses with errors, add the 0x prefix, and remove the last 3 digits? Can it also remove any possible zeros before the first non-zero number at thee beginning of the address, or would that step have to be done manually? Answering that question, and briefly explaining what steps the code does or does not do could be helpful for people who are not familiar with the code. Either way, this should be significantly faster and easier than doing everything manually. Thank You.

Frestho,
Kael is correct, you have not translated your memory addresses to page frame numbers correctly. Your memory address range would translate into over 100 page frame numbers starting with 0x28C920 and ending with 0x28C9AB. These page frame numbers cannot be abbreviated or shortened, you must follow the steps in my guide to properly convert them. I am not sure if there is an upper limit for the maximum number of page frame numbers bcdedit can blacklist in one command, over 100 may be to many. Thankfully, it is unlikely that your entire memory address range needs to be blacklisted. The memory address range only tells you the highest and lowest addresses with errors, there will likely be multiple addresses in between the highest and lowest address that do not have any errors, and do not need to be blacklisted. You can use my guide to find only the memory addresses with errors, and then convert them to page frame numbers. I will copy and paste the relevant sections of my guide below.

Also, I have never experienced this, but if memtest86 cannot complete a whole test, you could try reducing the number of passes, or you could test only a specific address range in memtest86 (for example you could test only the memory addresses lower than your lowest error address, and then do a second test with only the addresses higher than your highest error address. Doing this should allow you to confirm there are no errors above your highest address, or below your lowest address, breaking the tests into sections like this could also help allow you to complete the test if it is crashing). Hopefully this helps you.

The html test results and the text log file mentioned in the guide are located on the removable drive that memtest86 is installed on, they are in the directory: Drive\EFI\BOOT\

How to find the individual memory addresses in error (instead of a range) using memtest86:
Every time memtest86 runs a test, there is an option to save the test results as an html file, but this doesn't list every individual memory address in error, it only lists a range with the lowest and highest addresses in error, and also the last ten errors reported. By default memtest86 also creates a text log file in the same directory as the html test results every time it runs. This text log file contains every individual memory address that had errors, but the addresses are spread out throughout the very long text log file. Every line of this text log file that contains a memory error address will have the phrase [MEM ERROR - Data] in that line. After opening the text log file in notepad you can either click the edit menu and then click find, or press Ctrl+F, this will open the find menu to search notepad. Enter [MEM ERROR - Data] in the find window and click find next, this will let you quickly find all the individual memory addresses that had errors in the test. Continue clicking find next to find each memory address that had errors until you reach the end of the text log file. Each line of the log file will only contain a single memory address which will be located after the word Address: , the memory address listed here will not include the typical prefix of 0x before the address. Ether copy and paste or type out the addresses with errors into a separate text file and save them. Some of the same addresses may repeat throughout the log, you only need to write down each individual address once (don't write multiple copies of the same identical address). Make sure the text log file used to do this is from a test done with the same ram configuration in the same dimm slots, removing/changing the ram sticks or the slots they are in could change the memory addresses errors are reported in. Following the steps in this paragraph will give you a list of each individual address that had errors in the test; this list of individual addresses with errors could be significantly smaller than the total number of addresses in-between your lowest and highest reported addresses with errors in the html test result file, that is because there may be addresses that have no errors in-between your lowest and highest reported error addresses (this is good because the fewer individual addresses that need to be blacklisted, the easier it will be to enter their page frame numbers into bcdedit).

The difference between individual memory addresses reported by memtest86 and page frame numbers used by bcdedit:
Memtest86 will report memory addresses in a format that looks like this: 0x48D80C30 (without the 0x prefix if using the guide in my previous paragraph). Each page frame number used by bcdedit contains many of these individual memory addresses reported by memtest86. For example, to block the individual memory address 0x48D80C30, you will need to use the page frame number 0x48D80, this page frame number will block all the individual memory addresses in-between 0x48D80000, and 0x48D80FFF. Each page frame number will always include the exact amount of individual memory addresses needed to occupy four kilobytes of memory.

To convert the individual memory addresses reported by memtest86 into the page frame numbers used by bcdedit, follow these steps:
Step 1 - If using the memtest86 text log file to get individual addresses, add the prefix 0x to the beginning of each individual address. If you are not using the text log file or your addresses already start with the prefix 0x, skip this step (do not add the prefix 0x a second time if it is already there). For example, this step would convert 48D80C30 into 0x48D80C30 (if you were already starting with 0x48D80C30, you would skip this step).

Step 2 - If the individual memory address has any zeros that come after the prefix 0x, but before another number other than zero, remove them. If there are no zeros that come after the prefix 0x, but before another number other than zero, than skip this step. For example, this step would convert 0x00001000 into 0x1000, but would not change 0x10000000.

Step 3 - Remove the last three digits (regardless of whether or not they include any zeros). For example, in this step, 0x1000 becomes 0x1, 0x10000000 becomes 0x10000, 0x48D80C30 becomes 0x48D80.

Step 4 - Repeat steps 1 through 3 for each individual memory address. This step may turn individual memory addresses that were different, into the same page frame number (this is good because the fewer page frame numbers the easier it will be to enter them into bcdedit). Don't write/keep multiple copies of the same identical page frame number. For example, following these 4 steps would convert both 0x48D80C30, and 0x48D807E2 into the same page frame number (0x48D80).

Tip: If you have a lot of individual memory addresses with errors, it may be faster to use these four steps to convert them directly from the log text file the first time you write them down, instead of writing them, then converting them, then writing them again.

For example, here are some individual memory addresses from memtest86 before and after following the previous four steps to convert them into page frame numbers used by bcdedit:
individual memory address ------- page frame number
48D80C30 ---------------------------- 0x48D80
0x48D80C30 ------------------------- 0x48D80
0x48D807E2 ------------------------- 0x48D80
0x08D807E2 ------------------------- 0x8D80
0x00D8A7E2 ------------------------- 0xD8A
00001000 ----------------------------- 0x1
0x00001000 -------------------------- 0x1
0x10000000 -------------------------- 0x10000
0x48D89C30 ------------------------- 0x48D89

My personal results after following the steps in this guide:
After finding the individual memory addresses using the memtest86 text log file, and then converting them into page frame numbers using the previous four steps, there were only two page frame numbers I had to blacklist with bcdedit. My memory address error range in the memtest86 html test result was lowest error address 0x46D80234 (1133mb), highest error address 0x48D80C30 (1165mb). It would have taken thousands of page frame numbers to fully cover that whole range, but using this guide I was able to find there were only two page frame numbers that I really needed to block. Of course this is only my experience, you may find significantly more page frame numbers that need to be blacklisted. If you have a relatively small amount of individual memory addresses with errors, or many of the addresses are close enough together to be in the same page frame numbers, and those individual memory addresses in error are consistent in multiple tests, there is a good chance following this guide may also help you fix your errors.

**Haroldimos** · Aug-15-2023, 07:42 AM

Frestho,

To correct the format of your page frame numbers, please refer to my previous message and the section of my guide that I copied and pasted into my previous message.

In my last message I suggested you could test the memory address range below your lowest error, and above your highest error, but I didn't explain how to do that. In order to test the correct memory address range you need to be able to count in hexadecimal. Counting in hexadecimal (the combination of letters and numbers that are used for memory addresses and page frame numbers) can be confusing, so I will explain it. I will also explain how to enter the address range into memtest86.

Why testing below your lowest error and above your highest error is helpful:
If you have any memory errors when using memtest86, it will give you a memory address range showing only the lowest address with an error, and the highest address with an error. It is very likely there are memory addresses in between those that have no errors and do not need to be blacklisted. My previous guide explains how to find only the individual addresses with errors, instead of a large address range. While less likely, it is also possible that errors reported by memtest86 could be caused by other components of your computer such as your CPU. Memtest86 has a video about diagnosing possible causes of errors here: https://www.youtube.com/watch?v=F4iopcL5vxo. Testing specific address ranges in memtest86 can help to confirm that a specific address range is functioning properly without errors. It can also help rule out other possible causes of errors such as CPU. If you are having trouble with memtest86 crashing or unable to complete a full test, testing only an address range (instead of all addresses in one test), could help memtest86 complete the test without crashing.

Counting in hexadecimal:
For the purpose of this explanation, there are two relevant number systems, decimal, and hexadecimal.

Explaining the decimal system may seem redundant and unnecessary, but this will help when explaining the hexadecimal system. Decimal is the number system taught in school that everyone uses in day to day life, there are 10 digits, in order the digits are as follows: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. When counting in decimal, after 9 comes 10 (the the single digit number becomes a double digit number with the 9 turning into a 0, and the number 1 carrying to the tens place to the left before it). After 10 comes 11 and so on with counting resuming in the ones place to the right and following the digits in order until 19 turns to 20 and so on.

Hexadecimal works in the same way as the decimal system, it just has more digits. Instead of the normal 10 digits in decimal (0-9), the hexadecimal system has 16 digits (0-F) including both numbers and letters. The letters are not any different from the numbers; they are not special or different like in algebra. The letters are simply used to extend the the amount of numbers and add more digits. The 16 digits of hexadecimal in order are as follows: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F. When counting in hexadecimal, after F comes 10 (the the single digit number becomes a double digit number with the F turning into a 0, and the number 1 carrying to the tens place to the left before it). After 10 comes 11 and so on with counting resuming in the ones place to the right and following the digits in order until 1F turns to 20 and so on.

Here is a list of all the numbers between 0 and 30 in hexadecimal (this is just an example to help understand how counting in hexadecimal works): 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 1A, 1B, 1C, 1D, 1E, 1F, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 2A, 2B, 2C, 2D, 2E, 2F, 30.

Using hexadecimal to get the memory address range below your lowest error, and above your highest error:
Now that I have explained the basics of counting in hexadecimal, you can use that to select a specific memory address range you want to test. You said your lowest error address is 0x28C920060 and your highest error address is 0x28C9ABFA0. If you wanted to test all addresses below your lowest error (to confirm those addresses have no errors) you would start with your lowest error address number. Because this is going to be used for testing page frame numbers which are essentially 4 kilobyte packets of memory address ranges, we can start by temporarily ignoring the last 3 digits of your lowest memory address, similarly to how you would convert it to a page frame number. This would convert your lowest error memory address from 0x28C920060 to 0x28C920. The next step is to simply count back one digit (subtract 1) to get the closest address that shouldn't have any errors. Remember to count in hexadecimal as described above. This would convert 0x28C920 to 0x28C91F. Finally we have to add back three digits to the end of the address to make it compatible with memtest86. Because this is going to be used for testing page frame numbers, we can ignore the original 3 digits we removed and add back three zeros (this is because all possible combinations of the the last three digits would still be the same page frame number). Doing this would convert 0x28C91F to 0x28C91F000.

To test all addresses below your lowest memory address with errors, we will start with the lowest possible memory address (0x0), and end with the closest memory address to your lowest address with errors (the address we just made, 0x28C91F000). So, when entering the address range you want to test into memtest86, in this example you would use 0x0 as the lowest address, and 0x28C91F000 as the highest address to test.

You would do the same process in reverse to test all the the addresses above your highest address in error. Start with your highest address in error, for your example it is 0x28C9ABFA0. Temporarily remove the last three digits as we did before. this converts 0x28C9ABFA0 to 0x28C9AB. Now we will count up one digit (add 1) to get the closest address that should be working above your highest error address. This will convert 0x28C9AB to 0x28C9AC. Finally we will add three zeros as we did before. This converts 0x28C9AC to 0x28C9AC000.

To test all addresses above your highest memory address with errors, we will start with the closest address that should be working above your highest error address (the address we just made, 0x28C9AC000), and end with the highest possible memory address (this will vary depending on how much memory you have in your computer, just use the default highest address in memtest86, it will automatically be filled in correctly, you can reset it to default to be sure it is correct). So, when entering the address range you want to test into memtest86, in this example you would use 0x28C9AC000 as the lowest address, and the memtest86 default as the highest address to test.

You can use these same methods to test between any range of memory addresses.

Entering the address ranges you want to test into memtest86:
In the config menu of memtest86, there is a tab for memory address range. Simply navigate to the address range tab and enter the lowest and highest address you want to be tested. There is a button to easily reset these values to the default lowest and highest possible addresses to test all memory addresses at once, so don't be afraid to change these values, they only change what memory address range you are testing.

Tip: you can also adjust the number of passes for each test in the test selection tab of the memtest86 config menu. This is helpful if you need to save time, or if you are having trouble completing a full test. The default is 4 passes, but you could lower this to 1 or 2 (I think the first pass is designed to be slightly faster and less thorough to quickly catch errors, so I would recommend at least 2 passes to be thorough) . More passes will be more thorough, less passes will be faster. It is likely unnecessary to do more than 4 passes in one test.

TLDR:
This is for testing in memtest86 NOT for entering page frame numbers into bcdedit.
This is a lot of information to process, so if you just want the address ranges to test, here they are:
To test all addresses below your lowest memory address error you provided: use 0x0 as the lowest address, and 0x28C91F000 as the highest address.
To test all addresses above your highest memory address error you provided: use 0x28C9AC000 as the lowest address, and the memtest86 default as the highest address.
These addresses can be entered into the memtest86 address range tab in the config menu.

The same as my previous guide, Anyone can feel free to post this guide wherever they want, and feel free to modify or update it if anyone has better, more detailed, or more accurate information.

Feel free to ask any questions. I will try to remember to check this post periodically to reply.
hopefully this helps!

**Frestho** · Aug-31-2023, 10:02 PM

Hi both, thanks for correcting me. I realized the issue quickly after I posted but I forgot to update my post. Thanks for the info nonetheless as it reassures me and helps future thread viewers.

I had another question: since my RAM was bad, and I installed Windows on this bad RAM, part of my operating system seems to be broken. It's hard to describe all the issues are they're a bunch of seemingly unrelated ones but I have three examples. One is the Wifi always says "No Internet" even though it actually does connect. So I can still use my browser and do 99% of activities, but sometimes there's an app that detects I have no Wifi (untrue) then refuses to connect, even though if it did try to connect it would go through. Second is that the Microsoft Store doesn't load and some apps appear to be broken. Third is that sometimes the whole screen is black except the taskbar, and I can try to click on various apps in the taskbar which "opens" them yet they don't display anything and I can't interact with them. This is fixed by a restart but is somewhat annoying that I have to do that.

Anyways, the point is I want to install Windows correctly so I don't face weird bugs like this which are super bizarre and impossible to resolve because they're deep OS issues. How can I install Windows while bad RAM is blacklisted? Since I need to have Windows's bcdedit to blacklist RAM, but while Windows is installing, I don't have Windows or bcdedit yet... lol.

Haroldimos, you wrote

I will note that even though I haven't had any new BSOD errors, I have had some smaller errors such as certain drivers occasionally stopping working, most of these errors were not noticeable in use, I am only aware of them because I have been checking Windows Reliability Monitor (which can be found by typing view reliability history into the Windows start menu search bar). I believe these errors are caused by programs and drivers that were corrupted by my bad ram during updates that happened before I blacklisted my PFNs with errors.

I have used the System File Checker (SFC) tool, and the DISM tool in Windows to confirm that none of my system files are corrupt (I completed these tests with no errors) (Microsoft has a guide on how to use these tools here: https://support.microsoft.com/en-us/topic/use-the-system-file-checker-tool-to-repair-missing-or-corrupted-system-files-79aa86cb-ca52-166a-92a3-966e85d4094e#:~:text=The%20sfc%20%2Fscannow%20comm and%20will,the%20Windows%20operating%20system%20fo lder.)
I have also checked my SSD using the chkdsk command (it had no errors), and I have run a Windows security full scan and a Microsoft Defender offline scan to test for malicious software (no threats were found on my computer).
I believe the errors I am still having are caused by corrupted drivers, programs, and files that are not checked or repaired by the previous tools. I will likely have to manually update, replace, or repair any suspected drivers and programs until my errors stop. As I said before, most of these errors haven't been noticeable in use, and none of them have caused a BSOD or unexpected shutdown.

and this is very similar to the issue I'm experiencing: random things are broken due to bad RAM during installation and updates of Windows. However, my issue seems to deal less directly with drivers, but drivers might be the cause. Were you able to find a solution to this?

Announcement

How to list page frame numbers to blacklist in bcdedit using a memory address range

How to list page frame numbers to blacklist in bcdedit using a memory address range

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment