Question Watchdog Violation BSOD only while gaming ? - - most recent mini-dump attached.

Toggle sidebar Toggle sidebar
M

MetalMatty

Honorable
Apr 20, 2017
76
2
10,535
Hello,

Windows 11 system.
Ryzen 5600X
3070Ti
16GB 3200 RAM

Over the last couple of months I've had crashes while gaming, and generally only in very graphically intensive games, think BF2042 or Starfield. The system will lock up, then BSOD and while that is happening, the GPU fans will ramp up crazy. I assume this is a dying 3070Ti, but before I figure out a plan there I wanted to get some opinions from people smarter than I am before I either send this one in for RMA or buy a replacement.

I've attached the minidump file from the last crash, which happened about 15 minutes ago, 9/9/23 at 12:30PM. I opened it with a debugger program but honestly I couldn't make enough sense of it to figure it out.

090923-5171-01.dmp

drive.google.com drive.google.com

Thanks for any help!
 
One dump isn't really enough on which to base a reliable diagnosis, are there other minidumps in the folder C:\Windows\Minidump? If so upload them all please.

FWIW there is no indication in that one dump of a GPU issue. The operation in progress just before the bugcheck was a networking operation. We see the Windows drivers tcpip.sys and ndis.sys called, there are also calls to the Windows storage drivers storport.sys and stornvme.sys. It looks as though a networking send was in progress, reading data from an NVMe SSD drive.

It's difficult from this dump to know what caused this BSOD. It may have been a third-party network adapter driver, or it may have been an issue with the NVMe drive. Try removing and re-seating the NVMe drive, I've seen lots of niggly issues that were resolved by re-seating an M.2 drive.

I would also suggest running Windows Update and checking under the 'View optional updates' link for any driver updates. If you're not sure which of those you should install then post a screenshot. If there are any for your network adapter however, then definitely install those.
 
ubuysa said:
One dump isn't really enough on which to base a reliable diagnosis, are there other minidumps in the folder C:\Windows\Minidump? If so upload them all please.

FWIW there is no indication in that one dump of a GPU issue. The operation in progress just before the bugcheck was a networking operation. We see the Windows drivers tcpip.sys and ndis.sys called, there are also calls to the Windows storage drivers storport.sys and stornvme.sys. It looks as though a networking send was in progress, reading data from an NVMe SSD drive.

It's difficult from this dump to know what caused this BSOD. It may have been a third-party network adapter driver, or it may have been an issue with the NVMe drive. Try removing and re-seating the NVMe drive, I've seen lots of niggly issues that were resolved by re-seating an M.2 drive.

I would also suggest running Windows Update and checking under the 'View optional updates' link for any driver updates. If you're not sure which of those you should install then post a screenshot. If there are any for your network adapter however, then definitely install those.
Click to expand...
My computer must have known you were going to ask for more because it crashed 2 or 3 more times after I made this post, one of which while I was just chilling on desktop.

https://drive.google.com/drive/folders/1Crx0JTTVUNs5c8rBVuv68YGVNhtg9O7x?usp=sharing I reshared the link in case Drive goes stupid, but there should be more dumps there now.

I took off and reseated both of my NVME drives, and I completely unplugged my old dying HDD that was just there as a backup drive.

I did a Windows Update with optional updates too and will keep using computer like normal to see if it still crashes at random.
 
