Several BSODs with Different Stop Messages

[peak]

Newly built computer, I'll update my specs in the profile shortly (done).
Probably crashed 5 or 6 times.

Crashed while gaming, crashed while not gaming, crashed while I was at the store.
Could possibly blame xSplit for the crashes, as I can't remember if it's crashed while it isn't running.
Different errors each time: DRIVER_IRQL_NOT_LESS_OR_EQUAL, PAGE_FAULT_IN_NONPAGED_AREA (x2), UNEXPECTED_KERNEL_MODE_TRAP, KMODE_EXCEPTION_NOT_HANDLED, MEMORY_MANAGEMENT.

I removed one stick of RAM recently to test if it was bad, even though memory test didn't show any issues. All the crashes so far have been with both sticks.

Is Windows 7 . . .
- x86 (32-bit) or x64 ? x64 - the original installed OS on the system? I installed it, newly built computer.
- an OEM or full retail version? It's an OEM version from one of my Dell computers.
- OEM = came pre-installed on system
- Full Retail = you purchased it from retailer
- What is the age of system (hardware)? A few days, it's newly built.
- What is the age of OS installation (have you re-installed the OS?) A few days.

-

Edit: One dump didn't get included. It was at C:\Windows\MEMORY.DMP. It's roughly 500MB in size. Here is the results of running a WinDBG on it:

0: kd> !analyze -v
Unable to get program counter
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff80002e8df83, Address of the exception record for the exception that caused the bugcheck
Arg3: fffff88007f8eb90, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

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

***** Debugger could not find nt in module list, module list might be corrupt, error 0x80070057.

Page 9586dc3 too large to be in the dump file.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
+0
3a06:df83 ?? ???

CONTEXT: fffff88007f8eb90 -- (.cxr 0xfffff88007f8eb90)
rax=0000000000000002 rbx=0000000000000000 rcx=23cf5fe230f80000
rdx=0000000000000100 rsi=0000000000000000 rdi=fffff9802330ee10
rip=fffff80002e8df83 rsp=fffff88007f8f570 rbp=00000000a000000c
r8=fffff880009ea180 r9=fffff880009ea180 r10=0000000000000100
r11=0000000000000000 r12=00000000a0000003 r13=0000000000000000
r14=0000000000000000 r15=fffff9802330eed0
iopl=0 nv up ei ng nz na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010286
fffff800`02e8df83 0000 add byte ptr [rax],al ds:002b:00000000`00000002=??
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x3B

CURRENT_IRQL: 0

UNALIGNED_STACK_POINTER: 010101013acc39ee

LAST_CONTROL_TRANSFER: from fffffa80084e7900 to fffff80002e8df83

STACK_TEXT:
01010101`3acc39ee 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x1010101`3a103bc9


STACK_COMMAND: kb

SYMBOL_NAME: ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

BUCKET_ID: CORRUPT_MODULELIST

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

 

[Jonathan_King]

Hi there,

It seems there may be multiple issues going on. The first is a hardware problem, as suggested by some of the dumps and by your report on the crashes being with only both RAM sticks.

The second is a simple driver issue. Install the latest Realtek ethernet drivers from here: Realtek

Rt64win7.sys  Wed Jan 26 08:34:03 2011 (4D4022CB)

Continue testing with only one stick of RAM installed. You might also run Prime95 on both sticks at the same time: http://www.sevenforums.com/tutorials/100352-hardware-stress-test-prime95.html

Note: Prime95 passing the sticks does not prove that they are good. False negatives are common, but any positive (error) should be treated seriously.

...Summary of the dumps:

[font=lucida console]
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Debug session time: Wed Nov  9 22:00:19.630 2011 (UTC - 5:00)
System Uptime: 0 days 0:37:36.474
*** ERROR: Module load completed but symbols could not be loaded for tcpip.sys
*** WARNING: Unable to verify timestamp for Rt64win7.sys
*** ERROR: Module load completed but symbols could not be loaded for Rt64win7.sys
Probably caused by : Rt64win7.sys ( Rt64win7+159a3 )
BUGCHECK_STR:  0x1E_0
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
PROCESS_NAME:  svchost.exe
FAILURE_BUCKET_ID:  X64_0x1E_0_Rt64win7+159a3
BiosReleaseDate = 05/10/2011
SystemProductName = TZ68A+
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Debug session time: Wed Nov  9 22:37:32.248 2011 (UTC - 5:00)
System Uptime: 0 days 0:18:25.091
Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+330bc )
BUGCHECK_STR:  0x1a_403
DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP
PROCESS_NAME:  XSplit.Core.ex
FAILURE_BUCKET_ID:  X64_0x1a_403_VRF_nt!_??_::FNODOBFM::_string_+330bc
BiosReleaseDate = 05/10/2011
SystemProductName = TZ68A+
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Built by: 7600.16841.amd64fre.win7_gdr.110622-1503
Debug session time: Wed Nov  9 19:02:20.751 2011 (UTC - 5:00)
System Uptime: 0 days 0:12:31.203
Probably caused by : fltmgr.sys ( fltmgr!FltpMoveIrpToCallbackData+17 )
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
BUGCHECK_STR:  0x50
PROCESS_NAME:  svchost.exe
FAILURE_BUCKET_ID:  X64_0x50_fltmgr!FltpMoveIrpToCallbackData+17
BiosReleaseDate = 05/10/2011
SystemProductName = TZ68A+
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Built by: 7600.16841.amd64fre.win7_gdr.110622-1503
Debug session time: Wed Nov  9 04:00:47.418 2011 (UTC - 5:00)
System Uptime: 0 days 13:27:20.496
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for NETIO.SYS - 
*** ERROR: Module load completed but symbols could not be loaded for tcpip.sys
*** ERROR: Module load completed but symbols could not be loaded for afd.sys
Probably caused by : NETIO.SYS ( NETIO!NetioAllocateAndReferenceNetBufferListNetBufferMdlAndData+3e )
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
BUGCHECK_STR:  0xD1
PROCESS_NAME:  League of Lege
FAILURE_BUCKET_ID:  X64_0xD1_NETIO!NetioAllocateAndReferenceNetBufferListNetBufferMdlAndData+3e
BiosReleaseDate = 05/10/2011
SystemProductName = TZ68A+
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Built by: 7600.16841.amd64fre.win7_gdr.110622-1503
Debug session time: Wed Nov  9 18:23:26.044 2011 (UTC - 5:00)
System Uptime: 0 days 0:21:22.121
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : win32k.sys ( win32k+56dcd )
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
BUGCHECK_STR:  0x50
PROCESS_NAME:  firefox.exe
FAILURE_BUCKET_ID:  X64_0x50_win32k+56dcd
BiosReleaseDate = 05/10/2011
SystemProductName = TZ68A+
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Debug session time: Wed Nov  9 21:07:54.304 2011 (UTC - 5:00)
System Uptime: 0 days 1:19:44.662
Probably caused by : ndis.sys ( ndis!ndisParseReceivedNBL+da )
BUGCHECK_STR:  0x7f_8
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
PROCESS_NAME:  System
FAILURE_BUCKET_ID:  X64_0x7f_8_ndis!ndisParseReceivedNBL+da
BiosReleaseDate = 05/10/2011
SystemProductName = TZ68A+
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨``
  
[/font]

 

[peak]

Hi,

Thanks for your response.
In trying to diagnose this issue myself, I did notice the Realtek LAN drivers already and updated them yesterday.
I've crashed since then (the MEMORY.DMP instance), but only once.

I ran Prime95 with just the one stick a couple of minutes ago for about 5-10 minutes with no issue. I'll restart and put the other stick in and give it a go again.

edit: Running the test now. I'll leave it on a while.

 

[peak]

Been running for an hour now. No issues, no crashing, and temperatures are stable.
That's with both sticks of RAM.

 

