Nick Whittome - The Naked MVP

Microsoft MVP, Superhero, Crocodile Wrestler. Owner of NTES and G7eleven

News







  • Locations of visitors to this page







Archives

February 2010 - Posts

RSS / TCP Offloading strikes again. Microsoft should KILL this feature for the masses...

Hi All,

 

This is more of a rant than anything....      but I would love other peoples thoughts.

 

Today, in my own office, a Intel NIC driver was installed on a Windows 7 PC.    This driver enabled RSS, TCP offloading etc.    I got a call to tell me that once again access to the Companyweb was slow on SBS and that typing in http://companyweb in Office products paused for 30 second or more before showing the site content.

 

This symptom has taught me to first look at the network card settings and disable TCP offloading features, which sure enough fixed the problem.

 

My question is this...

 

WHY is this feature even available in Windows / Network Card drivers when I cannot find even ONE common situation where this feature has helped a network or server?

 

Seriously....   Why don’t Microsoft simply turn this feature off by default in an update to ALL versions of Windows and block drivers from enabling it without a user input?   

 

Over the past years I get more calls on support to our office that related to this supposedly great feature than anything else.    On top of that, I would say that there must be millions of people out there that do not even know why their servers are slow, PC’s are slow and network copying slow......

 

Rant over...

 

Gaaaaah!

Eircom are just UNBELIEVABLE! Murroe false service signups....

So, a while back, you sure heard me bitching a lot about not being able to get a decent broadband service in Murroe, Ireland.   You may also know that I teamed up with a fantastic company called Munster Broadband to bring a reliable and quick wireless broadband service to Murroe for the many companies and home users in this area.

For a year, this has been working well, I have a solid 8MB up and down business service from them, as do many of my customers around the area.   I know personally the effort that Munster Broadband put into getting Murroe connected and online when ICE, WTS and others just screwed it up…  over and over again.

Anyway, the latest in the broadband saga is that Eircom are finally going to enable the Murroe exchange.    They have decided apparently to do this in April this year (only 3 years late, but there you go).   Personally, I welcome this as I will happily use them as a backup service for my business.

That said, what they are doing right now has annoyed me so much I simply had to write this post….

They have an Eircom rep walking around Murroe, telling people that broadband service is here, signing people up!  When in fact, the service is NOT here yet!   They are simply “testing the waters”….     I have had three separate reports of this and frankly I think this is a disgrace!

How about doing your market research THREE years ago when we contacted you Eircom?!?!

The flip side….     good for our friends in www.munsterbroadband.ie whom are probably the most honest and reliable service I have used in years.

 

Posted: Tue, Feb 16 2010 10:35 by Nick Whittome | with no comments
Filed under:
Intel 4965AGN Blue Screen Crash on Windows 7 X64 under Heavy Load

This is one I have been fighting with for a while.   In my case, we have a Dell XPS1530 Laptop in the office that when under heavy load is causing BSOD’s on the Intel Driver.   I had found lots of threads on forums, but none pointing to the link with heavy load.    Until Now…..

http://communities.intel.com/thread/6030?tstart=0

If you are having this problem, I encourage you to open a ticket with Intel on this issue as there is still no fix at the time I type this.   There is certainly a major problem with this card, under heavy transfer load, on Windows 7 X64.