Ah, more dumps is always better! All those dumps are networking related, just like the first one. Fortunately one of them fingers the likely faulty driver. It's this dump...
Code: 
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: ffffa4039fd06060, Physical Device Object of the stack
Arg3: ffffdd0823f377b8, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffffa403a49118a0, The blocked IRP
This BSOD happened because a device failed to complete a power transition. Argument 2 contains the device object address of the failing device and if we display that device object...
Code: 
11: kd> !devobj ffffa4039fd06060
Device object (ffffa4039fd06060) is for:
 Cannot read info offset from nt!ObpInfoMaskToOffset
 \Driver\pci DriverObject ffffa4039e50ed50
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00001040
SecurityDescriptor ffffe206d4edc960 DevExt ffffa4039fd061b0 DevObjExt ffffa4039fd06970 DevNode ffffa4039fd06a20
ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000100)  FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffffa4039fca9de0 \Driver\ACPI
Device queue is not busy.
The most useful information in there is the address of the device node (the DevNode) which describes the actual device. Displaying the device node gives...
Code: 
11: kd> !devnode ffffa4039fd06a20
DevNode 0xffffa4039fd06a20 for PDO 0xffffa4039fd06060
  Parent 0xffffa4039fc1aa20   Sibling 0000000000   Child 0000000000
  InstancePath is "PCI\VEN_10EC&DEV_8168&SUBSYS_E0001458&REV_16\E1C440992EB4000000"
  ServiceName is "rtcx21"
  State = DeviceNodeStarted (0x30a)
  Previous State = DeviceNodeEnumerateCompletion (0x30f)
  StateHistory[15] = DeviceNodeEnumerateCompletion (0x30f)
  StateHistory[14] = DeviceNodeEnumeratePending (0x30e)
  StateHistory[13] = DeviceNodeStarted (0x30a)
  StateHistory[12] = DeviceNodeEnumerateCompletion (0x30f)
  StateHistory[11] = DeviceNodeEnumeratePending (0x30e)
  StateHistory[10] = DeviceNodeStarted (0x30a)
  StateHistory[09] = DeviceNodeEnumerateCompletion (0x30f)
  StateHistory[08] = DeviceNodeEnumeratePending (0x30e)
  StateHistory[07] = DeviceNodeStarted (0x30a)
  StateHistory[06] = DeviceNodeStartPostWork (0x309)
  StateHistory[05] = DeviceNodeStartCompletion (0x308)
  StateHistory[04] = DeviceNodeStartPending (0x307)
  StateHistory[03] = DeviceNodeResourcesAssigned (0x306)
  StateHistory[02] = DeviceNodeDriversAdded (0x305)
  StateHistory[01] = DeviceNodeInitialized (0x304)
  StateHistory[00] = DeviceNodeUninitialized (0x301)
  StateHistory[19] = Unknown State (0x0)
  StateHistory[18] = Unknown State (0x0)
  StateHistory[17] = Unknown State (0x0)
  StateHistory[16] = Unknown State (0x0)
  Flags (0x6c000070)  DNF_ENUMERATED, DNF_IDS_QUERIED,
                      DNF_HAS_BOOT_CONFIG, DNF_NO_LOWER_DEVICE_FILTERS,
                      DNF_NO_LOWER_CLASS_FILTERS, DNF_NO_UPPER_DEVICE_FILTERS,
                      DNF_NO_UPPER_CLASS_FILTERS
  CapabilityFlags (0x00403c43)  DeviceD1, DeviceD2,
                                UniqueID, WakeFromD0,
                                WakeFromD1, WakeFromD2,
                                WakeFromD3
                                Unknown flags 0x00400000
The key data there is the VEN & DEV identifiers. If you lookup VEN_10EC&DEV_8168 you'll find it's a Realtek-based PCI Express Gigabit Ethernet Controller. The call stack in the dump also identifies the driver, it's rtcx21x64.sys - the PCI Express Gigabit Ethernet Controller driver and the version you have installed is a couple of years old...
Code: 
                                Unknown flags 0x00400000
11: kd> lmDvm rtcx21x64
Browse full module list
start             end                 module name
fffff802`317b0000 fffff802`31838000   rtcx21x64   (pdb symbols)          c:\mysymbols\rtcx21x64.pdb\304D83AE7601452DA3F4A3C52D26DF351\rtcx21x64.pdb
    Loaded symbol image file: rtcx21x64.sys
    Mapped memory image file: c:\mysymbols\rtcx21x64.sys\615AA51C88000\rtcx21x64.sys
    Image path: \SystemRoot\System32\DriverStore\FileRepository\rtcx21x64.inf_amd64_516e5c9b75c49dc2\rtcx21x64.sys
    Image name: rtcx21x64.sys
    Browse all global symbols  functions  data
    Timestamp:        Mon Oct  4 09:54:20 2021 (615AA51C)
    CheckSum:         0008BAF4
    ImageSize:        00088000
    File version:     1.0.0.14
    Product version:  10.0.10011.16384
    File flags:       8 (Mask 3F) Private
    File OS:          40004 NT Win32
    File type:        3.6 Driver
    File date:        00000000.00000000
    Translations:     0000.04b0
    Information from resource tables:
        CompanyName:      Realtek                                     
        ProductName:      Realtek PCIe Adapter                                     
        InternalName:     rtcx21x64.sys
        OriginalFilename: rtcx21x64.sys
        ProductVersion:   1.0.0.14
        FileVersion:      1.0.0.14
        FileDescription:  Realtek NetAdapter Driver                                     
        LegalCopyright:   Copyright (C) 2021 Realtek Semiconductor Corporation. All Rights Reserved.
You need to look for an update for that LAN driver. Run Windows Update and look in the 'View optional updates' link for driver updates, if there's one for your LAN adapter then install it.
 
