Investigating High DPC Latency Caused by tcpip.sys

Investigating High DPC Latency Caused by tcpip.sys 

Introduction

After building a high-end Windows 11 workstation for Cubase, Dorico, Vienna Ensemble Pro (VEP) and Bome Network, I noticed occasional audio clicks and pops despite having a powerful computer and conservative ASIO buffer settings.

Running LatencyMon consistently showed that tcpip.sys (Microsoft TCP/IP Driver) was responsible for very large Deferred Procedure Call (DPC) execution times. Because Bome Network uses UDP port 37000, it was initially suspected that Bome Network was responsible for the excessive latency but it turned out to be my virus scanner (Bitdefender Total Security)

This post escribes the complete investigation, the experiments that were performed, and the conclusions.

System configuration

The workstation consists of:

• Windows 11
• Intel Ethernet Controller (3) I225-V (driver 2.1.5.7)
• NVIDIA Studio Driver
• MSI motherboard
• Cubase Pro
• Dorico
• Vienna Ensemble Pro
• Bome Network 1.6.0
• Bitdefender Total Security
• etc

Initial LatencyMon results consistently showed:

• tcpip.sys execution spikes between approximately 8 and 12 ms
• Audio drop-out warnings
• Excellent ISR timings
• Very few hard page faults

This suggested that the problem originated in the networking subsystem rather than the audio interface.

Initial hypotheses

Several possible causes were considered:

1. Bome Network continuously transmitting UDP packets.
2. Intel I225-V driver problem.
3. Windows TCP/IP stack.
4. Windows Filtering Platform (WFP).
5. Bitdefender network filtering.

The goal was to isolate each variable using controlled experiments.

Preliminary investigation

The following observations were made:

• Auto-discovery in Bome Network was disabled.
• Only a single UDP socket on port 37000 was open.
• NetBIOS was disabled.
• IPv6 was disabled (no measurable improvement).
• Various Intel adapter performance options (Interrupt Moderation, Energy Efficient Ethernet, Large Send Offload, etc.) were disabled with little effect.
• Latest Intel driver installed.

These changes did not remove the tcpip.sys spikes.

Controlled experiments

Test A – Baseline

Configuration

• Ethernet enabled
• Bitdefender installed
• Bome Network running

Result: Highest tcpip.sys execution: 8.85 ms

Observation: Large DPC spikes remained.

Test B – Bome stopped

Configuration

• Ethernet enabled
• Bitdefender installed
• Bome Network stopped

Result: Highest tcpip.sys execution: 12.24 ms

Interpretation: Stopping Bome did not improve latency.

Conclusion: Bome Network is not the source of the latency spikes.

Test C – Ethernet disabled

Configuration

• Ethernet adapter disabled
• Bitdefender installed
• Bome Network running

Result:  Highest tcpip.sys execution: 1.33 ms

Interpretation:  Disabling the Ethernet adapter reduced the worst-case DPC latency by approximately 85%. This clearly demonstrated that the networking subsystem was involved.

Test D – Ethernet cable unplugged

Configuration

• Ethernet adapter enabled
• Network cable unplugged
• Bitdefender installed
• Bome Network running

Result: Highest tcpip.sys execution: 8.84 ms

Interpretation: This was one of the most important experiments. Despite having essentially no network traffic, tcpip.sys still produced very large DPC spikes. This demonstrated that the problem was not caused by packet traffic. Instead, merely having an active network adapter was sufficient to trigger the latency.

Final experiment – Uninstalling Bitdefender

Configuration

• Bitdefender completely removed
• Ethernet enabled
• Bome Network running

Result:  Highest tcpip.sys execution: 0.257 ms.  This represents roughly a 34-fold reduction compared to the original measurements. The dominant driver also changed from tcpip.sys to the NVIDIA graphics driver, whose latency remained within a perfectly reasonable range for a professional DAW.

Interpretation

The experiments allow several hypotheses to be rejected.

Bome Network

Initially Bome Network appeared suspicious because it listens on UDP port 37000.

However:

• stopping Bome had no effect;
• unplugging the network cable had no effect;
• disabling the Ethernet adapter did improve latency.

Therefore Bome Network itself is very unlikely to be responsible.

Intel I225-V

The Intel driver also appears unlikely to be the primary cause. LatencyMon never identified the Intel miniport driver or NDIS as problematic. Instead, the expensive execution always occurred inside tcpip.sys.

Bitdefender

Removing Bitdefender almost completely eliminated the tcpip.sys spikes.

This strongly suggests an interaction between:

• Intel I225-V
• Windows TCP/IP
• Windows Filtering Platform
• Bitdefender kernel filtering drivers

rather than a defect in Cubase, Bome Network or the Intel driver itself.

Conclusions

The investigation leads to the following conclusions.

• Cubase was not responsible.
• Bome Network was not responsible.
• Network traffic itself was not responsible.
• Simply enabling the network adapter activated the problematic execution path.
• Removing Bitdefender reduced tcpip.sys latency from approximately 9–12 ms to only 0.26 ms.

For this workstation the primary source of excessive DPC latency was the interaction between Bitdefender and the Windows networking stack.

Recommendations

For professional DAW systems I recommend:

• Use Microsoft Defender unless specific Bitdefender functionality is required.
• Use LatencyMon to verify system behaviour after installing security software.
• Avoid assuming that the driver with the highest execution time is necessarily the driver that contains the root cause.
• Perform controlled A/B experiments by changing only one variable at a time.

Final remarks

This investigation illustrates how misleading DPC latency analysis can be. Although LatencyMon consistently reported tcpip.sys as the offending driver, the root cause was not the Microsoft TCP/IP driver itself. Instead, systematic experimentation demonstrated that the excessive latency originated from an interaction with third-party kernel filtering software.

The key lesson is simple: change one variable at a time and verify every hypothesis experimentally.