WinDbg: utorrent.exe + tcpip6 crash my PC

I noticed that for about two or three weeks my PC keeps crashing (well, as I should... dang!).

I run my crash dumps through WinDbg:

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


Loading Dump File [C:\WINDOWS\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: SRV*C:\Programme\Debugging Tools for Windows (x86)\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 2600.xpsp_sp3_gdr.080814-1236
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055d720
Debug session time: Tue Mar 10 22:37:01.718 2009 (GMT+1)
System Uptime: 0 days 0:56:53.312
Loading Kernel Symbols
...............................................................
.............................................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 7ffdd00c).  Type ".hh dbgerr001" for details
Loading unloaded module list
..............
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D1, {2c, 2, 1, b6e7d782}

Page 23254 not present in the dump file. Type ".hh dbgerr004" for details
PEB is paged out (Peb.Ldr = 7ffdd00c).  Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 7ffdd00c).  Type ".hh dbgerr001" for details
Probably caused by : tcpip6.sys ( tcpip6!SendACK+1af )

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

0: 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: 0000002c, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: b6e7d782, address which referenced memory

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

Page 23254 not present in the dump file. Type ".hh dbgerr004" for details
PEB is paged out (Peb.Ldr = 7ffdd00c).  Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 7ffdd00c).  Type ".hh dbgerr001" for details

WRITE_ADDRESS:  0000002c 

CURRENT_IRQL:  2

FAULTING_IP: 
tcpip6!SendACK+1af
b6e7d782 f00fc10f        lock xadd dword ptr [edi],ecx

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xD1

PROCESS_NAME:  utorrent.exe

TRAP_FRAME:  b663e970 -- (.trap 0xffffffffb663e970)
ErrCode = 00000002
eax=89795388 ebx=8976e918 ecx=00000001 edx=00000002 esi=89743fe8 edi=0000002c
eip=b6e7d782 esp=b663e9e4 ebp=b663ea0c iopl=0         nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202
tcpip6!SendACK+0x1af:
b6e7d782 f00fc10f        lock xadd dword ptr [edi],ecx ds:0023:0000002c=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from b6e7d782 to 805446f0

STACK_TEXT:  
b663e970 b6e7d782 badb0d00 00000002 096009e3 nt!KiTrap0E+0x238
b663ea0c b6e7efe3 8976e900 00000000 00000c1b tcpip6!SendACK+0x1af
b663ea28 b6e7bca0 893409b8 897e1aa0 893409f0 tcpip6!ProcessTCBDelayQ+0xed
b663ea44 b6e5d6be b663ea68 00000020 89340a74 tcpip6!TdiReceive+0x227
b663ea7c b6e5de46 89340900 89340a70 89340980 tcpip6!TCPReceiveData+0x72
b663ea98 804ef19f 89f1d030 893409b8 897a1db0 tcpip6!TCPDispatchInternalDeviceControl+0x4c
b663eaa8 b6e483a4 00000000 00000008 b663eb1c nt!IopfCallDriver+0x31
8a087e00 89e9f4f8 00000012 b6e5a000 00037240 afd!AfdFastConnectionReceive+0x25f
WARNING: Frame IP not in any known module. Following frames may be wrong.
8a087e14 8a087ea8 001c001c e1668298 8067d260 0x89e9f4f8
8a22dab0 8a4b87e0 b6e85480 00000001 00000000 0x8a087ea8
8a4bee48 8a22dab0 b6e39fa8 00000001 00000000 0x8a4b87e0
8a4bee4c b6e39fa8 00000001 00000000 00000000 0x8a22dab0
8a4bee50 00000000 00000000 00000000 b6e38000 afd!_load_config_used+0x48


STACK_COMMAND:  kb

FOLLOWUP_IP: 
tcpip6!SendACK+1af
b6e7d782 f00fc10f        lock xadd dword ptr [edi],ecx

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  tcpip6!SendACK+1af

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: tcpip6

IMAGE_NAME:  tcpip6.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  485b8fa4

FAILURE_BUCKET_ID:  0xD1_tcpip6!SendACK+1af

BUCKET_ID:  0xD1_tcpip6!SendACK+1af

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