ubuysa said:
Ah, more dumps is always better! All those dumps are networking related, just like the first one. Fortunately one of them fingers the likely faulty driver. It's this dump...
Code: 
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: ffffa4039fd06060, Physical Device Object of the stack
Arg3: ffffdd0823f377b8, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffffa403a49118a0, The blocked IRP
This BSOD happened because a device failed to complete a power transition. Argument 2 contains the device object address of the failing device and if we display that device object...
Code: 
11: kd> !devobj ffffa4039fd06060
Device object (ffffa4039fd06060) is for:
 Cannot read info offset from nt!ObpInfoMaskToOffset
 \Driver\pci DriverObject ffffa4039e50ed50
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00001040
SecurityDescriptor ffffe206d4edc960 DevExt ffffa4039fd061b0 DevObjExt ffffa4039fd06970 DevNode ffffa4039fd06a20
ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000100)  FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffffa4039fca9de0 \Driver\ACPI
Device queue is not busy.
The most useful information in there is the address of the device node (the DevNode) which describes the actual device. Displaying the device node gives...
Code: 
11: kd> !devnode ffffa4039fd06a20
DevNode 0xffffa4039fd06a20 for PDO 0xffffa4039fd06060
  Parent 0xffffa4039fc1aa20   Sibling 0000000000   Child 0000000000
  InstancePath is "PCI\VEN_10EC&DEV_8168&SUBSYS_E0001458&REV_16\E1C440992EB4000000"
  ServiceName is "rtcx21"
  State = DeviceNodeStarted (0x30a)
  Previous State = DeviceNodeEnumerateCompletion (0x30f)
  StateHistory[15] = DeviceNodeEnumerateCompletion (0x30f)
  StateHistory[14] = DeviceNodeEnumeratePending (0x30e)
  StateHistory[13] = DeviceNodeStarted (0x30a)
  StateHistory[12] = DeviceNodeEnumerateCompletion (0x30f)
  StateHistory[11] = DeviceNodeEnumeratePending (0x30e)
  StateHistory[10] = DeviceNodeStarted (0x30a)
  StateHistory[09] = DeviceNodeEnumerateCompletion (0x30f)
  StateHistory[08] = DeviceNodeEnumeratePending (0x30e)
  StateHistory[07] = DeviceNodeStarted (0x30a)
  StateHistory[06] = DeviceNodeStartPostWork (0x309)
  StateHistory[05] = DeviceNodeStartCompletion (0x308)
  StateHistory[04] = DeviceNodeStartPending (0x307)
  StateHistory[03] = DeviceNodeResourcesAssigned (0x306)
  StateHistory[02] = DeviceNodeDriversAdded (0x305)
  StateHistory[01] = DeviceNodeInitialized (0x304)
  StateHistory[00] = DeviceNodeUninitialized (0x301)
  StateHistory[19] = Unknown State (0x0)
  StateHistory[18] = Unknown State (0x0)
  StateHistory[17] = Unknown State (0x0)
  StateHistory[16] = Unknown State (0x0)
  Flags (0x6c000070)  DNF_ENUMERATED, DNF_IDS_QUERIED,
                      DNF_HAS_BOOT_CONFIG, DNF_NO_LOWER_DEVICE_FILTERS,
                      DNF_NO_LOWER_CLASS_FILTERS, DNF_NO_UPPER_DEVICE_FILTERS,
                      DNF_NO_UPPER_CLASS_FILTERS
  CapabilityFlags (0x00403c43)  DeviceD1, DeviceD2,
                                UniqueID, WakeFromD0,
                                WakeFromD1, WakeFromD2,
                                WakeFromD3
                                Unknown flags 0x00400000
The key data there is the VEN & DEV identifiers. If you lookup VEN_10EC&DEV_8168 you'll find it's a Realtek-based PCI Express Gigabit Ethernet Controller. The call stack in the dump also identifies the driver, it's rtcx21x64.sys - the PCI Express Gigabit Ethernet Controller driver and the version you have installed is a couple of years old...
Code: 
                                Unknown flags 0x00400000
