At this point there is no adequate reason for a stop 0xD1 BSOD caused by tcpip.sys!
Though I have faced such issues a couple of times earlier.
Test your RAM modules for possible errors.
How to Test and Diagnose RAM Issues with Memtest86+
Run memtest for at least 8 passes, preferably overnight.
If it start showing errors/red lines, stop testing. A single error is enough to determine that something is going bad there.
If it does not show any error, enable Driver Verifier to monitor the drivers.
Driver Verifier - Enable and Disable
Run Driver Verifier for 24 hours or the occurrence of the next crash, whichever is earlier.
Information
Why Driver Verifier:
It puts a stress on the drivers, ans so it makes the unstable drivers crash. Hopefully the driver that crashes is recorded in the memory dump.
How Can we know that DV is enabled:
It will make the system bit of slow, laggy.
Warning
Before enabling DV, make it sure that you have earlier System restore points made in your computer. You can check it easily by using
CCleaner looking at Tools > System Restore.
If there is no points,
make a System Restore Point manually before enabling DV.
Let us know the results, with the subsequent crash dumps, if any.
Also, can you update the BIOS to Version F4? GIGABYTE - Motherboard - Socket 775 - GA-EP35-DS3 (rev. 2.1)
____________________________________________
Code:
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck D1, {fffff8810a82cae0, 2, 1, fffff88001664f77}
Probably caused by : tcpip.sys ( tcpip!TcpSegmentTcbSend+87 )
Followup: MachineOwner
---------
1: kd> !analyze -v
*******************************************************************************
* *
* 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: fffff8810a82cae0, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, value 0 = read operation, 1 = write operation
Arg4: fffff88001664f77, address which referenced memory
Debugging Details:
------------------
WRITE_ADDRESS: GetPointerFromAddress: unable to read from fffff80003303100
GetUlongFromAddress: unable to read from fffff800033031c0
fffff8810a82cae0 Nonpaged pool
CURRENT_IRQL: 2
FAULTING_IP:
tcpip!TcpSegmentTcbSend+87
fffff880`01664f77 66418902 mov word ptr [r10],ax
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
BUGCHECK_STR: 0xD1
PROCESS_NAME: System
ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre
DPC_STACK_BASE: FFFFF88002F22FB0
TRAP_FRAME: fffff88002f1ac80 -- (.trap 0xfffff88002f1ac80)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=000000000000f8c6 rbx=0000000000000000 rcx=0000000000000014
rdx=fffffa8003d3f450 rsi=0000000000000000 rdi=0000000000000000
rip=fffff88001664f77 rsp=fffff88002f1ae10 rbp=0000000000000001
r8=0000000073440005 r9=fffff8810a82caf8 r10=fffff8810a82cae0
r11=0000fffffffff000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na pe nc
tcpip!TcpSegmentTcbSend+0x87:
fffff880`01664f77 66418902 mov word ptr [r10],ax ds:fffff881`0a82cae0=????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff800030cb169 to fffff800030cbbc0
STACK_TEXT:
fffff880`02f1ab38 fffff800`030cb169 : 00000000`0000000a fffff881`0a82cae0 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff880`02f1ab40 fffff800`030c9de0 : fffff880`00000006 fffffa80`048a0c60 fffffa80`045a0002 fffff880`02f1b020 : nt!KiBugCheckDispatch+0x69
fffff880`02f1ac80 fffff880`01664f77 : 00000000`00000001 fffff6fc`40054168 00000000`00000000 fffff881`0a82ca80 : nt!KiPageFault+0x260
fffff880`02f1ae10 fffff880`01662e39 : fffffa80`eb52defc fffffa80`03d3f450 00000000`00000001 fffff881`0a82caf8 : tcpip!TcpSegmentTcbSend+0x87
fffff880`02f1af10 fffff880`016675d9 : 00000000`00000000 fffff880`03b9d3fd 00000000`00000000 00000000`00000218 : tcpip!TcpBeginTcbSend+0x4d9
fffff880`02f1b190 fffff880`01687806 : 00000000`00000000 fffff880`01686b18 fffff880`01767128 00000000`00000000 : tcpip!TcpTcbSend+0x1d9
fffff880`02f1b410 fffff880`016871a6 : 00000000`00000000 00000000`00000000 00000000`00000d98 00000000`00061e5a : tcpip!TcpFlushDelay+0x316
fffff880`02f1b4f0 fffff800`030d685c : fffff880`02f1b600 fffff880`000207d2 00000000`00000000 00000000`00000001 : tcpip!TcpPeriodicTimeoutHandler+0x3f9
fffff880`02f1b570 fffff800`030d66f6 : fffffa80`05ea8c58 fffffa80`05ea8c58 00000000`00000000 00000000`00000000 : nt!KiProcessTimerDpcTable+0x6c
fffff880`02f1b5e0 fffff800`030d65de : 00000009`4a932cc1 fffff880`02f1bc58 00000000`0003e73d fffff880`009ebd28 : nt!KiProcessExpiredTimerList+0xc6
fffff880`02f1bc30 fffff800`030d63c7 : 00000002`302f7ec2 00000002`0003e73d 00000002`302f7e77 00000000`0000003d : nt!KiTimerExpiration+0x1be
fffff880`02f1bcd0 fffff800`030c38ca : fffff880`009e9180 fffff880`009f3fc0 00000000`00000000 fffff880`03bea480 : nt!KiRetireDpcList+0x277
fffff880`02f1bd80 00000000`00000000 : fffff880`02f1c000 fffff880`02f16000 fffff880`02f1bd40 00000000`00000000 : nt!KiIdleLoop+0x5a
STACK_COMMAND: kb
FOLLOWUP_IP:
tcpip!TcpSegmentTcbSend+87
fffff880`01664f77 66418902 mov word ptr [r10],ax
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: tcpip!TcpSegmentTcbSend+87
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: tcpip
IMAGE_NAME: tcpip.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 533f5bd4
IMAGE_VERSION: 6.1.7601.18438
FAILURE_BUCKET_ID: X64_0xD1_tcpip!TcpSegmentTcbSend+87
BUCKET_ID: X64_0xD1_tcpip!TcpSegmentTcbSend+87
ANALYSIS_SOURCE: KM
FAILURE_ID_HASH_STRING: km:x64_0xd1_tcpip!tcpsegmenttcbsend+87
FAILURE_ID_HASH: {54274084-0543-fa2c-cabe-6eb48ddbff82}
Followup: MachineOwner
---------