Killer networking software causes DRIVER_IRQL_NOT_LESS_OR_EQUAL or network-driver BSODs

Legacy or incompatible Intel Killer/Rivet networking software can install bandwidth-control, prioritization, or filter components into the Windows network stack. Under sustained downloading, VPN use, or other heavy network traffic, a defective component can cause a bug check. Two confirmed cases stopped crashing after the Killer software suite was removed; one named bwcW10x64.sys, and another recorded ndis.sys and klflt.sys in the network-path crash evidence.

The repair is not to delete the Windows network stack or the named .sys files. First prove that the machine contains Killer hardware/software and that the crash is linked to network load and a Killer/Rivet component. Then preserve an exact base network driver, remove the optional Killer performance software, restart, and retest. Install a current exact OEM or Intel package only if the adapter needs it or the performance suite is required.

Searchable Windows bug checks, files, and product identifiers

Do not advertise UNEXPECTED_IRQL_VALUE as an actual Windows stop name. Index the canonical IRQL_UNEXPECTED_VALUE (0xC8) only when verified, while retaining the source token internally as an alias that requires review.

Use this procedure when:

• Windows 10 or Windows 11 crashes during reproducible network load such as a large download, VPN traffic, or torrent traffic;
• the stop screen, BugCheck event, or dump records 0xD1, 0xC8, or a network-driver stack;
• the computer contains Intel Killer/Killer/Rivet networking software and matching network hardware, or a dump identifies a signed Killer/Rivet component;
• an exact OEM or Intel base driver package has been downloaded before the suite is removed; and
• the crash is not better explained by RAM, storage, GPU, security software, VPN software, or another identified filter driver.

The procedure can also be used as a controlled isolation test when ndis.sys appears in the stack but a third-party Killer filter is the stronger candidate.

Do not use this procedure for ordinary Wi-Fi disconnects, slow networking, high latency, router problems, or a Killer Control Center interface problem that does not produce a Windows bug check.

It also does not apply when:

• the adapter and installed applications have no Killer or Rivet relationship;
• the dump consistently identifies a VPN, antivirus, firewall, storage, graphics, or other third-party driver instead;
• the same crash occurs with networking disabled and no Killer component loaded;
• Windows Memory Diagnostic, MemTest, WHEA, or hardware diagnostics report a hardware fault;
• the network adapter has a Device Manager hardware problem code that persists with a known-good base driver; or
• the only evidence is ndis.sys in a stack or Event 41 after an unexpected restart.

A torrent or VPN trigger can involve its own filter driver. Do not remove Killer software merely because both were active.

The exact Windows build, internal programming defect, and precise packet sequence may remain unknown if a controlled uninstall removes the crash and reintroduction restores it.

The following may not remain unknown before removal:

• the actual bug-check code and dump path when available;
• the network adapter hardware ID and driver provider/version;
• the installed Killer/Rivet product names and versions;
• the digital-signature owner of each named non-Microsoft .sys file;
• a safe, repeatable trigger that does not use unknown or unlawful content;
• the exact base network driver package that will restore connectivity; and
• an alternate way to obtain files if the affected adapter stops working.

If klflt.sys cannot be attributed from its signature and dump context, leave its ownership unknown rather than labeling it a Killer driver.

• Administrator access
• Recent minidumps preserved from %SystemRoot%\Minidump
• A wired alternate connection, second computer, or exact base network driver package stored locally
• The computer OEM support page or Intel package that explicitly supports the adapter hardware ID
• Device Manager evidence for each Killer Ethernet and Wi-Fi adapter
• Installed-app inventory for Killer/Intel/Rivet software
• A safe controlled download source for verification
• Important work saved and backed up

Create a before-state folder and inventory the network devices and third-party drivers from an elevated Command Prompt:

md "%USERPROFILE%\Desktop\Killer-network-before"
pnputil /enum-devices /class Net /drivers > "%USERPROFILE%\Desktop\Killer-network-before\network-devices.txt"
pnputil /enum-drivers > "%USERPROFILE%\Desktop\Killer-network-before\third-party-drivers.txt"
driverquery /v > "%USERPROFILE%\Desktop\Killer-network-before\installed-drivers-verbose.txt"

If a command option is unavailable on the installed Windows build, preserve Device Manager screenshots and the plain pnputil /enum-drivers output. Do not update Windows solely to gain a diagnostic switch.

