Announcement

Collapse
No announcement yet.

Burn-in test configuration

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Burn-in test configuration

    We are having classic hardware vs software discussion on our project and I need a test configuration that will independantly verify our hardware. I'm testing it using Windows XP on an Intel Atom platform, 1GB RAM, Intel 80GB solid state drive. We use Windows Embedded Standard for the final product

    I'm using Burn-in Test 6.0 Professional with the following tests set: CPU, RAM, 2D Graphics, Disks, Sound, Network and USB.

    Problem is, we get Blue Screen errors intermittently with our software (running on WES), but Burn-in test runs just fine. I'm concerned that we are not testing all that we could be.

    Any suggestions appreciated.

  • #2
    There is no single cause for a blue screen, it can be hardware problems. But simple device driver bugs can also easily cause a BSOD.

    Often the text displayed on the blue screen can give some good hints as to the cause. In some cases directly identifying the driver with the bug. How consistent the text is, can also give some hints. Getting various different types of BSOD can indicate a RAM failure. Where as a consistent fault is more likely to be software.

    Comment


    • #3
      Help!!

      Understood...and in most cases to date we've used the BSOD data to identify driver issues. We've also used Burn-in test to confirm repeatable hardware errors. We are at the stage now where we are seeing intermittent failures and the info from the crash dumps is suggesting a hardware issue.

      Is there someone at Passmark that could help us put together a test that would help us confirm one way or another whether we have a software or hardware issue?

      Comment


      • #4
        There is no one magic wand test that will identify all possible software and hardware issues.

        You need to at least have a theory about what is wrong, before trying to devise a test to verify the theory.

        e.g. If you think it is bad RAM, then there are a number of options for proving and fault and fixing it.

        But there is a couple of things that might help narrow it down.
        - Does the problem happen on several machines, or just one machine?
        - How often does it happen?
        - What is happening when the problem happens, what provokes it?
        - Does it happen with a different O/S? e.g. Linux. This can be a big help is ruling our driver bugs

        Comment

        Working...
        X