Happened 2 times now while using JDownloader on my University's WiFi.
Seems to happen when I allow more than 10 simultaneous downloads taking about 10 MB/s total. I suspect it may be the version of Java I have installed or some drivers.
This is currently a fairly new installation of windows (2nd day), so it might not be too hard to narrow it down.
Included dumps and reports:
Crash Report.zip
Basic system info:
Windows 7 x64 SP1 (with latest updates)
Gateway P-78 Series Laptop
NVidia GeForce 9800M GTS (GPU-Z Report:
techPowerUp GPU-Z Validation v27be)
Intel Mobile Core 2 Duo P8400 (CPU-Z Report:
CPU-Z Validator 3.1)
Thank you in advance, also as a side note if you see that "Mass Storage Controller" driver not installed in my report, it's an integrated SD card reader that's broken (bent pins) so I don't bother installing it's drivers.
Both of these blame tcpip.sys but more specifically they are Related to
tdx.sys TDI Translation Driver from Microsoft Corporation.
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed. This is a tough bug to find because
the easiest case, a driver actually attempted to complete its own packet
twice, is generally not what happened. Rather, two separate drivers each
believe that they own the packet, and each attempts to complete it. The
first actually works, and the second fails. Tracking down which drivers
in the system actually did this is difficult, generally because the trails
of the first driver have been covered by the second. However, the driver
stack for the current request can be found by examining the DeviceObject
fields in each of the stack locations.
You can start by running a system file check to verify tdx.sys and look in device manager to see if there are two network drivers installed.
Run a system file check to verify and repair your system files.
To do this type cmd in search, then right click to run as administrator, then
SFC /SCANNOW
Read here for more information
SFC /SCANNOW Command - System File Checker
Let us know the results from the report at the end.
Code:
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\K\Desktop\Windows_NT6_BSOD_jcgriff2\052711-37674-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;srv*e:\symbols
*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17592.amd64fre.win7sp1_gdr.110408-1631
Machine Name:
Kernel base = 0xfffff800`02a62000 PsLoadedModuleList = 0xfffff800`02ca7650
Debug session time: Fri May 27 12:31:49.959 2011 (GMT-4)
System Uptime: 0 days 0:53:16.347
Loading Kernel Symbols
...............................................................
................................................................
.....................................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 44, {fffffa80054c2a20, eae, 0, 0}
Probably caused by : tcpip.sys ( tcpip!TcpSatisfyReceiveRequests+4a7 )
Followup: MachineOwner
---------
1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed. This is a tough bug to find because
the easiest case, a driver actually attempted to complete its own packet
twice, is generally not what happened. Rather, two separate drivers each
believe that they own the packet, and each attempts to complete it. The
first actually works, and the second fails. Tracking down which drivers
in the system actually did this is difficult, generally because the trails
of the first driver have been covered by the second. However, the driver
stack for the current request can be found by examining the DeviceObject
fields in each of the stack locations.
Arguments:
Arg1: fffffa80054c2a20, Address of the IRP
Arg2: 0000000000000eae
Arg3: 0000000000000000
Arg4: 0000000000000000
Debugging Details:
------------------
IRP_ADDRESS: fffffa80054c2a20
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0x44
PROCESS_NAME: System
CURRENT_IRQL: 2
LAST_CONTROL_TRANSFER: from fffff80002acb681 to fffff80002ae1d00
STACK_TEXT:
fffff880`02f19d48 fffff800`02acb681 : 00000000`00000044 fffffa80`054c2a20 00000000`00000eae 00000000`00000000 : nt!KeBugCheckEx
fffff880`02f19d50 fffff880`01747da7 : fffffa80`06e712c0 fffff880`02f19f02 fffff880`02f19f00 fffff880`02f19f30 : nt! ?? ::FNODOBFM::`string'+0x42493
fffff880`02f19e30 fffff880`0175ea45 : 00000000`be8cf553 fffffa80`04555cf0 fffffa80`04555cf0 fffffa80`0439d200 : tcpip!TcpSatisfyReceiveRequests+0x4a7
fffff880`02f1a110 fffff880`0175d839 : fffffa80`07396510 fffff880`017e28b7 00000000`00000001 fffffa80`07876670 : tcpip!TcpDeliverDataToClient+0x105
fffff880`02f1a290 fffff880`0176ddee : 00000000`00000510 00000000`0000056a fffffa80`04555cf0 00000000`00000010 : tcpip!TcpDeliverReceive+0xa9
fffff880`02f1a390 fffff880`0175bd54 : fffffa80`03e2f5e0 00000000`00005000 fffff880`02f1a888 fffffa80`04ccb000 : tcpip!TcpTcbCarefulDatagram+0x9ce
fffff880`02f1a540 fffff880`0175a5ea : fffffa80`04cd46f0 fffff880`01752a00 fffffa80`04c8d5d0 00000000`00000000 : tcpip!TcpTcbReceive+0x724
fffff880`02f1a730 fffff880`0175c2ab : fffff880`0563fd4a fffffa80`04ccb000 00000000`00000000 fffff880`02f1ab00 : tcpip!TcpMatchReceive+0x1fa
fffff880`02f1a880 fffff880`01753137 : fffffa80`04cd46f0 fffffa80`04cc5000 fffffa80`00003bc6 00000000`00003bc6 : tcpip!TcpPreValidatedReceive+0x36b
fffff880`02f1a950 fffff880`01752caa : 00000000`00000000 fffff880`018679a0 fffff880`02f1ab10 00000000`00005000 : tcpip!IppDeliverListToProtocol+0x97
fffff880`02f1aa10 fffff880`017522a9 : 00000000`00000000 00000000`00000000 00000000`00000000 fffff880`02f1ab00 : tcpip!IppProcessDeliverList+0x5a
fffff880`02f1aab0 fffff880`0174ffff : 00000000`00000000 fffffa80`04ccb000 fffff880`018679a0 00000000`06f9a401 : tcpip!IppReceiveHeaderBatch+0x23a
fffff880`02f1ab90 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!IpFlcReceivePackets+0x64f
STACK_COMMAND: kb
FOLLOWUP_IP:
tcpip!TcpSatisfyReceiveRequests+4a7
fffff880`01747da7 4c8b254a051400 mov r12,qword ptr [tcpip!TcpInetTransport+0x318 (fffff880`018882f8)]
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: tcpip!TcpSatisfyReceiveRequests+4a7
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: tcpip
IMAGE_NAME: tcpip.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4ce79420
FAILURE_BUCKET_ID: X64_0x44_tcpip!TcpSatisfyReceiveRequests+4a7
BUCKET_ID: X64_0x44_tcpip!TcpSatisfyReceiveRequests+4a7
Followup: MachineOwner
---------
Quote