11: kd> lmDvm rtcx21x64
Browse full module list
start             end                 module name
fffff802`317b0000 fffff802`31838000   rtcx21x64   (pdb symbols)          c:\mysymbols\rtcx21x64.pdb\304D83AE7601452DA3F4A3C52D26DF351\rtcx21x64.pdb
    Loaded symbol image file: rtcx21x64.sys
    Mapped memory image file: c:\mysymbols\rtcx21x64.sys\615AA51C88000\rtcx21x64.sys
    Image path: \SystemRoot\System32\DriverStore\FileRepository\rtcx21x64.inf_amd64_516e5c9b75c49dc2\rtcx21x64.sys
    Image name: rtcx21x64.sys
    Browse all global symbols  functions  data
    Timestamp:        Mon Oct  4 09:54:20 2021 (615AA51C)
    CheckSum:         0008BAF4
    ImageSize:        00088000
    File version:     1.0.0.14
    Product version:  10.0.10011.16384
    File flags:       8 (Mask 3F) Private
    File OS:          40004 NT Win32
    File type:        3.6 Driver
    File date:        00000000.00000000
    Translations:     0000.04b0
    Information from resource tables:
        CompanyName:      Realtek                                   
        ProductName:      Realtek PCIe Adapter                                   
        InternalName:     rtcx21x64.sys
        OriginalFilename: rtcx21x64.sys
        ProductVersion:   1.0.0.14
        FileVersion:      1.0.0.14
        FileDescription:  Realtek NetAdapter Driver                                   
        LegalCopyright:   Copyright (C) 2021 Realtek Semiconductor Corporation. All Rights Reserved.
You need to look for an update for that LAN driver. Run Windows Update and look in the 'View optional updates' link for driver updates, if there's one for your LAN adapter then install it.
Click to expand...
Wow! Thank you for the assistance!

So far, the only optional Windows Update was just a Cumulative Preview Update.

I'm currently downloading the most recent Realtek GBE Family Controller Driver for Windows 11 to see if maybe manually updating it will work.

I guess I'll let you know if that ends up taking care of it!

Realtek Gaming GbE Family Controller is now updated to 1168.15.715.2023, which is just a hair over two years newer than the driver that was installed. Fingers crossed!
 
ubuysa said:
Ah, more dumps is always better! All those dumps are networking related, just like the first one. Fortunately one of them fingers the likely faulty driver. It's this dump...
Code: 
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: ffffa4039fd06060, Physical Device Object of the stack
Arg3: ffffdd0823f377b8, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffffa403a49118a0, The blocked IRP
This BSOD happened because a device failed to complete a power transition. Argument 2 contains the device object address of the failing device and if we display that device object...
Code: 
11: kd> !devobj ffffa4039fd06060
Device object (ffffa4039fd06060) is for:
 Cannot read info offset from nt!ObpInfoMaskToOffset
 \Driver\pci DriverObject ffffa4039e50ed50
Current Irp 00000000 RefCount 0 Type 00000022 Flags 00001040
SecurityDescriptor ffffe206d4edc960 DevExt ffffa4039fd061b0 DevObjExt ffffa4039fd06970 DevNode ffffa4039fd06a20
ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT
Characteristics (0x00000100)  FILE_DEVICE_SECURE_OPEN
AttachedDevice (Upper) ffffa4039fca9de0 \Driver\ACPI
Device queue is not busy.
The most useful information in there is the address of the device node (the DevNode) which describes the actual device. Displaying the device node gives...
Code: 
11: kd> !devnode ffffa4039fd06a20
DevNode 0xffffa4039fd06a20 for PDO 0xffffa4039fd06060
  Parent 0xffffa4039fc1aa20   Sibling 0000000000   Child 0000000000
  InstancePath is "PCI\VEN_10EC&DEV_8168&SUBSYS_E0001458&REV_16\E1C440992EB4000000"
  ServiceName is "rtcx21"
  State = DeviceNodeStarted (0x30a)
  Previous State = DeviceNodeEnumerateCompletion (0x30f)
  StateHistory[15] = DeviceNodeEnumerateCompletion (0x30f)
  StateHistory[14] = DeviceNodeEnumeratePending (0x30e)
  StateHistory[13] = DeviceNodeStarted (0x30a)
  StateHistory[12] = DeviceNodeEnumerateCompletion (0x30f)
  StateHistory[11] = DeviceNodeEnumeratePending (0x30e)
  StateHistory[10] = DeviceNodeStarted (0x30a)
  StateHistory[09] = DeviceNodeEnumerateCompletion (0x30f)
  StateHistory[08] = DeviceNodeEnumeratePending (0x30e)
  StateHistory[07] = DeviceNodeStarted (0x30a)
  StateHistory[06] = DeviceNodeStartPostWork (0x309)
  StateHistory[05] = DeviceNodeStartCompletion (0x308)
  StateHistory[04] = DeviceNodeStartPending (0x307)
  StateHistory[03] = DeviceNodeResourcesAssigned (0x306)
  StateHistory[02] = DeviceNodeDriversAdded (0x305)
  StateHistory[01] = DeviceNodeInitialized (0x304)
  StateHistory[00] = DeviceNodeUninitialized (0x301)
  StateHistory[19] = Unknown State (0x0)
  StateHistory[18] = Unknown State (0x0)
  StateHistory[17] = Unknown State (0x0)
  StateHistory[16] = Unknown State (0x0)
  Flags (0x6c000070)  DNF_ENUMERATED, DNF_IDS_QUERIED,
                      DNF_HAS_BOOT_CONFIG, DNF_NO_LOWER_DEVICE_FILTERS,
                      DNF_NO_LOWER_CLASS_FILTERS, DNF_NO_UPPER_DEVICE_FILTERS,
                      DNF_NO_UPPER_CLASS_FILTERS
  CapabilityFlags (0x00403c43)  DeviceD1, DeviceD2,
                                UniqueID, WakeFromD0,
                                WakeFromD1, WakeFromD2,
                                WakeFromD3
                                Unknown flags 0x00400000