1. Stop the network-load activity that triggers the crash and save all work.
2. Copy recent minidumps to the evidence folder before cleanup tools or storage policies remove them.
3. Run perfmon /rel and record each hardware error, Windows failure, and software installation near the first crash.
4. Open Settings > Apps > Installed apps and record every entry containing Killer, Intel Killer, or Rivet.
5. Open Device Manager and record the hardware IDs, providers, versions, and dates for the affected Ethernet and Wi-Fi adapters.
6. Download the exact current base network package from the computer OEM first. Use Intel's package only when it supports the detected adapter and the OEM does not require its own release.
7. Store the package locally. Do not rely on the adapter under test to download it after removal.
8. Do not start Driver Verifier, delete ndis.sys, disable random network services, reset Windows networking, or uninstall VPN/security software before the driver ownership is established.

1. Capture the complete stop screen. Record the stop name, numeric code if shown, and named driver.

2. If the screen disappeared too quickly, open Event Viewer > Windows Logs > System, locate BugCheck Event 1001 at the restart time, and record the bug-check value and dump path.

3. Preserve and inspect the dump with WinDbg when available. Run !analyze -v and record:

   • the canonical bug-check name and value;
   • MODULE_NAME and IMAGE_NAME;
   • the failure bucket;
   • the stack frames around ndis.sys; and
   • whether bwcW10x64.sys, klflt.sys, or another third-party network filter is actually implicated.

   Do not classify a driver from the probably caused by line alone when the stack and signature contradict it.

4. Verify each named file on the affected computer. In an elevated PowerShell window run:

   $names = 'bwcW10x64.sys','klflt.sys','ndis.sys'
   foreach ($name in $names) {
     $path = Join-Path $env:SystemRoot "System32\drivers\$name"
     if (Test-Path $path) {
       Get-Item $path | Select-Object FullName,
         @{n='FileVersion';e={$_.VersionInfo.FileVersion}},
         @{n='Company';e={$_.VersionInfo.CompanyName}}
       Get-AuthenticodeSignature $path |
         Select-Object Path, Status,
           @{n='Signer';e={$_.SignerCertificate.Subject}}
     }
   }
   

5. Interpret the files narrowly:

   • ndis.sys signed by Microsoft is part of Windows; do not replace it.
   • A non-Microsoft file is relevant only when its signer/product and the dump connect it to the failing network path.
   • An unsigned or invalidly signed file requires security and package-integrity review before any reinstall.

6. In Device Manager, use View > Devices by driver or each adapter's Driver Details to connect the network adapter to its actual package. Record hardware IDs and the current INF/provider.

7. Establish a repeatable, safe trigger. Use a known legitimate large download, an internal test server, or a vendor-hosted test file. Record whether the VPN is connected, which adapter is active, and how long the crash takes. Do not use unknown torrent content as the verification workload.

8. Check competing explanations:

   • If the crash occurs only with one VPN and its filter appears in the dump, test or update that VPN first.
   • If memory tests or WHEA events report hardware faults, stop software isolation.
   • If the crash occurs with all networking disabled, Killer software is not established as the sole trigger.

9. Proceed when a Killer/Rivet suite is installed, the adapter identity matches, the crash follows network load, and the dump or controlled removal test supports its filter path.

Branch A — Remove the optional Killer performance software while preserving a base driver

1. Confirm the exact OEM or Intel base network package is stored locally.
2. Disconnect from the VPN and stop all downloads.
3. Open Settings > Apps > Installed apps.
4. Select Intel Killer Performance Suite, Killer Performance Suite, or the exact installed Killer software entry and choose Uninstall.
5. Follow the vendor uninstaller. Remove the performance suite/control components; do not manually delete driver files or Windows network components.
6. Restart Windows through Start > Power > Restart.
7. Open Device Manager and inspect each affected network adapter:
   • If it is present with no problem code and networking works, do not reinstall the optional suite yet.
   • If the adapter lacks a driver or has Code 28/31/39, run the exact local OEM/base driver installer.
8. Test ordinary browsing first, then the controlled network-load trigger from section 7.

This branch mirrors the two source-confirmed resolutions: removing the Killer software suite stopped the network-load crashes.

Branch B — Install only the exact base driver when the adapter lost its driver

1. Run the computer OEM's signed driver installer and select driver-only or minimum components when the package explicitly offers that option.

2. If the supported package consists of INF files, use an elevated Command Prompt:

   pnputil /add-driver "C:\Drivers\Exact-Network-Package\*.inf" /subdirs /install
   

3. Restart.

4. Confirm Device Manager shows the correct adapter, provider, version, and no problem code.

5. Test local networking and Internet access before applying sustained load.

Do not force an INF whose hardware IDs do not match. PnPUtil will not force a lower-ranked driver onto a device; do not bypass that protection by copying files manually.