Using the minidumps gives the pretty much the same result.

I understand (and that is confirmed by my experience that my PC crashed only when µTorrent v1.8.2.14458 is running) that there is some problem between µTorrent and tcpip.sys that keeps it crashing.

My PC seams to be clean (I have AVG Free Edition, occasionally run Autoruns and RootkitRevealer from Sysinternals/Microsoft and HijackThis), also ran LSPFix and have not additional Firewall installed, though my router seems to have one (but it's the same one for about six months now).

I used LvlLord's Intelligent TCPIP.SYS patcher / EventID 4226 patch to set the maximum concurrent half-open connections to 40. In µTorrent, I set net.max_halfopen to 25 - after several crashes, and I feel it has helped in reducing the number of crashes. The global maximum number of connections is set to 250 (after the last crash to 240), maximum number of connected peers per torrent was 65 (now 60). The maximum number of active torrents is set to 22.

I feel that the last crash may be the result of my limiting up- and download to 25 and 5 kB/s, respectively, but I'd like your advice on that. Earlier (i.e. a couple of days ago) I felt that my running eMule and occasionally the FreeDownloadManager at the same time was the reason. It was then that I changed my settings, and to this day it has helped. But this night (GMT+1) it crashed twice - once with multiple programs running, the other time with only µTorrent (and BOINC) running, but both time with limited up/download rates.

If anyone has any idea, it's a bit warysome

DRIVER_IRQL_NOT_LESS_OR_EQUAL

...is OFTEN the result of bad networking drivers/bad network cards crashing.

If newer drivers don't help, getting a good replacement card might.

I have an Atheros L1 Gigabit Ethernet 10/100/1000Base-T Controller (if that's what you mean) and it's driver is dated 12 november 2008 (v2.3.7.12). I can't tell if that's a good one or not.

I have downloaded the L1WinSetup_v2.4.7.15_WHQL.rar package (Atheros L1 Windows Driver x86/x64) and hope this is the one. If anyone thinks that's not the right one, please let me know. I might install that this weekend to see. Anyway, as long as I follow my following rules, it seems to work for the moment. (Remember, they are my rules, they may or may not work for you in the same situation.)

Rules:

* Don't run µTorrent with any P2P application together.

* Don't run µTorrent with a download manager with multiple connections for faster download.

* maximum concurrent half-open connections > net.max_halfopen > maximum number of active torrents

* No upload/download limiting (to use the internet connection for other reasons), stop torrents or µTorrent instead.

I'll come back to this later, either when I tried the new driver or someone wrote a message in this topic.

uTorrent should have upload speed max limits. Download matters far less and is usually unnecessary for all but the slowest symmetric connections. 2nd link in my signature to configure uTorrent...though you may want to limit global and per-torrent connections to 60 or less for testing.

To be honest, I have no idea of our ADSL connection speed. Our ISP doesn't really communicate that. "Up to 24M" or something like that. (And I have no idea, either whether it's 10 or 18 or 24 or something, nor whether it's Mbit or MByte. So I have no idea of the upload maximum. My guess would be that 1 or 1.5 mbit/s would be close enough. Which means, using your second link I'd have reduce the maximum number of active torrents, which would have been with 22 way too high... And I'll set and upload limit.

You still think that I should try this driver update?

If you're sure it's the right driver and newer than you have, yes.

Do speed tests of your line...your upload may be only a fraction of 1 megabit/second.

Download max for an ADSL 2+ line is 24 megabit/second.

You were right. I made several tests.

So it's only ~320 kb/s. :mad:

Also tried a server in Los Angeles, California which resulted in 4594 kb/s for download and 249 kb/s for upload.

Will have to adjust my settings.

As for the driver: I guess it's the right one (Atheros L1 Gigabit Ethernet vs. Atheros L1) and newer (2.3.7.12 vs. 2.4.7.15). And inside the archive the readme text file says "The driver installation package contains the Atheros L1 Gigabit Ethernet Controller Driver" - so I guess I'm good...

My speed chart for 320 kilobit/second upload seems best suited then.

If you want, you can set active downloading torrents to 2 or 3 -- since that doesn't change how fast you're uploading per upload slot.