The key data there is the VEN & DEV identifiers. If you lookup VEN_10EC&DEV_8168 you'll find it's a Realtek-based PCI Express Gigabit Ethernet Controller. The call stack in the dump also identifies the driver, it's rtcx21x64.sys - the PCI Express Gigabit Ethernet Controller driver and the version you have installed is a couple of years old...
Code: 
                                Unknown flags 0x00400000
11: kd> lmDvm rtcx21x64
Browse full module list
start             end                 module name
fffff802`317b0000 fffff802`31838000   rtcx21x64   (pdb symbols)          c:\mysymbols\rtcx21x64.pdb\304D83AE7601452DA3F4A3C52D26DF351\rtcx21x64.pdb
    Loaded symbol image file: rtcx21x64.sys
    Mapped memory image file: c:\mysymbols\rtcx21x64.sys\615AA51C88000\rtcx21x64.sys
    Image path: \SystemRoot\System32\DriverStore\FileRepository\rtcx21x64.inf_amd64_516e5c9b75c49dc2\rtcx21x64.sys
    Image name: rtcx21x64.sys
    Browse all global symbols  functions  data
    Timestamp:        Mon Oct  4 09:54:20 2021 (615AA51C)
    CheckSum:         0008BAF4
    ImageSize:        00088000
    File version:     1.0.0.14
    Product version:  10.0.10011.16384
    File flags:       8 (Mask 3F) Private
    File OS:          40004 NT Win32
    File type:        3.6 Driver
    File date:        00000000.00000000
    Translations:     0000.04b0
    Information from resource tables:
        CompanyName:      Realtek                                    
        ProductName:      Realtek PCIe Adapter                                    
        InternalName:     rtcx21x64.sys
        OriginalFilename: rtcx21x64.sys
        ProductVersion:   1.0.0.14
        FileVersion:      1.0.0.14
        FileDescription:  Realtek NetAdapter Driver                                    
        LegalCopyright:   Copyright (C) 2021 Realtek Semiconductor Corporation. All Rights Reserved.
You need to look for an update for that LAN driver. Run Windows Update and look in the 'View optional updates' link for driver updates, if there's one for your LAN adapter then install it.
Click to expand...
Well, unfortunately I'm back. Computer was fine since the last update, but while it was just on the desktop and I was cooking dinner, I came back to it rebooted with a new crash log and minidump. I've uploaded it to the same Drive folder, but I'll repost the link if you're still up for digging into it.

MiniDump – Google Drive

drive.google.com drive.google.com
 
This dump is a 0x133, a DPC_WATCHDOG_VIOLATION with an argument 1 value of zero. That indicates that a DPC ran for too long. (A DPC is a Deferred Procedure Call, it's a type of work item typically used for running the back-end of a device interrupt, the DPC code is part of the device driver). DPCs run when a processor has no other work to run, but because they effectively lock-out other work from the processor, they are not allowed to run for too long (typically 100 microseconds). If a DPC does exceed this time the watchdog BSODs the system (because it's uncertain exactly what is going on).

In the call stack we can clearly see that a networking operation was in progress, the Windows netio.sys, ndis.sys and tcpip.sys drivers are called often. This of course means that this 0x133 bugcheck failed in the same general area as the earlier 0x9F bugcheck. Although we don't see the LAN adapter driver (rtcx21x64.sys) referenced in the call stack it must clearly have been involved. It will have been called by tcpip.sys in order to get the network transfer done.

If you're running the latest driver then one would have to suspect the LAN adapter hardware. Though I think it's remotely possible that an issue with your router could hold up a data transfer and thus hold up the DPC. It would be worth powering your router off and on again to clear anything in there.

You might also try connecting via WiFi for a time to see whether this stops the BSODs. If you're going to do that then first disable the LAN adapter in Device Manager and then reboot (to ensure that the rtcx21x64.sys driver is not loaded).

The only other thing I can suggest is borrowing a USB LAN adapter and see whether that suffers BSODs (disable the on-board LAN adapter and reboot again if you do try this).
 
