Announcement

Collapse
No announcement yet.

BIT stops working or has BSOD

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

  • BIT stops working or has BSOD

    I have several Windows Vista machines where BIT stops running every day. One thing that I have noticed on the machines is that the hard drive is practically full because of the BurnInTest test folder. I believe that BIT is supposed to remove this folder or at least maintain it. How can I correct this error and is it possible to run BIT on Vista continuously?

  • #2
    We have had a few reports of this just in the last week. It does seem like something has changed in regards to Vista SP1, a Windows update and/or the recent build of BurnInTest.

    1) Have you only had this problem recently?
    2) Which Version of BurnInTest are you using, e.g. 5.3.1014 and when did you upgrade to this build?
    3) Which Operating System are are you using, e.g. Vista Business SP1 and when did you upgrade to this Operating System/Service Pack?
    4) How far into the test does the problem occur (e.g. 8 hours)?
    5) The Disk test should delete the files after a test, and then re-test the disk, however if the software stops before this happens then this will not happen. How full are the disks when the software stops (it would be interesting to understand if this may be causing the problem, or is just a consequence of the problem)?
    6) Does this problem occur if you exclude the disk test?


    This is a Software error. The software error could occur in BurnInTest, a library BurnInTest uses (like DirectX), a device driver or the Windows Operating System. In some cases a hardware error can cause a software problem (like faulty RAM). I would say that in most cases it is BurnInTest exercising a Device driver with a bug.
    Can you get the software error information, such as:
    - The address related to this problem, eg 0x00412345. If this information is not available from a link from the "BurnInTest has stopped working" error window (or you don't see this window) then you can normally get this information from the Windows Application event log. In XP (other operating systems will be similar) the Application event log is here:
    Start-> right click "My Computer" and select Manage, double click "Event Viewer" on the left hand side of the window, double click "Application" and find the event of type "Error" around the time the problem occurred. This will contain information like:
    "Faulting application bit.exe, version 5.0.1003.0, faulting module bit.exe, version 5.0.1003.0, fault address 0x00412345."

    7) Can you send us this information from a few of your systems?

    In regards to the BSOD. What information is displayed on the BSOD, for example is there a system component show (like abc.sys device driver) and a crash address (e.g. 0x41234567)?

    9) Are you running in a virtual environment (like VMWare)?

    Also, if you send us an email I will send you a debug version of BurnInTest that may provide additional information. Email us at:
    help [at] passmark [dot] com

    Thanks.

    Regards,
    Ian

    Comment


    • #3
      Below are the responses to your questions...

      1) No, this has been happening for a while, but I got tired of dealing with it just recently.
      2) 5.3.10011
      3) Vista Business, original install
      4) Tests will typically run 1-1.5 days before fail.
      5) Typically there is 1-2GB left empty on a 160GB HDD when it fails. Usually there are 140GB of temp BIT files.
      6) I have never tested it without the disk test. I imagine it would work, but I will change it and see what result I receive.
      7) Faulting application bit.exe, version 5.3.1011.0, time stamp 0x46ee241c, faulting module ntdll.dll, version 6.0.6000.16386, time stamp 0x4549bdc9, exception code 0xc0000005, fault offset 0x00069ee8, process id 0x4ec, application start time 0x01c8b0600d3b6e7f.

      Here are two of the BSOD dumps

      0: kd> !analyze -v
      ************************************************** *****************************
      * *
      * Bugcheck Analysis *
      * *
      ************************************************** *****************************
      MEMORY_MANAGEMENT (1a)
      # Any other values for parameter 1 must be individually examined.
      Arguments:
      Arg1: 00041287, The subtype of the bugcheck.
      Arg2: 00000000
      Arg3: 00000000
      Arg4: 00000000
      Debugging Details:
      ------------------


      BUGCHECK_STR: 0x1a_41287
      CUSTOMER_CRASH_COUNT: 1
      DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
      PROCESS_NAME: scheduler_proxy
      CURRENT_IRQL: 0
      TRAP_FRAME: 82f9c824 -- (.trap 0xffffffff82f9c824)
      ErrCode = 00000000
      eax=a0dd4480 ebx=83c00000 ecx=00000000 edx=00000000 esi=82f9c8ac edi=00000000
      eip=81c2cdf4 esp=82f9c898 ebp=82f9caa8 iopl=0 nv up ei pl nz ac pe cy
      cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010217
      nt!MiFreeWsleList+0x1f2:
      81c2cdf4 8b07 mov eax,dword ptr [edi] ds:0023:00000000=????????
      Resetting default scope
      LAST_CONTROL_TRANSFER: from 81c8fb74 to 81ca9ef2
      STACK_TEXT:
      82f9c80c 81c8fb74 00000000 00000000 00000000 nt!MmAccessFault+0x106
      82f9c80c 81c2cdf4 00000000 00000000 00000000 nt!KiTrap0E+0xdc
      82f9caa8 81cb6b8f a0dd4480 82f9cb58 a0dd4480 nt!MiFreeWsleList+0x1f2
      82f9cc34 81cb64a1 a0dd4480 00000001 82f9cc78 nt!MiAgeWorkingSet+0x40d
      82f9cc90 81cb02a0 00000002 82f9ccb0 00000001 nt!MiProcessWorkingSets+0x1c2
      82f9ccd8 81cafe94 00000000 84374828 00000000 nt!MmWorkingSetManager+0x3a3
      82f9cd7c 81e254b2 00000000 82f97680 00000000 nt!KeBalanceSetManager+0x12a
      82f9cdc0 81c9155e 81cafd6a 00000000 00000000 nt!PspSystemThreadStartup+0x9d
      00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

      STACK_COMMAND: kb
      FOLLOWUP_IP:
      nt!KiTrap0E+dc
      81c8fb74 85c0 test eax,eax
      SYMBOL_STACK_INDEX: 1
      SYMBOL_NAME: nt!KiTrap0E+dc
      FOLLOWUP_NAME: MachineOwner
      MODULE_NAME: nt
      IMAGE_NAME: ntkrpamp.exe
      DEBUG_FLR_IMAGE_TIMESTAMP: 46d4cc7a
      FAILURE_BUCKET_ID: 0x1a_41287_nt!KiTrap0E+dc
      BUCKET_ID: 0x1a_41287_nt!KiTrap0E+dc
      Followup: MachineOwner
      ---------

      Another one.....

      0: kd> !analyze -v
      ************************************************** *****************************
      * *
      * Bugcheck Analysis *
      * *
      ************************************************** *****************************
      IRQL_NOT_LESS_OR_EQUAL (a)
      An attempt was made to access a pageable (or completely invalid) address at an
      interrupt request level (IRQL) that is too high. This is usually
      caused by drivers using improper addresses.
      If a kernel debugger is available get the stack backtrace.
      Arguments:
      Arg1: ffffffef, memory referenced
      Arg2: 00000002, IRQL
      Arg3: 00000000, bitfield :
      bit 0 : value 0 = read operation, 1 = write operation
      bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
      Arg4: 81cc5813, address which referenced memory
      Debugging Details:
      ------------------


      READ_ADDRESS: GetPointerFromAddress: unable to read from 81d315ac
      Unable to read MiSystemVaType memory at 81d117c0
      ffffffef
      CURRENT_IRQL: 2
      FAULTING_IP:
      nt!CcAcquireByteRangeForWrite+384
      81cc5813 66813ffd02 cmp word ptr [edi],2FDh
      CUSTOMER_CRASH_COUNT: 1
      DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
      BUGCHECK_STR: 0xA
      PROCESS_NAME: System
      TRAP_FRAME: 82404af4 -- (.trap 0xffffffff82404af4)
      ErrCode = 00000000
      eax=85d081a8 ebx=85d08198 ecx=ffffffff edx=00000000 esi=82404c30 edi=ffffffef
      eip=81cc5813 esp=82404b68 ebp=82404bf8 iopl=0 nv up ei pl nz na po nc
      cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202
      nt!CcAcquireByteRangeForWrite+0x384:
      81cc5813 66813ffd02 cmp word ptr [edi],2FDh ds:0023:ffffffef=????
      Resetting default scope
      LAST_CONTROL_TRANSFER: from 81cc5813 to 81c8fd44
      STACK_TEXT:
      82404af4 81cc5813 badb0d00 00000000 00000000 nt!KiTrap0E+0x2ac
      82404bf8 81cc50fc 85d08198 00000000 00000000 nt!CcAcquireByteRangeForWrite+0x384
      82404c98 81c244e4 85b7337c 00000000 00000001 nt!CcFlushCache+0x33e
      82404cec 81cbc311 85d08198 82404d10 00000000 nt!CcWriteBehind+0x155
      82404d44 81c78f84 84374380 00000000 8436da48 nt!CcWorkerThread+0x1bd
      82404d7c 81e254b2 84374380 8240f680 00000000 nt!ExpWorkerThread+0xfd
      82404dc0 81c9155e 81c78e87 00000000 00000000 nt!PspSystemThreadStartup+0x9d
      00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

      STACK_COMMAND: kb
      FOLLOWUP_IP:
      nt!CcAcquireByteRangeForWrite+384
      81cc5813 66813ffd02 cmp word ptr [edi],2FDh
      SYMBOL_STACK_INDEX: 1
      SYMBOL_NAME: nt!CcAcquireByteRangeForWrite+384
      FOLLOWUP_NAME: MachineOwner
      MODULE_NAME: nt
      IMAGE_NAME: ntkrpamp.exe
      DEBUG_FLR_IMAGE_TIMESTAMP: 46d4cc7a
      FAILURE_BUCKET_ID: 0xA_nt!CcAcquireByteRangeForWrite+384
      BUCKET_ID: 0xA_nt!CcAcquireByteRangeForWrite+384
      Followup: MachineOwner
      ---------

      9) No VMware

      Comment


      • #4
        Hello,

        Thanks for your post. It is very useful.

        Based on the information I believe there are 2 different problems shown:
        1) BurnInTest stops working 1-1.5 days into a test. The error code is Access Violation in ntdll.dll at offset 0x00069ee8. This is a software crash in the Windows. I have found that this problem has been reported to Microsoft for BurnInTest and so I have retrieved a couple of Minidumps from Microsoft. Analysis of the Minidump shows that this is a hardware error:

        EXCEPTION_DOESNOT_MATCH_CODE: This indicates a hardware error.
        Instruction at 77509ee8 does not read/write to 02240ffc

        So, essentially it would appear that BurnInTest is exercising a hardware component with a fault. I would reduce your test set to a minimum to try and identify which system component is faulty.

        2) The BSOD shows a Vista device driver fault.

        Essentially it would appear that BurnInTest is exercising a Vista Device driver with a fault. I would reduce your test set to a minimum to try and identify which system component is faulty.

        Regards,
        Ian

        Comment

        Working...
        X