PassMark Software


No announcement yet.

Memtest86 Test 10 freezing with Xeon CPU

  • Filter
  • Time
  • Show
Clear All
new posts

  • Memtest86 Test 10 freezing with Xeon CPU

    Hi all,
    I'm having some issues with pro 7.5 . I am getting a freeze on test 10 the second it starts. The PC is 2012/2013 using an early uefi bios (Lenovo ThinkStation D30). It has a Xeon and ecc memory

    However, if I go into 4.3.7 non uefi the test passes easily.

    Any thoughts? (Please check screenshots).

    Cheers Michael

    Edit: I should clarify in regards to the screenshot of 7.5 with a 15 minute timestamp that it had been running for 15 mins doing tests 1-9 up until it froze at the start of 10.
    Last edited by ironhorse; 07-06-2018, 12:34 PM.

  • #2
    Same question was sent via EMail and already answered.


    • #3
      True. I posted this before I got an answer though. I would be interested to see if others have experienced this. I'm still trying to find a solution.


      • #4
        If anyone is following this - I found a version of 7.3 that is running the test. PC is using a C600 chipset.


        • #5
          Might be the same as this issue,


          • #6
            We found the issue.

            The problem is in fact not a system fault but rather a fault with the latest build as v7.3 works with no issue. Keith from PassMark was very helpful in helping me find the issue and said that it will be addressed in version 8.

            So, what is happening is the screen is not updating, yet the test seems to be running in the background.

            It seems that the issue is in regards to memory used by video. We found that by altering the memory range to: Lower Address Limit: 0x100000000 Upper Address limit: 0x480000000 that the computer will allow the test to run correctly.



            • #7
              That's not totally correct. We think it is totally a fault with the machine. Likely a BIOS bug in the memory map. And not a problem with MemTest86. The workaround was not to test some of the RAM that the BIOS claimed was free RAM.

              As the screen updates were effected by the firmware bug and not the actual RAM testing, likely some bit of RAM related to the video card that should've been reserved as in use by BIOS wasn't reserved.

              What we have put in place is a work around to not test small memory ranges in test #10. But it is a bit of a hack. The problem could also occur in other tests, but with a lower probability.


              • #8
                I do understand that the issue is likely the map and understand what the work around is doing.

                Though what puzzles me is that the behavior has only exhibited itself after v7.3. Therefore I'd argue that means somewhere, something has either been changed or something else has gone wrong in the later builds which I would believe is always a possibility when dealing with such a large range of hardware and bioses.


                • #9
                  Or it was just random. Sometimes (due to the timing, or the values written) writing to the effected memory range caused a problem and other times it didn't.