ubuysa said:
This dump is a 0x133, a DPC_WATCHDOG_VIOLATION with an argument 1 value of zero. That indicates that a DPC ran for too long. (A DPC is a Deferred Procedure Call, it's a type of work item typically used for running the back-end of a device interrupt, the DPC code is part of the device driver). DPCs run when a processor has no other work to run, but because they effectively lock-out other work from the processor, they are not allowed to run for too long (typically 100 microseconds). If a DPC does exceed this time the watchdog BSODs the system (because it's uncertain exactly what is going on).

In the call stack we can clearly see that a networking operation was in progress, the Windows netio.sys, ndis.sys and tcpip.sys drivers are called often. This of course means that this 0x133 bugcheck failed in the same general area as the earlier 0x9F bugcheck. Although we don't see the LAN adapter driver (rtcx21x64.sys) referenced in the call stack it must clearly have been involved. It will have been called by tcpip.sys in order to get the network transfer done.

If you're running the latest driver then one would have to suspect the LAN adapter hardware. Though I think it's remotely possible that an issue with your router could hold up a data transfer and thus hold up the DPC. It would be worth powering your router off and on again to clear anything in there.

You might also try connecting via WiFi for a time to see whether this stops the BSODs. If you're going to do that then first disable the LAN adapter in Device Manager and then reboot (to ensure that the rtcx21x64.sys driver is not loaded).

The only other thing I can suggest is borrowing a USB LAN adapter and see whether that suffers BSODs (disable the on-board LAN adapter and reboot again if you do try this).
Click to expand...
I'll go into the router and reset it to factory settings. I was in there not super long ago doing some stuff to set up a dedicated server for Valheim, but I was pretty sure I put everything back to original after.

The only network card on my motherboard is the one built into it, so is it possible that the motherboard/network adapter is just dying?
 
MetalMatty said:
I'll go into the router and reset it to factory settings. I was in there not super long ago doing some stuff to set up a dedicated server for Valheim, but I was pretty sure I put everything back to original after.
Click to expand...
I would still power it off and on to clear any caches it may have.

MetalMatty said:
The only network card on my motherboard is the one built into it, so is it possible that the motherboard/network adapter is just dying?
Click to expand...
It could be, but I can't confirm that. Both the 0x9F and the 0x133 bugchecks were network related and you now have the latest driver for that adapter installed, so what's left but the LAN adapter itself? You could try visiting your motherboard driver site and install the LAN adapter driver from there. Sometimes generic drivers don't contain specific customisation that the motherboard driver does.

Connecting via WiFi is the best way to prove whether the LAN adapter is at fault.
 
Aright, sounds good. So the current plan is that I reset the router to factory settings and rebooted the router and modem by unplugging.

I'll leave my computer on while I'm at work.

If it ends up crashing again, I'll buy a USB Wi-Fi dongle and see if disabling the LAN Adapter makes the crashes stop.

If it does crash again and going on Wi-Fi fixes it, really the only solution will be to get a new LAN adapter for my spare PCI slot or a new motherboard, I'm assuming?
ubuysa said:
I would still power it off and on to clear any caches it may have.


It could be, but I can't confirm that. Both the 0x9F and the 0x133 bugchecks were network related and you now have the latest driver for that adapter installed, so what's left but the LAN adapter itself? You could try visiting your motherboard driver site and install the LAN adapter driver from there. Sometimes generic drivers don't contain specific customisation that the motherboard driver does.

Connecting via WiFi is the best way to prove whether the LAN adapter is at fault.
Click to expand...
 
MetalMatty said:
Aright, sounds good. So the current plan is that I reset the router to factory settings and rebooted the router and modem by unplugging.

I'll leave my computer on while I'm at work.

If it ends up crashing again, I'll buy a USB Wi-Fi dongle and see if disabling the LAN Adapter makes the crashes stop.

If it does crash again and going on Wi-Fi fixes it, really the only solution will be to get a new LAN adapter for my spare PCI slot or a new motherboard, I'm assuming?
Click to expand...
Yes, that's a good plan. If it turns out to be the LAN adapter then just buy a USB LAN adapter, it will be cheaper than a new motherboard!
 
ubuysa said:
Yes, that's a good plan. If it turns out to be the LAN adapter then just buy a USB LAN adapter, it will be cheaper than a new motherboard!
Click to expand...
Well, I'm back.

Since we last talked, I bought a USB Wi-Fi Adapter. Using that adapter with the LAN driver disabled, I only had one crash which came back to a NVIDIA driver, so I think it was just a glitch in the GPU Driver. I ran that way for a few weeks and other than the USB adapter sucking and losing connection for 2-4 seconds randomly, I didn't have any crashes that related back to these two network drivers.