Branch C — Clean-install a current compatible Killer suite only when its features are required

1. Obtain the current package from the computer OEM or Intel and verify explicit support for the hardware and Windows architecture.
2. Uninstall the existing Killer Performance Suite from Installed apps.
3. Restart.
4. Run the verified current installer.
5. Choose the minimum or driver-only installation when the exact installer offers it and Killer prioritization features are not required. Otherwise complete the supported installation.
6. Restart if requested.
7. Repeat the same controlled network-load test.

If Branch A is stable and Branch C restores the crash, remove the optional suite and retain the stable base-driver configuration. That A/B result is stronger evidence than the original temporal association.

• Networking works and the controlled load no longer crashes after suite removal: keep the base-driver configuration and complete verification.
• The adapter has no driver after removal: install the exact base package from Branch B; this is why the package had to be local first.
• A current clean-installed suite remains stable: retain it and record the exact corrected version.
• The crash returns only when the suite is reinstalled: the optional suite/filter path is strongly demonstrated; remove it again.
• The crash continues with the suite absent: stop attributing the problem solely to Killer. Reinspect the dump for VPN, security, hardware, and other filter drivers.
• ndis.sys remains in the stack without a third-party culprit: do not replace it. Continue dump analysis.
• A different canonical bug check appears: treat it as a new result and route by that code and module.
• Network connectivity cannot be restored with the exact base package: stop further removal and use the alternate connection or OEM support.

• Do not delete, rename, or download a replacement ndis.sys.
• Do not assume klflt.sys belongs to Killer without checking its signer and dump context.
• Do not advertise UNEXPECTED_IRQL_VALUE as the canonical Windows bug-check name; verify IRQL_UNEXPECTED_VALUE (0xC8) in the dump.
• Do not start Driver Verifier on an actively crashing production machine as a first step.
• Do not remove every network driver, adapter, VPN, firewall, and security product at once.
• Do not use pnputil /delete-driver ... /force on guessed INF packages.
• Do not run registry cleaners or third-party driver cleaners.
• Do not verify with unknown torrent content or a workload that creates legal or security risk.
• Do not reinstall Windows before the optional network filter has been isolated.

If suite removal causes loss of required features or connectivity:

1. Use the locally saved exact OEM/base driver installer to restore the adapter.
2. Restart and confirm basic connectivity.
3. If the full performance suite is required, install the verified current compatible package, not the same legacy version that produced the crash.
4. Restore VPN or policy settings only after base networking is stable.
5. Repeat a controlled load test. If the crash returns with the full suite, remove it again and use the stable base driver while seeking a corrected release.

If a driver package was changed through Device Manager and Roll Back Driver is enabled, record the current version and use that button to return to the prior package. Do not restore by copying individual .sys files.

1. Confirm every required Ethernet/Wi-Fi adapter is present in Device Manager with no problem code.
2. Record the final driver provider, version, date, and installed Killer suite status.
3. Test DHCP or the configured static network, DNS resolution, and ordinary browsing.
4. Connect the VPN only if it was part of the original trigger and is approved for the test.
5. Run the same safe sustained download for longer than the prior time-to-crash. Repeat at least twice.
6. Restart and repeat one controlled load test.
7. Review Reliability Monitor and Event Viewer for new Windows failures or BugCheck Event 1001 entries after the repair time.
8. If a new dump exists, compare its code and modules; do not count a changed crash as success.
9. Confirm that Windows Update or a vendor utility has not silently reinstalled the removed optional suite during the observation period.

Success requires working networking and no recurrence across the prior trigger and duration. A short idle session is not verification.

Confidence is 80% that removing the Killer performance software will resolve a matching network-load BSOD when the hardware/software identity is proven and the dump or controlled test implicates its filter path. Two independent Windows 10 cases explicitly confirmed that uninstalling the Killer suite stopped the crashes; one included DRIVER_IRQL_NOT_LESS_OR_EQUAL and bwcW10x64.sys. Installing a current clean suite is a separate A/B branch whose success must be verified on the affected machine; the retained cases do not establish that branch at 80%.

The confidence is bounded because the cases are historical, this procedure has not been independently reproduced, ndis.sys can appear when another filter is at fault, and the source token UNEXPECTED_IRQL_VALUE requires canonical dump verification.

Stop when the driver signer cannot be established, the adapter lacks an exact recovery package, the dump identifies another component, hardware tests fail, the crash continues with Killer software absent, connectivity cannot be restored, or the device is governed by an enterprise network/security configuration that requires administrator approval.