WIndows Update KB5044091 seems to kill comms to VP WLL

Been working happily for moths, but this morning after windows update kb5044091 and kb5044273 WD is acting strange. Updated to wd37-152 version today, issues still present.
WD makes out like its connecting to Davis VP WLL via tcp and port, in that the green data light blinks, but the data counter doesn’t increase, nor is any valid data displayed.
Tested connection from another old win10 pc running (very) old WD10.37-02 and this works fine, so we know not an issue with connection or the Davis VP equip.
Turned off all firewalls on pc, no difference.
made sure files folders in C:/wdisplay/ aren’t set to “read only”, no difference.
Any ideas?

Strange I have 2 units that run windows 10 22H2 both getting tcp data via tcp serial interface ok after those updates installed
First try a power reboot ie shutdown and power off for a few minutes then power up and restart see if that resolves it. If that fails You could also try uninstalling the 2 updates to see what happens or use system restore to a date before the updates

well after a day of mucking around i managed to get it working but still unsure of the actual cause!

Removed the 2 updates, didn’t work.
System restored back to 2 days previous, didn’t work.
Reupdated WDL to lasted version, and now its working again?!?
What’s strange is that during this, an old version on a different win10 pc was conecting fine… strange…

coming back to this as failed again.
even gone so far as to reset the windows PC and still no data.
green light flashes but counter doesn’t rise from zero.
connection to davis console IP still works from other win10 pc running demo version of WDL on same switch etc.

netstat shows connected established.
wireshark shows the davis request and the provision of mac address.
wireshark shows regular packets of 154bytes (100 byte length) from the Davis IP to the PC IP (PSH,ACK) then PC responds with the 54byte ACK.

So networking everything seems fine? But WDL just will not show any data…

so installed completely fresh version of WDL on this troublesome PC, set it up, and same issue, green light flashing, no data on data counter, no live data showing.
I can only presume some sort of issue between ethernet and WDL.

WD, if in fact that’s what you’re running, is hard coded to ignore data that is invalid or wildly inaccurate. Barometer readings seem to be the most common.

but connection and data working fine when on another PC connected to the same Davis unit, so can rule that out.

What is the program debug info under view panel showing in WD

So the plot thickens…
just updated my very old demo version to the latest version on my laptop that was working and fine, and now have excatly same issue as i’m trying to solve on the original PC!

log just gives:
Doing checking of time zone calculation
Daylight saving in use
Loaded all time records
TCP/IP connected to 192.168.2.38
Doing checking of time zone calculation
Daylight saving in use
VP reception #1 4601 #2 60 = 99

It sounds like a permission problem to me. If WD is flashing green then my guess is the data input is okay. I’m not sure where WD writes that data. My guess is it uses the .inf files for quick access, then the log file for the human readable data.

Since you have multiple systems that aren’t production value I would try doing a clean start of WD from scratch. The goal would be to rule out a setting. You could try the 2wd.txt troubleshooting tool. While I can’t think of any setting that could cause this I sure wouldn’t rule it out either.

done a clean start of WD and same issue.
so now 2 pc with same version same issue.
to rule out connectivity, connected one pc via davis weatherlink software and that displays data fine.
set folder/file permisions to full access for “everyone” on wdisplay folder, still no resolve.

windows defender and windows firewalls all disabled… running out of options :slight_smile:

Maybe time to contact Brian at [email protected]

just went back to old school 10.370 build 02 on my laptop, and works fine… must be something in new build

Definitely time to contact Brian :slightly_smiling_face:

Good to know Weatherlink works, verify USBExpress mode is not enabled.

I would try to verify the inf and log files are updating by checking date/time and size of file.

think i need to contact Brian over this, just completely wiped wd, installed old build 120, didn’t work. dragged even older build 02 across from laptop, works fine… something weird going on…

OK, so just to tidy this up incase anyone has same issue.
After a windows update, WD failed to communicate with Davis Weatherlink Envoy (6134 UK) with a WeatherLink IP (6555).
Comms to the unit were tested and verified using wireshark, and connection to the unit using Davis own Weatherlink software.
The WD version was updated to latest to rule out issue.
All firewall and defender turned off.
File permissions on the c:/wdisplay folder and files set to full permissions to “everyone”.
WD subsequently uninstalled and folders wiped.
older version build 120 installed with same issue.
Then a very old build 02 “wdisplay folder” was dragged across from an old laptop and communication started and worked fine.
Latest build was then installed over the top of this, and it once again failed to establish comms.
Old build 02 wdisplay folder contents dragged into wdisplay folder, ran “weatherD.exe” comms resumed and everything working once again.
Final check, installed build 152, didn’t work, then just dragged the build 02 “weatherD.exe” across. ran fine.

From above and without any further deeper debug info, it does appear to be a conflict with updated windows10 with the weatherdisplay.exe file or a .dll that it refers to.

1 Like

So, Thanks to Brian’s help debugging, established that indeed the barometer in the Davis Console seems to have decided to produce erroneous data, on the same day the computer installed updates and died. Not a great believer in coincidence really, but it does seem to happen!
The older version of software obviously more tolerent of this data than the newer versions, hence it worked fine on the older software. I’ve marked @dcrooks answer as the solution as ultimately that was indeed the issue underneath all of this.

4 Likes