All of the attached DMP files are of the DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
This indicates that a kernel-mode driver attempted to access pageable memory at a process IRQL that was too high.
A driver tried to access an address that is pageable (or that is completely invalid) while the IRQL was too high. This bug check is usually caused by drivers that have used improper addresses.
If we look at the call stack:
0: kd> kv
Child-SP RetAddr : Args to Child : Call Site
fffff880`0351c6a8 fffff800`02edd129 : 00000000`0000000a 00000000`00000028 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`0351c6b0 fffff800`02edbda0 : fffffa80`08212a78 fffffa80`08212010 fffffa80`0815e300 00000000`00000044 : nt!KiBugCheckDispatch+0x69
fffff880`0351c7f0 fffff880`018106fd : 00000000`00000047 fffff880`01a169dc 00000000`0000000d fffffa80`03dcde68 : nt!KiPageFault+0x260 (TrapFrame @ fffff880`0351c7f0)
fffff880`0351c980 fffff880`01aa60bc : 00000000`00000000 fffff880`01a74876 00000000`00000000 fffff880`04b7500f : NETIO!RtlCopyBufferToMdl+0x1d
fffff880`0351c9e0 fffff880`01a72393 : fffffa80`0a18a340 00000000`00000000 fffffa80`040e4190 00000000`262d0515 : tcpip! ?? ::FNODOBFM::`string'+0x1cadf
fffff880`0351ca50 fffff880`01a612c4 : fffff880`0351cf08 fffffa80`00000029 fffffa80`040e4190 00000000`00000001 : tcpip!TcpTcbCarefulDatagram+0x1aa3
fffff880`0351cc00 fffff880`01a6075a : fffffa80`04ba0f00 fffff880`01a59634 fffffa80`04b56548 00000000`00000000 : tcpip!TcpTcbReceive+0x694
fffff880`0351cdb0 fffff880`01a61cfb : fffff880`0577b070 fffffa80`04b8f000 00000000`00000000 fffff880`0351d100 : tcpip!TcpMatchReceive+0x1fa
fffff880`0351cf00 fffff880`01a59cc7 : fffffa80`04ba0f00 fffffa80`04ba9ddd fffffa80`00001bfd 00000000`00001bfd : tcpip!TcpPreValidatedReceive+0x36b
fffff880`0351cfd0 fffff880`01a5983a : 00000000`00000000 fffff880`01b69800 fffff880`0351d190 fffffa80`09824300 : tcpip!IppDeliverListToProtocol+0x97
fffff880`0351d090 fffff880`01a58e39 : fffff880`0351d258 00000000`00000000 00000000`00000002 fffff880`0351d180 : tcpip!IppProcessDeliverList+0x5a
fffff880`0351d130 fffff880`01a56adf : 00000000`00000000 00000000`07985b00 fffff880`01b69800 fffff880`01b69800 : tcpip!IppReceiveHeaderBatch+0x23a
fffff880`0351d210 fffff880`01a560b2 : fffffa80`05077290 00000000`00000000 fffffa80`07985b00 00000000`00000001 : tcpip!IpFlcReceivePackets+0x64f
fffff880`0351d410 fffff880`01aca93a : fffffa80`00000000 fffffa80`04221440 fffffa80`07985ba0 fffff880`0351d500 : tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x2b2
fffff880`0351d4f0 fffff800`02ee9878 : fffffa80`04221440 fffffa80`04b7bcec fffffa80`03cc7040 00000000`00000001 : tcpip! ?? ::FNODOBFM::`string'+0x4c812
fffff880`0351d540 fffff880`01a55bd2 : fffff880`01a55400 00000000`00000014 00000000`00000000 fffffa80`03e40901 : nt!KeExpandKernelStackAndCalloutEx+0xd8
fffff880`0351d620 fffff880`019a40eb : fffffa80`07985460 00000000`00000000 fffffa80`0745e1a0 00000000`00000000 : tcpip!FlReceiveNetBufferListChain+0xb2
fffff880`0351d690 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ndis!ndisMIndicateNetBufferListsToOpen+0xdb
We can see various network related routines being called (tcpip.sys, NETIO.sys, etc). The culprit throughout the dumps is always labeled as NETIO.sys as that's the consistent driver routine right before the pagefault that goes into the bugcheck which you can see in the stack above.
Usually when we have network crashes like this it's due to 3rd party antivirus / firewall software causing conflicts. It's also possible there are 3rd party device driver(s) causing corruption or conflicts as well.
Please enable Driver Verifier to look for further possible software corruption and or conflicts:
What is Driver Verifier?
Driver Verifier is included in Windows 8, 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows 2000, Windows XP, and Windows Server 2003 to promote stability and reliability; you can use this tool to troubleshoot driver issues. Windows kernel-mode components can cause system corruption or system failures as a result of an improperly written driver, such as an earlier version of a Windows Driver Model (WDM) driver.
Essentially, if there's a 3rd party driver believed to be at issue, enabling Driver Verifier will help flush out the rogue driver if it detects a violation.
Before enabling Driver Verifier, it is recommended to create a System Restore Point:
Vista - START | type rstrui - create a restore point
Windows 7 - START | type create | select "Create a Restore Point"
Windows 8 - Restore Point - Create in Windows 8
How to enable Driver Verifier:
Start > type "verifier" without the quotes > Select the following options -
1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (Windows 7 & 8)
- DDI compliance checking (Windows 8)
- Miscellaneous Checks
4. Select - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is NOT
provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
Important information regarding Driver Verifier:
- If Driver Verifier finds a violation, the system will BSOD.
- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will flag it, and as stated above, that will cause / force a BSOD.
If this happens, do not
panic, do the following:
- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.
- Once in Safe Mode - Start > type "system restore" without the quotes.
- Choose the restore point you created earlier.
If you did not set up a restore point, do not worry, you can still disable Driver Verifier to get back into normal Windows:
- Start > Search > type "cmd" without the quotes.
- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.
・ Restart and boot into normal Windows.
How long should I keep Driver Verifier enabled for?
It varies, many experts and analysts have different recommendations. Personally, I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier.
My system BSOD'd, where can I find the crash dumps?
They will be located in %systemroot%\Minidump
Any other questions can most likely be answered by this article:
Using Driver Verifier to identify issues with Windows drivers for advanced users