Very high DPC routine execution time for TCPIP.SYS with Glasswire 1.20

For some weeks now I’ve been trying to diagnose a problem with audio on a laptop that I’ve been running for more than 3 years, a Dell Latitude e6230 with very stock standard hardware (8gig ram, 512gig SSD (SATA), core i5 3340m, onboard audio and an external USB DAC Fiio e17). Behaviour affected all audio devices, even bluetooth connected ones in the same way.
Audio playback - be it 3rd party video players (VLC) or embedded video via chrome, etc. (even winamp type programs) were experiencing stuttering and freezing accompanied by insane CPU utilisation especially when Chrome was open (and extremely high when loading detailed pages).
Complete removal of Glasswire 1.2 resolved this - LatencyMon didn’t point to Glasswire directly so I found this with trial and error. Before this TCPIP.SYS was at the highest rate that LatencyMon could report, it was often hitting this over and over again and audio would break up badly enough to break for several seconds and video would become quite out of sync.
I’ve re-installed 1.2 deleting original config and log data - has anyone else seen or reported this type of problem? I’ve just done the re-installation but CPU utilisation is VASTLY lower.

Since the re-install I’ve had to pull it completely - it was just causing too many system problems, there’s something badly wrong with the way the latest version is working with the network stack on my system. I’ve tried a wide range of things too including NIC drivers, switching NICs, switching sound devices, etc. - the only thing that’s worked is pulling Glasswire completely off the system (used Revo to do this). Idle (not active) CPU has dropped remarkably, my current draw is about 12% when before it was above 80% or more most of the time and that wasn’t clearly showing as Glasswire doing it - it was showing as a combination of increased draw from Chrome.exe and System. Not sure what to make of this as I’ve used Glsswire for a while now.

Sorry for the problem. We have never seen this reported before and we have never seen this on any of our systems.

GlassWire does not do anything with TCPIP.SYS.

If you disable GlassWire’s network scanning does it help?

To disable Network auto-scanning completely create a text file called glasswire.conf and place it in the c:\programdata\glasswire\service folder. Add this string to the text file: enable_network_scan = false then restart the GlassWire service. We plan to add a setting for this in the future.