GlassWire very unreliably recording upload activity as of recently and other bug

A lot of connections (but not all) are showing 0.0 B upload regardless of how much was downloaded, this is happening across two different Windows installs and after resetting GlassWire and firewall. (IPv6 disabled, only other adapters are from VMware player)

I know for sure this is a thing since Version 2.1.158 but it may have existed since Version 2.1.157.

I also just had a bug where randomly two applications were recorded under the same entry in GlassWire, a reinstall (with settings deletion) was required to fix it (removing firewall entries manually didn’t work).

@Thinking

Strange. Please email us some screenshots and details of what Windows version number you are using so we can try to recreate this.

We read a Windows API for data, so this is not something I have ever heard of happening that I recall. Maybe it has something to do with VMWare, but I also use VMWare software myself and I have never seen this on my own PC yet.

https://www.glasswire.com/contact/

Sorry for not replying for a few days, I was collecting more details (what I had wasn’t much) and just generally monitoring GlassWire’s behavior.

I decided to post this here publicly as I feel this may be a situation where experiences from other people (and their hardware) is very valuable.

First off, a couple screenshots:

2019-06-28_09-36-09

^ Screenshot from Chrome, shows random connections not displaying upload bandwidth. (This is just one example of many)

2019-06-28_09-34-59

^ I didn’t get a screenshot of the two apps merging into one entry but here you can see Discord randomly becoming the LXSS (Linux Subsystem) “ping” command. This “entry swapping” seems to start and end randomly, although a creating new GlassWire database/history files is an instant fix.

Interestingly the upload bandwidth recording seems to work fine sometimes right after booting but breaks shortly after.

My setup: Everything worked fine until around the beginning of this month then the whole issues with upload bandwidth recording started on my old install (LTSC 2019/1809) and continued over to my new install (Windows 10 Enterprise 1903), the new install was installed completely fresh (disk reformatted) and I didn’t import my old GlassWire data.

Edit: I also had it happen once or twice that download bandwidth wasn’t recorded at all (or only a few hosts) for a specific application until it was restarted.

Edit 2: Very interesting, seems like i am not alone with this issue? No upload visible on some programs But that thread was started last year…

Edit 3: I just remembered a few other things that I should mention: I am using DNSCrypt-Proxy https://github.com/jedisct1/dnscrypt-proxy for DNS (I don’t think that should matter for upload bandwidth?) I also disabled nslookup in the GlassWire config, I left it enabled for a test and it didn’t fix the issue.

I also totally forgot to put this in the post right away: I actually previously experienced bugs with “0” upload when using IPv6! I usually have it disabled for various reasons but this was something that I found noteworthy, interestingly it never affected IPv4 before now. This all is such a weird issue!

Thanks for your report.

GlassWire uses a Windows API to read network activity. If GlassWire isn’t showing data then it would most likely be a bug with Windows itself. Almost every application that reads network activity uses the same Windows API, so I think that’s unlikely.

We will test with DNSCrypt-Proxy. Perhaps it’s due to that somehow.

I see your screenshots but I don’t understand what exactly is wrong with your stats? Maybe you can explain more in detail why you think the network data is wrong? It will help me understand.

You mention the Linux Subsystem is wrong, but do you use the Linux Subsystem at all? How do you know it’s wrong?

How do you know the upload is not zero?

Do you have some apps set as “Incognito”? If so they will not show up on the graph because that’s how Incognito works.

Please provide details on your OS version and any network software installed, then please provide numbered steps on how to reproduce this bug.

I am going to combine my answers for your reply in both threads here.

some type of proxy/DNS software that may be unusual

(Referring to DNSCrypt-Proxy)

DNSCrypt-Proxy isn’t a conventional network proxying service like a VPN, it’s actually just a local DNS server that allows you to use DNSCrypt DNS encryption. The only change that really happens is that you point your DNS servers to 127.0.0.1

You mention the Linux Subsystem is wrong, but do you use the Linux Subsystem at all? How do you know it’s wrong?

I use LXSS with Ubuntu but when the screenshot was made the LXSS service was stopped (e.g. it is impossible for “ping” to actually do anything), what happened was that traffic coming from Discord was falsely categorized as coming from the “ping” application.

How do you know the upload is not zero?

I can’t know for sure for every connection (too lazy to match everything with Wireshark readings) but I think it is fair to assume that some upload is not registered when entire applications are showing 0.0byte readings over longer periods of time.

GlassWire_2019-06-29_11-27-38

^ Screenshot from my PC after waking it up from sleep just now, this causes the network to reset so you would expect any network activity to have at least some outgoing traffic. Note that this is very common, there is no way that this reflecting the real data.

Do you have some apps set as “Incognito”? If so they will not show up on the graph because that’s how Incognito works.

Nope

Please provide details on your OS version and any network software installed, then please provide numbered steps on how to reproduce this bug.

Version 1903 18362.207 - Other network related software is just VMware Player and Wireshark. Also DNSCrypt but that is literally just a local DNS server.

As for reproducing the bug, be me (or the other guy with the issue) and have GlassWire installed, I guess?

I believe Wireshark uses the exact same Windows API to read network activity, so it’s most likely its stats would be identical.

We’ll investigate and try to reproduce this issue. Please note GlassWire is a historical network monitor that can allow you to go back in time, so perhaps the Linux Subsystem data you are seeing is from a previous period in time and it’s actually correct.

I know for sure I never pinged the Discord CDN, keep in mind that the Windows install is only a few days old so I’ll remember (and I created clean GlassWire installs a couple times during that time).

Note also that it shows a bunch of different IPs (that’s why the multiple entries) so I would have to ping it multiple times and get different CDN endpoints.

Also (I remember checking carefully) during that time the actual Discord entry showed no traffic so it was clearly swapped.

I did some searching and it appears the Discord app has the ability to ping its server inside the app itself. Perhaps you did that while using it?

“It’s above your name in the bottom left where it says “Voice Connected”. You can hover over the signal icon to the left of it and it should pop up or you can click the info icon to the right.”

Maybe you clicked that info icon? Perhaps you can try it again and see if the ping re-appears in GlassWire.

The “ping” application shown by GlassWire was under “\LocalState\rootfs\bin” of the Ubuntu for Windows filesystem/folder and considering I neither installed a Desktop Environment nor Discord on Ubuntu, that’s not it. Also, Discord would either ping through its own application which would show up as “Discord” or through Windows which would show up under “System”.

Edit: The connection being checked when showing the ping is always the connected voice server which shows as “[something].discord.media”

Reviving the thread because I am still having this issue. Some upload data gets recorded but clearly the majority is missing showing 0.0 B on most or all hosts in any application. Does someone from GlassWire know what to investigate as a possible cause, is there anything special about upload monitoring?

@Thinking

We use a Windows API to count data so I’m not sure why the API would just give GlassWire readings of 0 somehow.

I think this is not your issue but in the past some people have misunderstood our “Usage” tab local vs external traffic settings. Details are here https://www.glasswire.com/userguide/#Usage_Tab.

Please note we’re releasing an update with a completely new backend in the next 30-60 days. I would recommend using that update and seeing if you still have the issue. At this point we’re not making major modifications to our current software so I don’t think logs would help.

If the problem appears in our major backend update we could possibly provide a logging version but I’m not sure we can do logging for Windows API data issues since it’s related to Windows itself.

Just a quick update on the situation: The issue is actually fixed now, it seems to have disappeared since I installed WireGuard and used it a couple times, something about it did something and now I can see all the up and download data as I would expect it to look like.

This is probably a really weird solution but if you have this issue try installing WireGuard and connect to something, if you don’t already have a VPN that supports it you can use Cloudflare’s WARP VPN: https://github.com/ViRb3/wgcf not sure what you have to do exactly but for me connecting to it and using it for a bit fixed the problem permanently.

Note: I am not sponsored or anything by them, it’s just an option that gives you a WireGuard server to connect to and isn’t some shady free VPN or requires you to set up your own server.

Also if this doesn’t work for you, you can try to install the Windows Sandbox feature (if your version supports it) it sets up a virtual Hyper-V network adapter which may also fix the issue.

I have the suspicion that the problem is some “”“intelligent”"" Windows feature that gets disabled (somehow permanently) under certain circumstances.

Edit: I didn’t even reset the history or reinstalled or even updated GlassWire back when this fixed itself it seems it was all due to connecting to a WireGuard server.

@Thinking

I am glad the issue is fixed!

The change list does show there was a known counting issue related to database conversions (upgrading from 2.1 to 2.2). Perhaps it was related somehow.

I agree Cloudflare Warp VPN and Wireguard are both great services/software.

It’s interesting you mention Hyper-V. We found the Hyper-V adapters cause our “Things” list to load more slowly than previously. GlassWire "Things" not working (or updating) and Hyper-V Network Adapters So we don’t recommend using them unless you need them.

The issue fixed itself some time mid April so before GlassWire 2.2 was released.

Regarding the Hyper-V adapter, yeah I’m not surprised in the slightest that it causes issues like this.

I remember that installing Hyper-V was one of the first things I tried to fix the missing upload bandwidth issue when it initially showed up for me, I believe it either fixed or caused some issue I had with something similar before, also whenever I see odd looking local IPs that applications connect to it’s always Hyper-V with another weird IP range.