No announcement yet.

Lpt1 test

  • Filter
  • Time
  • Show
Clear All
new posts

  • Lpt1 test

    Hello, I'am working for an Industrial PC manufacturer. We stress tests all our PC's series with this program. We have all the versions until 5.x.
    Except for the 8.1 builds, all the others until the latest 9.xx can't be used to test the LPT ports in any case. Always LPT port does not found.
    Only the 8.1 is able to find the loopback correctly and start the tests.
    Please, fix it asap. Have you never tested this function?
    Thanks in advance.

    Please, add one simple function how permits to build an iso [linux or WINPE based] how start only the BURNINTEST interface with the registration already accepted.
    Do you know the Macrium reflect backup solutions? From this interface you can choose the PE builds or Linux and this proggy produce an iso who is very smaller and super easy to create.

    Thanks in advance

  • #2
    all the others until the latest 9.xx can't be used
    V10.1 is actually the latest release.

    I don't think we have any working hardware with a LPT port anymore. They have all died of old age.

    LPT ports were made redundant 20 years ago by USB. So you are correct, we haven't tested the parallel port test for a while. But on the other hand we haven't changed the code for this test for at least 10 years either. So V10 should behave the same as V6.

    Microsoft never properly supported the parallel port for data communications. (i.e. the never shipped a device driver for it and their driver was limited to printer control, without any data input). So it might be a driver issue.

    We'll have a look around and see if one of our vintage systems can still boot up.


    • #3
      There are a few things that can stop the parallel port test from starting correctly, if using Windows 11 and the 22H2 update then the "Core isolation" virtualised security can prevent the device driver required from loading, in this case "Core isolation" should be turned off (we are looking into why this is happening).

      If using WinPE then the parallel port usually has to be enabled.

      There was also a case where the port wouldn't be initialised by BurnInTest correctly the first time if the test wasn't selected at start up (in this case the test would start correctly on a second attempt), which should be fixed in this build.


      • #4
        Hi again,
        We test our Panel PC's [different vendors, chipsets, etc] with many OS: from Windows 7 to Windows 10 LTSC and 10 Pro [any builds]. No Windows 11.
        I'am 100% sure that any BurnInStress settings related to the LPT is setted correctly. the program is unable to find the loopback always except when we install the 8.1 that is the only and one version that is able to test the parallel ports alwats.
        Never I have found a 9x or 10x release that can test the parallel ports.
        Industrial PC's motherboards mount COM's serials and LPT ports as standard. I know that LPT is obsolete but these mainboards are not obsolete. 4,6,8,10 gen Intel chipsets.
        Please, can you try to fix this issue? it's a shame that we are not able to complete a 13h stress test why this device can't be tested.
        I don't know what you have changed but it's true.
        Believe me: we test at least 400/500 pc's x months and we know how stress them.
        Thanks in advance


        • #5
          Could you please try the new build from my last post, if the parallel test is not working then please launch in debug mode and send us a copy of the logs after trying to run the test twice.


          • #6
            Hi, I also meet the same problem.
            OS version is 22H2 + Burnintest v10.2 the parallel port address always show 0, but use 21H2 OS to run parallel port test can get address normal.
            Could you tell me what is causing it?
            Or how can I do for this problem?


            • #7
              Microsoft broke their device driver signing in 22H2, initially we had to get it resigned by Microsoft which turns out was also broken so that the newly signed driver only worked in that one specific revision of 22H2 (436).

              We have now had our driver resigned again (the current debug build should have the latest driver) which should be working for all revisions of 22H2 and there should be a new public release soon.