[SOLVED] BSOD when NIC connected to the internet

CP_TH

Distinguished
May 28, 2008
19
0
18,520
1
A few days ago, I started getting BSODs every now and then. Since then it got progressively worse up to the point that I got a BSOD as soon as Windows (7 64bit) had booted. It took me a while to figure out what was causing it: as soon as Win7 connects to the internet, it crashes soon after. If I disconnect the LAN cable, or switch Internet connection off on my cable mode, everything works just fine. When I switch off internet on my cable modem, I'm able to browse the network, move files between my computer and others on the network. But as soon as I switch on Internet connection, windows crashes.

I connected a USB NIC and if I use that, it doesn't crash.

I've removed the driver, re-downloaded it from ASUS' website (it's an onboard NIC on an ASUS Z97-A mobo), reinstalled it, but that did not help.

In MSConfig, I disabled all Startup Items. Did not help.

The Stop Error I'm getting is 0x10D (Par1: 0x06, Par2: 0x03)
 

jason201

Prominent
Feb 20, 2018
231
8
765
42
Could you attach your minidump files (as an archive)? They're located in the c:\windows\minidump folder. Is any driver (something.sys) mentioned on the BSOD?
 

Satan-IR

Honorable
Apr 18, 2014
1,473
171
11,890
168
What is your full system specs including PSU make and model?

You said BSODs started few days ago? What changed? Did you install or remove anything?

I ran that dump. The process named is Firefox.exe and some drivers. e1d68x64.sys, klwtp.sys (which I think is a Kaspersky driver) and vsdatant.sys (which I believe is a Zone Alarm firewall driver).

It's not advised to have various security software packages/suites on the system as they might be conflicting each other and when they do bad things happen; such as BSODs.

Disable or remove one of the two security applications (if indeed you are using both) and see if it helps.

I would normally suggest you update your network adapter drivers but seeing you already did and it didn't help I would also suggest you test your RAM with memtest, run with each module at a time, one by one if you have more than one.

Also from an elevated command prompt (right click CMD and click Run as administrator) run 'sfc /scannow' to see if there's file corruption.
 
Last edited:

Satan-IR

Honorable
Apr 18, 2014
1,473
171
11,890
168
Oddly enough, I don't have Zone Alarm, nor Kaspersky installed...

Sorry, my bad, I ran a similarly-named dmp.

It's a 10D bugcheck. The drivers named are LEqdUsb.Sys and LHidEqd.Sys. They have the same timestamp for installtion which suggests they were put there when you installed some software suite/application.

Which are:

LHidEqd = Tue Apr 03 21:29:39 2018
LEqdUsb.Sys = Tue Apr 03 21:29:40 2018.

They are somehow conflicting with Wdf01000.sys which is Windows drivers framework driver.

They are Logitech drivers for an HID device, or an input device mouse/keyboard or gaming input devices like a racing wheel maybe? I'd suggest updating their drivers if available.
 

CP_TH

Distinguished
May 28, 2008
19
0
18,520
1
I'd suggest you update setpoint to the latest version:
https://support.logitech.com/en_us/software/setpoint
Doing this should hopefully resolve it.
I'd suggest updating their drivers if available.
I just downloaded and installed the latest version of Logitech's SetPoint software and the BSODs have disappeared! Simply awesome! 👍👍👍

I've ran the minidumps through BlueScreenView, WhoCrashed and WinDbg myself but how can you see it was actually the Setpoint drivers that caused the problem?
 

CP_TH

Distinguished
May 28, 2008
19
0
18,520
1
I spoke too soon... :confused2:

Although it didn't crash on me for almost 12 hours (which is a huge improvement over the few minutes it took before to crash), I just got another BSOD, again 0x10D. Here's the minidump:

Minidump 2
 

jason201

Prominent
Feb 20, 2018
231
8
765
42
I spoke too soon... :confused2:

Although it didn't crash on me for almost 12 hours (which is a huge improvement over the few minutes it took before to crash), I just got another BSOD, again 0x10D. Here's the minidump:

Minidump 2
Same issue as before! Try fully removing Logitech's Setpoint and reinstalling, also , try putting the USB receiver in a different port, that might also help. If the problem remains, then I'd say it'd be best you'd replace your Logitech's mouse/keyboard with something else. In some cases, driver crashes could be related to a problem with the associated hardware (so it's possible there's something wrong with your mouse/keyboard)
 

jason201

Prominent
Feb 20, 2018
231
8
765
42
How did you get that information from the minidump? If I run Windbg, it just tells me the crash is probably caused by Wdf01000.sys.
I've also used windbg. You should first set your symbol's path with this command:
.sympath srv*https://msdl.microsoft.com/download/symbols
this part should only be done once (as it'd remember it for next time)
Then, in order to properly analyze the dump, you should do
!analyze -v
 

CP_TH

Distinguished
May 28, 2008
19
0
18,520
1
That's exactly what I do. But the output from !analyze -v makes no mention of LEqdUsb.sys...

This is the output I get:


Code:
4: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 0000000000000006, A fatal error was made in handling a WDF request. In this case,
    Parameter 2 further specifies the type of fatal error that has
    been made, as defined by the enumeration WDF_REQUEST_FATAL_ERROR.
Arg2: 0000000000000003, The driver attempted to send a framework request that has
    already been sent to an I/O target.
Arg3: 0000057ff24aace8, The WDF request handle value.
Arg4: fffffa800ce4a720, Reserved.

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


BUGCHECK_STR:  0x10D_6

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff88000e133d3 to fffff80005ae8aa0

STACK_TEXT: 
fffff880`035d2448 fffff880`00e133d3 : 00000000`0000010d 00000000`00000006 00000000`00000003 0000057f`f24aace8 : nt!KeBugCheckEx
fffff880`035d2450 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Wdf01000!FxIoTarget::SubmitLocked+0xcb


STACK_COMMAND:  kb

FOLLOWUP_IP:
Wdf01000!FxIoTarget::SubmitLocked+cb
fffff880`00e133d3 cc              int     3

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  Wdf01000!FxIoTarget::SubmitLocked+cb

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Wdf01000

IMAGE_NAME:  Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  51c51641

FAILURE_BUCKET_ID:  X64_0x10D_6_Wdf01000!FxIoTarget::SubmitLocked+cb

BUCKET_ID:  X64_0x10D_6_Wdf01000!FxIoTarget::SubmitLocked+cb

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

jason201

Prominent
Feb 20, 2018
231
8
765
42
That's exactly what I do. But the output from !analyze -v makes no mention of LEqdUsb.sys...

This is the output I get:


Code:
4: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 0000000000000006, A fatal error was made in handling a WDF request. In this case,
    Parameter 2 further specifies the type of fatal error that has
    been made, as defined by the enumeration WDF_REQUEST_FATAL_ERROR.
Arg2: 0000000000000003, The driver attempted to send a framework request that has
    already been sent to an I/O target.
Arg3: 0000057ff24aace8, The WDF request handle value.
Arg4: fffffa800ce4a720, Reserved.

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


BUGCHECK_STR:  0x10D_6

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff88000e133d3 to fffff80005ae8aa0

STACK_TEXT:
fffff880`035d2448 fffff880`00e133d3 : 00000000`0000010d 00000000`00000006 00000000`00000003 0000057f`f24aace8 : nt!KeBugCheckEx
fffff880`035d2450 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Wdf01000!FxIoTarget::SubmitLocked+0xcb


STACK_COMMAND:  kb

FOLLOWUP_IP:
Wdf01000!FxIoTarget::SubmitLocked+cb
fffff880`00e133d3 cc              int     3

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  Wdf01000!FxIoTarget::SubmitLocked+cb

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Wdf01000

IMAGE_NAME:  Wdf01000.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  51c51641

FAILURE_BUCKET_ID:  X64_0x10D_6_Wdf01000!FxIoTarget::SubmitLocked+cb

BUCKET_ID:  X64_0x10D_6_Wdf01000!FxIoTarget::SubmitLocked+cb

Followup: MachineOwner
---------
I'm not sure if we're on the same page here, were you analyzing an entirely different minidump than I did?
 

Satan-IR

Honorable
Apr 18, 2014
1,473
171
11,890
168
I spoke too soon... :confused2:

Although it didn't crash on me for almost 12 hours (which is a huge improvement over the few minutes it took before to crash), I just got another BSOD, again 0x10D. Here's the minidump:

Minidump 2

This one is a 10D bugcheck. It mentions Wdf01000.sys again. As I said before probably some drivers are conflicting with it.

Other drivers named are LEqdUsb.Sys and LHidEqd.Sys again and also nvlddmkm.sys which is a Windows driver for nvidia shaders I think.

I also noticed you have drivers/modules loaded which I think are Oracle software. VBoxUSBMon and VBoxDrv. Do you have Virtual Box installed?

This is just a guess, a hunch if you like. Do these BSODs happen by any chance when you're also running a guest OS in Virtual Box and that OS attempts to use the NIC on the host machine? IF that's the case it also might explain the Logitech drivers acting up as a guest machine tries to capture their activity through virtualization.

Have you run memtest and sfc /scannow as I specified in post $5? That post was a different dump but it might help in resolving BSODs. Determining whether there's file system corruption and whether RAM is faulty.

I'd also suggest reinstalling latest network adapter and VGA drivers for Windows and see if that helps.
 

CP_TH

Distinguished
May 28, 2008
19
0
18,520
1
I'm not sure if we're on the same page here, were you analyzing an entirely different minidump than I did?
This is the output from the first minidump in post #3.

Have you run memtest and sfc /scannow as I specified in post $5?
I haven't run memtest yet, but I did run sfc /scannow and it didn't find any problems.

I'd also suggest reinstalling latest network adapter and VGA drivers for Windows and see if that helps
I already reinstalled the latest network drivers. Haven't updated the NVidia yet. Will do so now.

I also noticed you have drivers/modules loaded which I think are Oracle software. VBoxUSBMon and VBoxDrv. Do you have Virtual Box installed?
Yes I do.

This is just a guess, a hunch if you like. Do these BSODs happen by any chance when you're also running a guest OS in Virtual Box and that OS attempts to use the NIC on the host machine?
No, I'm not running any VMs. The BSODs happen as soon as the NIC connects to the internet. So if I switch off my cable modem, I don't get a BSOD and I can browse the network just fine. Switching it back on and I get a BSOD. The computer first becomes unresponsive, then after a few minutes I get a BSOD.
 

jason201

Prominent
Feb 20, 2018
231
8
765
42
This is the output from the first minidump in post #3
That's definitely not what my windbg is showing, I'd say you're doing something wrong, here's the full output on my end:


Microsoft (R) Windows Debugger Version 10.0.17134.12 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\dumpcheck\061019-39593-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available


Path validation summary *
Response Time (ms) Location
Deferred srv*https://msdl.microsoft.com/download/symbols
Symbol search path is: srv*https://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.24441.amd64fre.win7sp1_ldr.190418-1735
Machine Name:
Kernel base = 0xfffff80005a55000 PsLoadedModuleList = 0xfffff80005c8ec90
Debug session time: Mon Jun 10 09:31:50.223 2019 (UTC + 2:00)
System Uptime: 0 days 0:13:53.035
Loading Kernel Symbols
...............................................................
................................................................
................................................................
........
Loading User Symbols
Loading unloaded module list
...........
***
  • *
  • Bugcheck Analysis *
  • *
***

Use !analyze -v to get detailed debugging information.

BugCheck 10D, {6, 3, 57ff24aace8, fffffa800ce4a720}

*** WARNING: Unable to verify timestamp for LEqdUsb.Sys
*** ERROR: Module load completed but symbols could not be loaded for LEqdUsb.Sys
Probably caused by : LEqdUsb.Sys ( LEqdUsb+6e0a )

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

4: kd> !analyze -v
***
  • *
  • Bugcheck Analysis *
  • *
***

WDF_VIOLATION (10d)
The Kernel-Mode Driver Framework was notified that Windows detected an error
in a framework-based driver. In general, the dump file will yield additional
information about the driver that caused this bug check.
Arguments:
Arg1: 0000000000000006, A fatal error was made in handling a WDF request. In this case,
Parameter 2 further specifies the type of fatal error that has
been made, as defined by the enumeration WDF_REQUEST_FATAL_ERROR.
Arg2: 0000000000000003, The driver attempted to send a framework request that has
already been sent to an I/O target.
Arg3: 0000057ff24aace8, The WDF request handle value.
Arg4: fffffa800ce4a720, Reserved.

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


KEY_VALUES_STRING: 1


TIMELINE_ANALYSIS: 1


DUMP_CLASS: 1

DUMP_QUALIFIER: 400

BUILD_VERSION_STRING: 7601.24441.amd64fre.win7sp1_ldr.190418-1735

SYSTEM_MANUFACTURER: ASUS

SYSTEM_PRODUCT_NAME: All Series

SYSTEM_SKU: All

SYSTEM_VERSION: System Version

BIOS_VENDOR: American Megatrends Inc.

BIOS_VERSION: 1204

BIOS_DATE: 06/20/2014

BASEBOARD_MANUFACTURER: ASUSTeK COMPUTER INC.

BASEBOARD_PRODUCT: Z97-A

BASEBOARD_VERSION: Rev 1.xx

DUMP_TYPE: 2

BUGCHECK_P1: 6

BUGCHECK_P2: 3

BUGCHECK_P3: 57ff24aace8

BUGCHECK_P4: fffffa800ce4a720

BUGCHECK_STR: 0x10D_6

CPU_COUNT: 8

CPU_MHZ: 1195

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3c

CPU_STEPPING: 3

CPU_MICROCODE: 6,3c,3,0 (F,M,S,R) SIG: 1C'00000000 (cache) 19'00000000 (init)

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_SESSION_HOST: JASON-PC

ANALYSIS_SESSION_TIME: 06-12-2019 20:14:31.0098

ANALYSIS_VERSION: 10.0.17134.12 amd64fre

LAST_CONTROL_TRANSFER: from fffff88000e133d3 to fffff80005ae8aa0

STACK_TEXT:
fffff880035d2448 fffff88000e133d3 : 000000000000010d 0000000000000006 0000000000000003 0000057ff24aace8 : nt!KeBugCheckEx
fffff880035d2450 fffff88000e11384 : 0000000000000000 fffffa800e615d30 0000000000000000 fffffa800db55020 : Wdf01000!FxIoTarget::SubmitLocked+0xcb
fffff880035d2500 fffff88000e12082 : 0000057ff1996a08 fffffa800db55310 fffff880035d2590 fffffa800e6695f0 : Wdf01000!FxIoTarget::Submit+0x60
fffff880035d2540 fffff88006316e0a : fffffa800ce4a8a0 fffffa800db55310 fffffa800db55020 fffffa800ce4a720 : Wdf01000!imp_WdfRequestSend+0x48e
fffff880035d25d0 fffffa800ce4a8a0 : fffffa800db55310 fffffa800db55020 fffffa800ce4a720 0000057ff19ea328 : LEqdUsb+0x6e0a
fffff880035d25d8 fffffa800db55310 : fffffa800db55020 fffffa800ce4a720 0000057ff19ea328 0000000000000000 : 0xfffffa800ce4a8a0
fffff880
035d25e0 fffffa800db55020 : fffffa800ce4a720 0000057ff19ea328 0000000000000000 0000000000000000 : 0xfffffa800db55310
fffff880035d25e8 fffffa800ce4a720 : 0000057ff19ea328 0000000000000000 0000000000000000 0000000000000000 : 0xfffffa800db55020
fffff880
035d25f0 0000057ff19ea328 : 0000000000000000 0000000000000000 0000000000000000 fffffa800ded52d0 : 0xfffffa800ce4a720
fffff880035d25f8 0000000000000000 : 0000000000000000 0000000000000000 fffffa800ded52d0 0000057ff24aafd8 : 0x0000057ff19ea328


THREAD_SHA1_HASH_MOD_FUNC: 2058e7c4c679671758a7ec6ccc48d4b5079596f7

THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 11d18080234e6723a5beed022680b9b18dace760

THREAD_SHA1_HASH_MOD: 5b7dde6a01f5a21cc18feebd6094981fabc185cd

FOLLOWUP_IP:
LEqdUsb+6e0a
fffff880
06316e0a ?? ???

SYMBOL_STACK_INDEX: 4

SYMBOL_NAME: LEqdUsb+6e0a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: LEqdUsb

IMAGE_NAME: LEqdUsb.Sys

DEBUG_FLR_IMAGE_TIMESTAMP: 5ac3b2fc

STACK_COMMAND: .thread ; .cxr ; kb

FAILURE_BUCKET_ID: X64_0x10D_6_LEqdUsb+6e0a

BUCKET_ID: X64_0x10D_6_LEqdUsb+6e0a

PRIMARY_PROBLEM_CLASS: X64_0x10D_6_LEqdUsb+6e0a

TARGET_TIME: 2019-06-10T07:31:50.000Z

OSBUILD: 7601

OSSERVICEPACK: 1000

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK: 272

PRODUCT_TYPE: 1

OSPLATFORM_TYPE: x64

OSNAME: Windows 7

OSEDITION: Windows 7 WinNt (Service Pack 1) TerminalServer SingleUserTS

OS_LOCALE:

USER_LCID: 0

OSBUILD_TIMESTAMP: 2019-04-19 04:08:54

BUILDDATESTAMP_STR: 190418-1735

BUILDLAB_STR: win7sp1_ldr

BUILDOSVER_STR: 6.1.7601.24441.amd64fre.win7sp1_ldr.190418-1735

ANALYSIS_SESSION_ELAPSED_TIME: 31d

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:x64_0x10d_6_leqdusb+6e0a

FAILURE_ID_HASH: {32175d8c-281a-17da-b948-77e6640b7865}

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

Again I say, this is 100% related to Logitech's setpoint (fact is that there's been a dramatic improvement after you've updated it!) and both minidumps (3rd & 11th post) are showing LEqdUsb.Sys as the cause.
 

CP_TH

Distinguished
May 28, 2008
19
0
18,520
1
Aaaaaaahhhh... Apparently I have a very, very old version of Windbg...I have version 6.1 from 2009... 🙈

I'll install the latest version. Thanks!

Edit:
Yep. Now I see (almost) the same thing you do. :)
 
Last edited:

ASK THE COMMUNITY

TRENDING THREADS