Crash and reboot [Dump data included]

Hello,

I am new on this forum and english is not my native language.
I will do my best to be clear but pls be indulgent for languages errors and faults.Thanks.

Summary of the situation
Running an E4400 on P5B deluxe.
Everythink was Fine since 8 months.

Since several weeks, during "heavy" video encoding with various software ( Virtual Dub, Nero, TMPGe,c) computer crash and reboot time to time (from 2 or 3 crashes per day to one crash every 2 or 3 days)

I have suspected various things and already made the followings tests:
- TAT - 8 hours - OK
- memory test - 6 hours - no problems
- check SMART disk status - OK
- At the crash time, temperatures are low (40° for CO and C1) and voltage are OK (logged by speedfan every 3 secondes)

I read the events log and found messages which indicates that a crash dump has been done, found explanation how to install debugging tool and run it.

But I am totaly unable to understand that analyis. Pls could someboby have a look and tell me what is the cause of the problem. (I have approximatly 15 crash dump available. I analyse the 2 more recents and they look the same for me)

Here is the detail.

-----


Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINDOWS\Minidump\Mini112907-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: D:\DOCUMENTS\Doc Philippe\PC\DOWNLOAD Logiciels\Système\Windows\Symbols
Executable search path is:
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Windows XP Kernel Version 2600 (Service Pack 2) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055c700
Debug session time: Thu Nov 29 20:37:05.453 2007 (GMT+1)
System Uptime: 0 days 21:00:23.141
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Loading Kernel Symbols
......................................................................................................................................................................
Loading User Symbols
Loading unloaded module list
...............................................
ERROR: FindPlugIns 8007007b
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 96, {8a44e288, 8056375c, 80563720, 80575950}



Probably caused by : hardware ( nt!CmpFindNameInList+2e )

Followup: MachineOwner
---------

1: kd> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

INVALID_WORK_QUEUE_ITEM (96)
This message occurs when KeRemoveQueue removes a queue entry whose flink
or blink field is null. This is almost always called by code misusing
worker thread work items, but any queue misuse can cause this. The rule
is that an entry on a queue may only be inserted on the list once. When an
item is removed from a queue, it's flink field is set to NULL. This bugcheck
occurs when remove queue attempts to remove an entry, but the flink or blink
field is NULL. In order to debug this problem, you need to know the queue being
referenced.
In an attempt to help identify the guilty driver, this bugcheck assumes the
queue is a worker queue (ExWorkerQueue) and prints the worker routine as
parameter 4 below.
Arguments:
Arg1: 8a44e288, The address of the queue entry whose flink/blink field is NULL
Arg2: 8056375c, The address of the queue being references. Usually this is one
of the ExWorkerQueues.
Arg3: 80563720, The base address of the ExWorkerQueue array. This will help determine
if the queue in question is an ExWorkerQueue and if so, the offset from
this parameter will isolate the queue.
Arg4: 80575950, If this is an ExWorkerQueue (which it usually is), this is the address
of the worker routine that would have been called if the work item was
valid. This can be used to isolate the driver that is misusing the work
queue.

Debugging Details:
------------------




WORKER_ROUTINE:
nt!CmpFindNameInList+2e
80575950 8bff mov edi,edi

FAULTING_IP:
nt!CmpFindNameInList+2e
80575950 8bff mov edi,edi

WORK_ITEM: 8a44e288

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x96

PROCESS_NAME: System

MISALIGNED_IP:
nt!KeForceResumeThread+1
804f9deb 5d pop ebp

LAST_CONTROL_TRANSFER: from 804fcc28 to 804f9deb

STACK_TEXT:
bacf7d34 804fcc28 00000096 8a44e288 8056375c nt!KeForceResumeThread+0x1
bacf7d74 80537999 00000001 00000001 00000000 nt!IoBuildDeviceIoControlRequest+0x7
bacf7dac 805ce84c 8a44e288 00000000 00000000 nt!MmEnableModifiedWriteOfSection+0x5
bacf7ddc 8054532e 805378ce 00000001 00000000 nt!`string'+0x14
bacf7e64 00000000 00000000 00000000 80000000 nt!WmiTraceMessageVa+0x290


STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nt!CmpFindNameInList+2e
80575950 8bff mov edi,edi

SYMBOL_NAME: nt!CmpFindNameInList+2e

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: hardware

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MODULE_NAME: hardware

FAILURE_BUCKET_ID: IP_MISALIGNED

BUCKET_ID: IP_MISALIGNED

Followup: MachineOwner
---------

 

Hello Arie,

Bugcheck code 96 is quite rare.
That's a pleasure for me if we find the solution


DUMP #2
---------------------------------------------------------------------

Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINDOWS\Minidump\Mini112202-02.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: D:\DOCUMENTS\Doc Philippe\PC\DOWNLOAD Logiciels\Système\Windows\Symbols
Executable search path is:
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Windows XP Kernel Version 2600 (Service Pack 1) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Kernel base = 0x804d4000 PsLoadedModuleList = 0x80543530
Debug session time: Fri Nov 22 00:58:58.859 2002 (GMT+1)
System Uptime: 0 days 0:01:17.465
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Loading Kernel Symbols
......................................................................................................................................
Loading User Symbols
Loading unloaded module list
...
ERROR: FindPlugIns 8007007b
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 10000050, {fe8cfe95, 0, 804f5bac, 0}


Could not read faulting driver name


Probably caused by : ntoskrnl.exe ( nt!FsRtlAddLargeMcbEntry+ce )

Followup: MachineOwner
---------

kd> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: fe8cfe95, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 804f5bac, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:
------------------


Could not read faulting driver name



READ_ADDRESS: fe8cfe95

FAULTING_IP:
nt!FsRtlAddLargeMcbEntry+ce
804f5bac 8b7708 mov esi,dword ptr [edi+8]

MM_INTERNAL_CODE: 0

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x50

PROCESS_NAME: CCPROXY.EXE

LAST_CONTROL_TRANSFER: from 805ff504 to 804f5bac

STACK_TEXT:
f5405c58 805ff504 fe8cfe8d 0000010b e2c14510 nt!FsRtlAddLargeMcbEntry+0xce
f5405c88 8060a81b e2c976f8 00000000 00000000 nt!SeCaptureAuditPolicy+0xd9
f5405cd8 805975bb 81f07880 e2cc0eb0 823c78a0 nt!HvpEnlistFreeCell+0x216
f5405d00 80597651 e2ccbc78 e2cc0eb0 00000224 nt!HvpDoWriteHive+0x142
f5405d48 80597777 00000224 00000001 00000000 nt!HvpDoWriteHive+0x2e2
f5405d64 00000000 00000000 00000000 00000000 nt!CmpFileWriteThroughCache+0x49


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!FsRtlAddLargeMcbEntry+ce
804f5bac 8b7708 mov esi,dword ptr [edi+8]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!FsRtlAddLargeMcbEntry+ce

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3ea80977

FAILURE_BUCKET_ID: 0x50_nt!FsRtlAddLargeMcbEntry+ce

BUCKET_ID: 0x50_nt!FsRtlAddLargeMcbEntry+ce

Followup: MachineOwner


DUMP # 3
---------------------------------------------------------------------


Microsoft (R) Windows Debugger Version 6.8.0004.0 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINDOWS\Minidump\Mini070607-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: D:\DOCUMENTS\Doc Philippe\PC\DOWNLOAD Logiciels\Système\Windows\Symbols
Executable search path is:
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Windows XP Kernel Version 2600 (Service Pack 1) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Kernel base = 0x804d4000 PsLoadedModuleList = 0x8054a230
Debug session time: Fri Jul 6 14:46:38.656 2007 (GMT+1)
System Uptime: 0 days 0:01:02.381
Unable to load image ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Loading Kernel Symbols
.................................................................................................................................................................
Loading User Symbols
Loading unloaded module list
..........
ERROR: FindPlugIns 8007007b
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D1, {60, 2, 0, baa83486}

*** WARNING: Unable to verify timestamp for HSF_MSFT.sys


Probably caused by : HSF_MSFT.sys ( HSF_MSFT!WinAcNtSynchGetCommStatus+54 )

Followup: MachineOwner
---------

1: kd> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000060, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: baa83486, address which referenced memory

Debugging Details:
------------------




READ_ADDRESS: 00000060

CURRENT_IRQL: 2

FAULTING_IP:
HSF_MSFT!WinAcNtSynchGetCommStatus+54
baa83486 8b4960 mov ecx,dword ptr [ecx+60h]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: svchost.exe

LAST_CONTROL_TRANSFER: from 805334b1 to 804f5471

STACK_TEXT:
b569ab30 805334b1 0000000a 00000060 00000002 nt!MiWaitForInPageComplete+0x275
b569ab4c 8a5cc2f8 00000784 7ffe0304 0000001b nt!MmProtectMdlSystemAddress+0x267
WARNING: Frame IP not in any known module. Following frames may be wrong.
b569ab58 00000000 00000202 038aff40 00000000 0x8a5cc2f8


STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
HSF_MSFT!WinAcNtSynchGetCommStatus+54
baa83486 8b4960 mov ecx,dword ptr [ecx+60h]

SYMBOL_NAME: HSF_MSFT!WinAcNtSynchGetCommStatus+54

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: HSF_MSFT

IMAGE_NAME: HSF_MSFT.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3b24e552

FAILURE_BUCKET_ID: 0xD1_HSF_MSFT!WinAcNtSynchGetCommStatus+54

BUCKET_ID: 0xD1_HSF_MSFT!WinAcNtSynchGetCommStatus+54

Followup: MachineOwner

 

come in every now &

what to you mean by this ?

Any way to use Quote in the forum (I don't find it)

OK Arie, I will run Windows memory Diagnostic tonight.

thanks for the help provided

 

Thanks again Arie

Run an overnight intensive memory test with Windows Memory Diagnostic.
No errors found after mores of 230 pass (passes ?)

Hope that one of your expert will have the possibilties to have a look on the dumps.

Have a good day

 

Thats OK

Thanks again Arie

Run an overnight intensive memory test with Windows Memory Diagnostic.
No errors found after mores of 230 pass (passes ?)

Hope that one of your expert will have the possibilities to have a look on the dumps.

Have a good day

 

Hi, Lecopi. Welcome to Windows BBS!

A More Reliable RAM Testing Method:

1. Remove some of the memory modules from the computer (while the computer is off, of course).
   • For example, if two RAM modules are installed in your computer, remove one of the RAM modules.
2. Start your computer and see if the problem goes away.
3. If you continue to have unexpected reboots, then replace that RAM module with another module, or install the module in a different memory slot.
4. Start your computer and see if the problem goes away.

Continue this process to see if you can pinpoint the cause of your problem to a specific RAM module or slot.

==========

• Microsoft KB134503:
  

==========

 

Hello to all,

Just an idea ,
Anyway to have somebody sending a private message to one the experts to try to solve this situation.

Thanks to all for the help provided.

 

I suggest we just try to patiently wait for them to return here and offer suggestions. If too many people "bug" them with private messages (PMs), they might decide to stay away for awhile or, even worse, remove their membership from Windows BBS.

If I'm not mistaken, the two dump log analysis experts Arie mentioned are cpc2004 and peterdiva. You might be able to send them a PM but don't expect to receive a faster response about your issue. The title of your thread should be enough to capture their attention if/when they return to this forum.

Both of them have been active on other forums around the Internet and I suspect they spread themselves pretty thin with their available time. You can Google their handles to see where else they might be active.

EDIT: By the way, did you try the alternative RAM testing method I described in post #9 above?

Perhaps one of the experts has already seen your thread (and, perhaps, also suspects your RAM) but did not respond because you have not stated any details about having tried the alternative method of testing your RAM.

 

Hello mailman.

First, thanks for you reply

1) concerning the expert I will strictly follow your advices.

2) concerning the proposed test methodology , I have not perform this specific test until now .
- I ran 2 differents long range memory test (3 hours and 12 hours)
- memory are fully new crucial ballistixs (2 x 1G)

But, I understand your point and I will enter in this proposed methodology starting now. This test could be very, very long if unfortunatly (in this case) the crash doesn't appear quicky . (2 or 3 days for each combination of memory ).

I was expecting, your expert advice, before entering in this kind of test. Pls don't be offense by this.

I will start this process today