[peak]

Two hours. My movie is over, still no issues and still running on all four cores.
Any thoughts?

edit: I'm going to run and grab some food, but I'm going to load up xSplit while I'm gone.
I don't recall it crashing without xSplit. I also installed it on the 8th and started streaming a game for the first time that night. I also crashed for the first time that night. Could that be the cause?

 

[peak]

Stopped xSplit now.
Still no crashes.

 

[peak]

Any more suggestions on what I could do?

 

[peak]

No crashes at all tonight.
Both sticks of RAM. Played some Skyrim, streamed it too.

Also Prime95 for about 4.5 hours with no errors reported.

 

[Jonathan_King]

It's possible that one of the sticks wasn't seated properly, and removing it and reinstalling it did some good.

Without crashes, there is nothing else we can do. Just keep an eye on the system, and if you get another crash, post back and we'll go from there.

 

[peak]

New crash. Seems to be referencing the same driver again, even though I already updated it.
I'll double check it, but let me know what you think.

Here is the WinDBG:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc000001d, The exception code that was not handled
Arg2: fffff880069c2470, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: 0000000000000000, Parameter 1 of the exception

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


EXCEPTION_CODE: (NTSTATUS) 0xc000001d - {EXCEPTION} Illegal Instruction An attempt was made to execute an illegal instruction.

FAULTING_IP:
+56ab952f033ddcc0
fffff880`069c2470 98 cwde

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000000000000000

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP

BUGCHECK_STR: 0x1E

PROCESS_NAME: System

CURRENT_IRQL: 2

EXCEPTION_RECORD: fffff880069c3398 -- (.exr 0xfffff880069c3398)
ExceptionAddress: fffff88001706fd3 (tcpip!TcpTcbFastDatagram+0x0000000000000483)
ExceptionCode: c000001d (Illegal instruction)
ExceptionFlags: 00000000
NumberParameters: 0

TRAP_FRAME: fffff880069c3440 -- (.trap 0xfffff880069c3440)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000006 rbx=0000000000000000 rcx=00000000000006aa
rdx=000000000004431a rsi=0000000000000000 rdi=0000000000000000
rip=fffff88001706fd3 rsp=fffff880069c35d0 rbp=fffff880069c3870
r8=fffffa8009a9ecf0 r9=0000000000600000 r10=00000000000006aa
r11=0000000000059fbd r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
tcpip!TcpTcbFastDatagram+0x483:
fffff880`01706fd3 0f8501030000 jne tcpip!TcpTcbFastDatagram+0x78a (fffff880`017072da) [br=1]
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002f164fb to fffff80002e8ac40

FAILED_INSTRUCTION_ADDRESS:
+56ab952f033ddcc0
fffff880`069c2470 98 cwde

STACK_TEXT:
fffff880`069c35d0 fffff880`017078b5 : 00000000`80000000 fffff800`033224a3 00000000`00000000 00000000`00000000 : tcpip!TcpTcbFastDatagram+0x483
fffff880`069c3790 fffff880`0170667a : fffffa80`08223900 fffff880`016feb00 fffffa80`081ef101 00000000`00000000 : tcpip!TcpTcbReceive+0x1f5
fffff880`069c3940 fffff880`017082ab : fffff880`04ceaea2 fffffa80`08342000 00000000`00000000 fffff880`0fcc3000 : tcpip!TcpMatchReceive+0x1fa
fffff880`069c3a90 fffff880`016ff1c7 : fffffa80`08223900 fffffa80`08220830 fffffa80`000096c6 00000000`00000000 : tcpip!TcpPreValidatedReceive+0x36b
fffff880`069c3b60 fffff880`016fed3a : 00000000`00000000 fffff880`0181e9a0 fffff880`069c3d20 00001f80`00000200 : tcpip!IppDeliverListToProtocol+0x97
fffff880`069c3c20 fffff880`016fe339 : 00000000`00000000 00000000`00000000 00000000`00000000 fffff880`069c3d10 : tcpip!IppProcessDeliverList+0x5a
fffff880`069c3cc0 fffff880`016fc0af : 00000000`00000000 fffffa80`08342000 fffff880`0181e9a0 00000000`0817a001 : tcpip!IppReceiveHeaderBatch+0x23a
fffff880`069c3da0 fffff880`016fb6a2 : fffffa80`087b7f70 00000000`00000000 fffffa80`0817a001 fffff880`00000001 : tcpip!IpFlcReceivePackets+0x64f
fffff880`069c3fa0 fffff880`016fab3a : fffffa80`0817a010 fffff880`069c40d0 fffffa80`0817a010 fffff8a0`082e0000 : tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x2b2
fffff880`069c4080 fffff800`02e97618 : fffff980`05b40e20 00000000`00004800 fffffa80`09ac9970 00000000`00000000 : tcpip!FlReceiveNetBufferListChainCalloutRoutine+0xda
fffff880`069c40d0 fffff880`016fb202 : fffff880`016faa60 00000000`00000000 00000000`00000002 00000000`00000000 : nt!KeExpandKernelStackAndCalloutEx+0xd8
fffff880`069c41b0 fffff880`015170eb : fffff980`0a1ee8d0 00000000`00000000 fffffa80`087581a0 00000000`00000000 : tcpip!FlReceiveNetBufferListChain+0xb2
fffff880`069c4220 fffff880`014e0ad6 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ndis!ndisMIndicateNetBufferListsToOpen+0xdb
fffff880`069c4290 fffff880`01459cc1 : fffffa80`087581a0 00000000`00000002 00000000`00000001 00000000`00000001 : ndis!ndisMDispatchReceiveNetBufferLists+0x1d6
fffff880`069c4710 fffff880`03f34ce8 : fffffa80`087ce000 00000000`00000001 fffffa80`087ce618 00000000`00000000 : ndis!NdisMIndicateReceiveNetBufferLists+0xc1
fffff880`069c4760 fffffa80`087ce000 : 00000000`00000001 fffffa80`087ce618 00000000`00000000 00000000`00000001 : Rt64win7+0x16ce8
fffff880`069c4768 00000000`00000001 : fffffa80`087ce618 00000000`00000000 00000000`00000001 fffff800`02e729cb : 0xfffffa80`087ce000
fffff880`069c4770 fffffa80`087ce618 : 00000000`00000000 00000000`00000001 fffff800`02e729cb 00000001`069c8000 : 0x1
fffff880`069c4778 00000000`00000000 : 00000000`00000001 fffff800`02e729cb 00000001`069c8000 ffff0000`00000001 : 0xfffffa80`087ce618


STACK_COMMAND: .trap 0xfffff880069c3440 ; kb

FOLLOWUP_IP:
Rt64win7+16ce8
fffff880`03f34ce8 ?? ???

SYMBOL_STACK_INDEX: f

SYMBOL_NAME: Rt64win7+16ce8

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Rt64win7

IMAGE_NAME: Rt64win7.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4e53b15d

FAILURE_BUCKET_ID: X64_0x1E_VRF_BAD_IP_Rt64win7+16ce8

BUCKET_ID: X64_0x1E_VRF_BAD_IP_Rt64win7+16ce8

Followup: MachineOwner

 

[peak]

Two more crashes.

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000020, a pool block header size is corrupt.
Arg2: fffff8a0014851c0, The pool entry we were looking for within the page.
Arg3: fffff8a001485210, The next pool entry.
Arg4: 0000000005050404, (reserved)

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


BUGCHECK_STR: 0x19_20

POOL_ADDRESS: fffff8a0014851c0

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP

PROCESS_NAME: iPodService.ex

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80003009cae to fffff80002edbc40

STACK_TEXT:
fffff880`06e41898 fffff800`03009cae : 00000000`00000019 00000000`00000020 fffff8a0`014851c0 fffff8a0`01485210 : nt!KeBugCheckEx
fffff880`06e418a0 fffff800`031d2dd3 : fffffa80`06d50570 fffffa80`088c9f50 fffffa80`6d4e624f 00000000`00000000 : nt!ExDeferredFreePool+0x12da
fffff880`06e41950 fffff800`02ee5afc : 00000000`00000000 fffffa80`09b87b30 fffffa80`06d50570 00000000`0001009e : nt!ObpFreeObject+0x2b3
fffff880`06e419a0 fffff800`031d2f44 : fffffa80`09b87b30 00000000`00000000 fffffa80`09c6fb60 00000000`00000000 : nt!ObfDereferenceObject+0xdc
fffff880`06e41a00 fffff800`031d34f4 : 00000000`00000168 fffffa80`09b87b30 fffff8a0`0367ce90 00000000`00000168 : nt!ObpCloseHandleTableEntry+0xc4
fffff880`06e41a90 fffff800`02edaed3 : fffffa80`09c6fb60 fffff880`06e41b60 00000000`00000000 00000000`00000000 : nt!ObpCloseHandle+0x94
fffff880`06e41ae0 00000000`77bd140a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`028df3a8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77bd140a


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!ObpFreeObject+2b3
fffff800`031d2dd3 49c7451000000000 mov qword ptr [r13+10h],0

SYMBOL_STACK_INDEX: 2

SYMBOL_NAME: nt!ObpFreeObject+2b3

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4e02aaa3

FAILURE_BUCKET_ID: X64_0x19_20_VRF_nt!ObpFreeObject+2b3

BUCKET_ID: X64_0x19_20_VRF_nt!ObpFreeObject+2b3

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

SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION (c1)
Special pool has detected memory corruption. Typically the current thread's
stack backtrace will reveal the guilty party.
Arguments:
Arg1: fffff9801af92ee0, address trying to free
Arg2: fffff9801af92893, address where one bit is corrupted
Arg3: 00000000006f0118, (reserved)
Arg4: 0000000000000032, caller is freeing an address where nearby bytes within the same page have a single bit error

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


BUGCHECK_STR: 0xC1_32

SPECIAL_POOL_CORRUPTION_TYPE: 32

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP

PROCESS_NAME: VHMultiWriterE

CURRENT_IRQL: 1

IRP_ADDRESS: fffffa8008924a88

LAST_CONTROL_TRANSFER: from fffff80002f1bfe3 to fffff80002e92c40

STACK_TEXT:
fffff880`084f5598 fffff800`02f1bfe3 : 00000000`000000c1 fffff980`1af92ee0 fffff980`1af92893 00000000`006f0118 : nt!KeBugCheckEx
fffff880`084f55a0 fffff800`02f949b3 : 00000000`00000000 fffff800`0333a40a fffffa80`00000003 fffffa80`08924b60 : nt!MiCheckSpecialPoolSlop+0x83
fffff880`084f55e0 fffff800`02fc093b : fffff800`02e16000 00000000`2b707249 00000000`002deab8 00000000`00000001 : nt!MmFreeSpecialPool+0x1d3
fffff880`084f5720 fffff800`03337026 : fffffa80`09729102 fffffa80`09729160 00000000`00000000 fffff980`1af92ee0 : nt!ExDeferredFreePool+0xf33
fffff880`084f57d0 fffff800`033375ec : fffff800`02ea801c fffff980`1af92ee0 fffffa80`09cb3740 00000000`00000000 : nt!VfIoFreeIrp+0xe6
fffff880`084f5800 fffff800`02ea801c : fffffa80`09cb3740 fffff980`1af92ee0 00000000`00000000 fffff800`03332b63 : nt!IovFreeIrpPrivate+0x5c
fffff880`084f5840 fffff800`0319b267 : fffffa80`08924b00 fffffa80`09cb3740 00000000`00000000 fffffa80`00000000 : nt!IopCompleteRequest+0x54c
fffff880`084f5910 fffff800`0317cb63 : fffffa80`09cb3740 fffff880`084f5b60 fffffa80`09cb3740 00000000`00000001 : nt!IopSynchronousServiceTail+0x147
fffff880`084f5980 fffff800`02e91ed3 : 00000000`74d72450 00000000`000000d4 00000000`00000001 00000000`022ef944 : nt!NtReadFile+0x631
fffff880`084f5a70 00000000`74d72e09 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`01e9ea28 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x74d72e09


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!MiCheckSpecialPoolSlop+83
fffff800`02f1bfe3 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!MiCheckSpecialPoolSlop+83

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

DEBUG_FLR_IMAGE_TIMESTAMP: 4e02aaa3

IMAGE_NAME: memory_corruption

FAILURE_BUCKET_ID: X64_0xC1_32_VRF_nt!MiCheckSpecialPoolSlop+83

BUCKET_ID: X64_0xC1_32_VRF_nt!MiCheckSpecialPoolSlop+83

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

 

[peak]

Another:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1A, {403, fffff68000035350, bd90000177d89867, fffff68000039672}

Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+330bc )

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

3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

MEMORY_MANAGEMENT (1a)
# Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000000403, The subtype of the bugcheck.
Arg2: fffff68000035350
Arg3: bd90000177d89867
Arg4: fffff68000039672

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


BUGCHECK_STR: 0x1a_403

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VERIFIER_ENABLED_VISTA_MINIDUMP

PROCESS_NAME: rads_user_kern

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002e7e3f6 to fffff80002ed6c40

STACK_TEXT:
fffff880`0814f668 fffff800`02e7e3f6 : 00000000`0000001a 00000000`00000403 fffff680`00035350 bd900001`77d89867 : nt!KeBugCheckEx
fffff880`0814f670 fffff800`02f08bb7 : 00000000`00000000 fffff680`00035ff8 fffffa80`07ece860 00000000`00000001 : nt! ?? ::FNODOBFM::`string'+0x330bc
fffff880`0814f820 fffff800`02ec40ff : fffffa80`00000000 00000000`07310fff 00000000`00000000 00000000`00000000 : nt!MiDeleteVirtualAddresses+0x41f
fffff880`0814f9e0 fffff800`02ed5ed3 : ffffffff`ffffffff 00000000`02a0e810 00000000`02a0e808 00000000`00008000 : nt!NtFreeVirtualMemory+0x61f
fffff880`0814fae0 00000000`775914fa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`02a0e7d8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x775914fa


STACK_COMMAND: kb

FOLLOWUP_IP:
nt! ?? ::FNODOBFM::`string'+330bc
fffff800`02e7e3f6 cc int 3

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt! ?? ::FNODOBFM::`string'+330bc

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4e02aaa3

FAILURE_BUCKET_ID: X64_0x1a_403_VRF_nt!_??_::FNODOBFM::_string_+330bc

BUCKET_ID: X64_0x1a_403_VRF_nt!_??_::FNODOBFM::_string_+330bc

Followup: MachineOwner

 

[peak]

Ran memtest86+ again.
Around 5 minutes in and 20% through the first pass and 14 errors have cropped up already.

Should I keep it running, or is that enough to say "okay, something's messed up" and drop down and test one slot at a time?

 

[peak]

Up to 36 errors now, 13 minutes in.

 

[Jonathan_King]

Yep, any number of errors is grounds for calling it. I suggest you replace your RAM and see what happens.

 

[peak]

Thousands of errors on the bad stick.
No errors on the good stick, in two different slots. One for 3 passes, one for 9 passes.

 

[Jonathan_King]

You're best off replacing the entire kit, rather than trying to find an identical match. That's when incompatibility issues start to show.

 

[peak]

That's the plan, but at least for now I can operate on the one stick.
I found out that I can get an advanced RMA with Newegg and basically get a replacement sooner than I would normally, so I'll have practically no downtime.

 

[Jonathan_King]

Good deal...keep us posted!