Here is a Dump file output you might see for comparison:


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


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

Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (2 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02a14000 PsLoadedModuleList = 0xfffff800`02c51e50
Debug session time: Fri Feb  5 07:16:33.693 2010 (GMT+0)
System Uptime: 0 days 10:41:40.659
Loading Kernel Symbols
...............................................................
................................................................
..............................................
Loading User Symbols
Loading unloaded module list
.......................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D1, {8, 2, 0, fffff8800aaba6d8}

Unable to load image \SystemRoot\system32\DRIVERS\netw5v64.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for netw5v64.sys
*** ERROR: Module load completed but symbols could not be loaded for netw5v64.sys
Probably caused by : netw5v64.sys ( netw5v64+b6d8 )

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: 0000000000000008, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff8800aaba6d8, address which referenced memory

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

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002cbc0e0
0000000000000008

CURRENT_IRQL:  2

FAULTING_IP:
netw5v64+b6d8
fffff880`0aaba6d8 488b4808        mov     rcx,qword ptr [rax+8]

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xD1

PROCESS_NAME:  System

TRAP_FRAME:  fffff80000b9bdc0 -- (.trap 0xfffff80000b9bdc0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=fffffa80073917c0
rdx=0000000000000002 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8800aaba6d8 rsp=fffff80000b9bf50 rbp=fffffa8004cbd720
 r8=fffffa80070c0c00  r9=0000000000000000 r10=fffff80002bff760
r11=0000000000000002 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
netw5v64+0xb6d8:
fffff880`0aaba6d8 488b4808        mov     rcx,qword ptr [rax+8] ds:003a:00000000`00000008=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002a85469 to fffff80002a85f00

STACK_TEXT: 
fffff800`00b9bc78 fffff800`02a85469 : 00000000`0000000a 00000000`00000008 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff800`00b9bc80 fffff800`02a840e0 : 00000000`00000000 fffffa80`08531280 fffffa80`08531201 fffffa80`071e3902 : nt!KiBugCheckDispatch+0x69
fffff800`00b9bdc0 fffff880`0aaba6d8 : fffffa80`08531280 fffff880`0aab1ace 00000000`00000002 00000000`000000ff : nt!KiPageFault+0x260
fffff800`00b9bf50 fffffa80`08531280 : fffff880`0aab1ace 00000000`00000002 00000000`000000ff 00000000`0000069e : netw5v64+0xb6d8
fffff800`00b9bf58 fffff880`0aab1ace : 00000000`00000002 00000000`000000ff 00000000`0000069e fffff800`00b9c0d0 : 0xfffffa80`08531280
fffff800`00b9bf60 00000000`00000002 : 00000000`000000ff 00000000`0000069e fffff800`00b9c0d0 fffffa80`08531170 : netw5v64+0x2ace
fffff800`00b9bf68 00000000`000000ff : 00000000`0000069e fffff800`00b9c0d0 fffffa80`08531170 fffff880`0ac601ec : 0x2
fffff800`00b9bf70 00000000`0000069e : fffff800`00b9c0d0 fffffa80`08531170 fffff880`0ac601ec fffffa80`041c71a0 : 0xff
fffff800`00b9bf78 fffff800`00b9c0d0 : fffffa80`08531170 fffff880`0ac601ec fffffa80`041c71a0 00000000`00000048 : 0x69e
fffff800`00b9bf80 fffffa80`08531170 : fffff880`0ac601ec fffffa80`041c71a0 00000000`00000048 fffffa80`084e3b40 : 0xfffff800`00b9c0d0
fffff800`00b9bf88 fffff880`0ac601ec : fffffa80`041c71a0 00000000`00000048 fffffa80`084e3b40 00000000`00002000 : 0xfffffa80`08531170
fffff800`00b9bf90 fffffa80`041c71a0 : 00000000`00000048 fffffa80`084e3b40 00000000`00002000 00000000`00000000 : netw5v64+0x1b11ec
fffff800`00b9bf98 00000000`00000048 : fffffa80`084e3b40 00000000`00002000 00000000`00000000 fffff800`00b9c0d0 : 0xfffffa80`041c71a0
fffff800`00b9bfa0 fffffa80`084e3b40 : 00000000`00002000 00000000`00000000 fffff800`00b9c0d0 00000000`00000048 : 0x48
fffff800`00b9bfa8 00000000`00002000 : 00000000`00000000 fffff800`00b9c0d0 00000000`00000048 fffffa80`05400310 : 0xfffffa80`084e3b40
fffff800`00b9bfb0 00000000`00000000 : fffff800`00b9c0d0 00000000`00000048 fffffa80`05400310 fffffa80`04cbd720 : 0x2000


STACK_COMMAND:  kb

FOLLOWUP_IP:
netw5v64+b6d8
fffff880`0aaba6d8 488b4808        mov     rcx,qword ptr [rax+8]

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  netw5v64+b6d8

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: netw5v64

IMAGE_NAME:  netw5v64.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4aafec38

FAILURE_BUCKET_ID:  X64_0xD1_netw5v64+b6d8

BUCKET_ID:  X64_0xD1_netw5v64+b6d8

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

Posted: Sat, Feb 6 2010 22:05 by Nick Whittome | with 2 comment(s)
Filed under: