Tweet
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?
-
-
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 -
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 VMwareComment
-
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
Comment