Today, I bought a new Network Card. I hopped on WoW and within an hour, I had a crash going back to the tcpip from before. https://drive.google.com/file/d/1eUbzY3CC7ua9hkpI1SJbGbxg6RwnxM1d/view?usp=drive_link I've uploaded it here just so you can verify (if you're still up for it), but I've since downloaded the program to open these dumps up myself and it is the same, or at least extremely similar, to the original crashes. The card I bought uses an RTL8125B chip and of course runs off of PCI.

My current plan of attack is to just straight up uninstall the old, original device and driver from device manager completely and see what happens. I figure at this point I have the USB adapter -and- the new PCI adapter.

If I crash again, and if you have no other ideas, I think the step after that will be to fresh install Windows 11. This was originally a Windows 10 computer that I updated to Windows 11 without doing it fresh about 6 or 7 months ago, so maybe it's just finally at the point where W10 and W11 have something that disagree with each other.
 
Well this is interesting!

The dump you recently linked to is indeed a DPC_WATCHDOG_VIOLATION - meaning the back-end of a device interrupt ran for too long - and (from the call stack that analyze -v gives you) it is indeed a networking operation that's in progress.

BUT - and this is a big but, the full call stack reveals the problem driver as being wfpent8.sys, you can see it being called many times in this fragment of the full call stack...
Code: 
ffff8586`e60d44e8  00000000`00000000
ffff8586`e60d44f0  fffff803`34a2d005 tcpip!TcpTlConnectionSendCalloutRoutine+0x25
ffff8586`e60d44f8  fffff803`30c5287a nt!KeExpandKernelStackAndCalloutInternal+0x7a
ffff8586`e60d4500  fffff803`30c527ed nt!KeExpandKernelStackAndCalloutEx+0x1d
ffff8586`e60d4508  fffff803`34a8603d tcpip!TcpTlConnectionSend+0x8d
ffff8586`e60d4510  00000000`00000000
ffff8586`e60d4518  00000000`00000000
ffff8586`e60d4520  00000000`00000000
ffff8586`e60d4528  00000000`00000000
ffff8586`e60d4530  00000000`00000013
ffff8586`e60d4538  00000000`00000000
ffff8586`e60d4540  00000000`00000000
ffff8586`e60d4548  00000000`00000000
ffff8586`e60d4550  00000000`00000000
ffff8586`e60d4558  00000000`00000246
ffff8586`e60d4560  ffff8586`e60d46f0
ffff8586`e60d4568  fffff803`30c83328 nt!KeAcquireInStackQueuedSpinLock+0x88
ffff8586`e60d4570  00000000`00000000
ffff8586`e60d4578  00000000`00000000
ffff8586`e60d4580  00000000`00000000
ffff8586`e60d4588  00000000`00000293
ffff8586`e60d4590  00000000`00000000
ffff8586`e60d4598  fffff803`9a1e2c50 wfpent8+0x2c50
ffff8586`e60d45a0  00000000`00000000
ffff8586`e60d45a8  00000000`00000000
ffff8586`e60d45b0  ffffffff`fffffffe
ffff8586`e60d45b8  fffff803`9a1e2c0f wfpent8+0x2c0f
ffff8586`e60d45c0  00000000`00000000
ffff8586`e60d45c8  fffff803`9a1ef650 wfpent8+0xf650
ffff8586`e60d45d0  00000000`00000002
ffff8586`e60d45d8  00000000`00000018
ffff8586`e60d45e0  ffff8586`e60d5050
ffff8586`e60d45e8  fffff803`9a1e34fd wfpent8+0x34fd
From what I can discover, wfpent8.sys appears to be related to an IPPC Technologies product. The version of wfpent8.sys that you have is over a year old now...
Code: 
7: kd> lmDvmwfpent8
Browse full module list
start             end                 module name
fffff803`9a1e0000 fffff803`9a1f4000   wfpent8  T (no symbols)          
    Loaded symbol image file: wfpent8.sys
    Image path: wfpent8.sys
    Image name: wfpent8.sys
    Browse all global symbols  functions  data
    Timestamp:        Wed Jun 15 20:16:19 2022 (62AA13E3)
    CheckSum:         0001AFB8
    ImageSize:        00014000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:
I would contact IPPC, make this dump available to them (save the associated kernel dump in C:\Windows\Memory.dmp in case they want to see that as well). See whether there is a more recent version of this driver.

I checked back at your earlier dumps and wfpent8.sys doesn't appear in those full call stacks, but that doesn't mean it wasn't called. We don't always see every driver called in the stack. It's entirely possible that all of your 0x133 BSODs have been down to wfpent8.sys - but there's no way to know.
 
  • Like
Reactions: MetalMatty
ubuysa said:
Well this is interesting!

The dump you recently linked to is indeed a DPC_WATCHDOG_VIOLATION - meaning the back-end of a device interrupt ran for too long - and (from the call stack that analyze -v gives you) it is indeed a networking operation that's in progress.

BUT - and this is a big but, the full call stack reveals the problem driver as being wfpent8.sys, you can see it being called many times in this fragment of the full call stack...
Code: 
ffff8586`e60d44e8  00000000`00000000
ffff8586`e60d44f0  fffff803`34a2d005 tcpip!TcpTlConnectionSendCalloutRoutine+0x25
ffff8586`e60d44f8  fffff803`30c5287a nt!KeExpandKernelStackAndCalloutInternal+0x7a
ffff8586`e60d4500  fffff803`30c527ed nt!KeExpandKernelStackAndCalloutEx+0x1d
ffff8586`e60d4508  fffff803`34a8603d tcpip!TcpTlConnectionSend+0x8d
ffff8586`e60d4510  00000000`00000000
ffff8586`e60d4518  00000000`00000000
ffff8586`e60d4520  00000000`00000000
ffff8586`e60d4528  00000000`00000000
ffff8586`e60d4530  00000000`00000013
ffff8586`e60d4538  00000000`00000000
ffff8586`e60d4540  00000000`00000000
ffff8586`e60d4548  00000000`00000000
ffff8586`e60d4550  00000000`00000000
ffff8586`e60d4558  00000000`00000246
ffff8586`e60d4560  ffff8586`e60d46f0
ffff8586`e60d4568  fffff803`30c83328 nt!KeAcquireInStackQueuedSpinLock+0x88
ffff8586`e60d4570  00000000`00000000
ffff8586`e60d4578  00000000`00000000
ffff8586`e60d4580  00000000`00000000
ffff8586`e60d4588  00000000`00000293
ffff8586`e60d4590  00000000`00000000
ffff8586`e60d4598  fffff803`9a1e2c50 wfpent8+0x2c50
ffff8586`e60d45a0  00000000`00000000
ffff8586`e60d45a8  00000000`00000000
ffff8586`e60d45b0  ffffffff`fffffffe
ffff8586`e60d45b8  fffff803`9a1e2c0f wfpent8+0x2c0f
ffff8586`e60d45c0  00000000`00000000
ffff8586`e60d45c8  fffff803`9a1ef650 wfpent8+0xf650
ffff8586`e60d45d0  00000000`00000002
ffff8586`e60d45d8  00000000`00000018
ffff8586`e60d45e0  ffff8586`e60d5050
ffff8586`e60d45e8  fffff803`9a1e34fd wfpent8+0x34fd
From what I can discover, wfpent8.sys appears to be related to an IPPC Technologies product. The version of wfpent8.sys that you have is over a year old now...
Code: 
7: kd> lmDvmwfpent8
Browse full module list
start             end                 module name
fffff803`9a1e0000 fffff803`9a1f4000   wfpent8  T (no symbols)         
    Loaded symbol image file: wfpent8.sys
    Image path: wfpent8.sys
    Image name: wfpent8.sys
    Browse all global symbols  functions  data
    Timestamp:        Wed Jun 15 20:16:19 2022 (62AA13E3)
    CheckSum:         0001AFB8
    ImageSize:        00014000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:
I would contact IPPC, make this dump available to them (save the associated kernel dump in C:\Windows\Memory.dmp in case they want to see that as well). See whether there is a more recent version of this driver.

I checked back at your earlier dumps and wfpent8.sys doesn't appear in those full call stacks, but that doesn't mean it wasn't called. We don't always see every driver called in the stack. It's entirely possible that all of your 0x133 BSODs have been down to wfpent8.sys - but there's no way to know.
Click to expand...
Hey, just wanted to reach out.

Turns out the issue was (seemingly anyway) just some bug in Windows.

I originally just let Windows update from 10 to 11, and it was mostly fine, but I had a weird feeling that this driver issue was somehow caused by doing that. I held off as long as I could, but after doing a fresh Windows 11 install it has been fine for weeks now.

Thanks so much for all your help through all of this, you taught me a lot on how to diagnose this stuff in the future, :).
 
It wasn't a bug in Windows.

It's quite common to see issues when upgrading from Windows 10 to 11 if you have drivers for obscure or unsupported devices installed. It's always a wiser move to clean install Windows 11 from scratch. Yes it's more work but because you get a stable system from the get-go it's a faster and less painful process in the long run.
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom