BSOD: Netio.sys based

[Binkenstein]

Hi,

I'm getting a netio.sys based BSOD, but I can't read the minidump files clearly (I think I need to do some configuration to get it to read clearly).

Can someone open the latest one and post the contents? I should be able to work it from there (or, any advice you can give would be appreciated).

Cheers.

 

[Tmagic650]

We see Netio.sys problems all the time and most of the time, the BSOD's are actually caused by something else. In your case an Nvidia driver may be the "real" problem. What anti virus are you running?

 

[Binkenstein]

Microsoft Security Essentials.

I do have stability issues whenever I upgrade the Nvidia graphics drivers, which usually requires uninstalling them completely before installing new ones.

 

[Tmagic650]

Are there any yellow (!) in the device manager? The anti virus program is good

 

[Binkenstein]

Nope. Device Manager is clean & fine, no warnings whatsoever.

 

[Tmagic650]

The funny thing is that I always update my Nvidia drivers right over the top of the old ones from here:
http://www.nvidia.com/Download/Scan.aspx?lang=en-us
With no trouble. Let the automatic scan run and see what you come up with. There is no need to un-install the old drivers manually. The install process un-installs the old driver automatically

 

[Binkenstein]

Fixed the nVidia driver update problem. Power saving settings was killing power to the PCI-E card during driver update (at the point where the screen goes black) so the computer was registering it as failing to communicate. Now updates correctly.

Still looking at the netio.sys error. Will reinstall network drivers to see if that resolves it (have latest copy from website, so re-downloaded to reinstall).

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

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


READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80002efb100
GetUlongFromAddress: unable to read from fffff80002efb1c0
0000000000000028 Nonpaged pool

CURRENT_IRQL: 2

FAULTING_IP:
NETIO!RtlCopyBufferToMdl+1d
fffff880`01a106fd 448b5228 mov r10d,dword ptr [rdx+28h]

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0xD1

PROCESS_NAME: System

TRAP_FRAME: fffff880037ae790 -- (.trap 0xfffff880037ae790)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffff880037ae9b0 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff88001a106fd rsp=fffff880037ae920 rbp=fffff880037aea48
r8=00000000ffffffbc r9=0000000000000044 r10=0000000000000000
r11=fffffa80143c9a00 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
NETIO!RtlCopyBufferToMdl+0x1d:
fffff880`01a106fd 448b5228 mov r10d,dword ptr [rdx+28h] ds:00000000`00000028=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff80002cc3169 to fffff80002cc3bc0

STACK_TEXT:
fffff880`037ae648 fffff800`02cc3169 : 00000000`0000000a 00000000`00000028 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`037ae650 fffff800`02cc1de0 : fffffa80`119d9cf0 00000000`00000006 fffffa80`119d9cf0 00000000`00000044 : nt!KiBugCheckDispatch+0x69
fffff880`037ae790 fffff880`01a106fd : fffffa80`0ca8fe20 fffff880`01a0d941 00000000`00000246 fffff800`02cad20b : nt!KiPageFault+0x260
fffff880`037ae920 fffff880`01ca84eb : 00000000`00000000 fffff880`01c76802 00000000`00000000 00000000`0000000c : NETIO!RtlCopyBufferToMdl+0x1d
fffff880`037ae980 fffff880`01c740f6 : fffffa80`143c9a00 00000000`00000000 fffffa80`0d456010 00000000`0ba2962a : tcpip! ?? ::FNODOBFM::`string'+0x1bb3f
fffff880`037ae9f0 fffff880`01c636b8 : 00000000`00000000 00000000`00000000 00000000`00000000 fffff880`01b8917b : tcpip!TcpTcbCarefulDatagram+0x1a46
fffff880`037aeba0 fffff880`01c6297a : fffffa80`0d456010 fffff880`01c5b800 fffffa80`0d69b300 fffff800`02c07593 : tcpip!TcpTcbReceive+0x37c
fffff880`037aecb0 fffff880`01c63aeb : fffff880`06ea5652 fffffa80`0d805000 00000000`00000000 fffff880`037af000 : tcpip!TcpMatchReceive+0x1fa
fffff880`037aee00 fffff880`01c5bf17 : fffffa80`0d6d9910 fffffa80`0d6ba3c5 fffffa80`0000ff77 00000000`0000ff77 : tcpip!TcpPreValidatedReceive+0x36b
fffff880`037aeed0 fffff880`01c5ba8a : 00000000`00000000 fffff880`01d69800 fffff880`037af090 00001fa0`00240000 : tcpip!IppDeliverListToProtocol+0x97
fffff880`037aef90 fffff880`01c5b089 : 00000000`00000000 00000000`00000000 00000000`00000000 fffff880`037af080 : tcpip!IppProcessDeliverList+0x5a
fffff880`037af030 fffff880`01c58d2f : 00000000`00000000 00000000`11d79100 fffff880`01d69800 fffff880`01d69800 : tcpip!IppReceiveHeaderBatch+0x23a
fffff880`037af110 fffff880`01c58302 : fffffa80`11d7d700 00000000`00000000 fffffa80`11d79100 00000000`00000001 : tcpip!IpFlcReceivePackets+0x64f
fffff880`037af310 fffff880`01ccabca : fffffa80`00000000 fffffa80`13243cd0 fffffa80`11d791a0 fffff880`037af400 : tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x2b2
fffff880`037af3f0 fffff800`02ccf878 : fffffa80`13243cd0 fffffa80`00000000 fffffa80`0c76ab50 00000000`00000001 : tcpip! ?? ::FNODOBFM::`string'+0x49ca2
fffff880`037af440 fffff880`01c57e22 : fffff880`01c57650 00000000`00000014 00000000`00000000 fffffa80`13b6f501 : nt!KeExpandKernelStackAndCalloutEx+0xd8
fffff880`037af520 fffff880`01b890eb : fffffa80`11d7c8d0 00000000`00000000 fffffa80`11af11a0 fffffa80`0d6c6858 : tcpip!FlReceiveNetBufferListChain+0xb2
fffff880`037af590 fffff880`01b52ad6 : fffffa80`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ndis!ndisMIndicateNetBufferListsToOpen+0xdb
fffff880`037af600 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ndis!ndisMDispatchReceiveNetBufferLists+0x1d6


STACK_COMMAND: kb

FOLLOWUP_IP:
NETIO!RtlCopyBufferToMdl+1d
fffff880`01a106fd 448b5228 mov r10d,dword ptr [rdx+28h]

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: NETIO!RtlCopyBufferToMdl+1d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: NETIO

IMAGE_NAME: NETIO.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 5034f6a0

FAILURE_BUCKET_ID: X64_0xD1_NETIO!RtlCopyBufferToMdl+1d

BUCKET_ID: X64_0xD1_NETIO!RtlCopyBufferToMdl+1d

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

 

[Tmagic650]

Is the network driver from Nvidia?

 

[Binkenstein]

Nope. It's a Gigabyte Intel motherboard with a standard intel X58 chipset.

However, turns out I was using the wrong lan drivers as it was identified as something else (Qualcomm Atheros AR8161/8165) so I've obtained the drivers for that & installed them.

 

[Binkenstein]

Nope. That driver upgrade still didn't resolve the issue. I'll look into upgrading all other system drivers over the weekend, but in the meantime here's the latest dump file in case anyone has a suggestion

 

[Tmagic650]

Netio.sys is the offending driver still:
http://answers.microsoft.com/en-us/...e-screen/d1b844ec-fd05-491e-8cbc-8f3050e94cc0