Interprocessor Connection does not disconnect on Windows when moving from 5.4.4 to 5.4.5

I use InterprocessorConnection for bidirectional data transfer between client and server - both using the InterprocessorConnection class over a WAN/internet connection (using a socket, not a pipe). I set callbacksOnMessageThread=false. This has been working well for a long time. When the connection is terminated with disconnect() on the client side, it has always caused the server to call connectionLost(). This stoppped occurring recently on windows only (mac is fine). The server will just stop receiving data with no connectionLost indication. I dug down into the depths of the InterprocessorConnection functions as far as I could go and confirmed it never gets a socket read that returns -1, as far as I can tell. If the server tries to send in this state, it will error appropriately and I can manually call disconnect() on the server in response to that, but that seems like a hack/workaround. I had updated Windows 10 and JUCE recently so I suspected one of those changes was the problem. If I downgrade JUCE from 5.4.5 back to 5.4.4, the problem goes away and connectionLost gets called correctly. I do get this in my build:

Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. For example:
1>- add -D_WIN32_WINNT=0x0501 to the compiler command line; or
1>- add _WIN32_WINNT=0x0501 to your project’s Preprocessor Definitions.
1>Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target).

That has always been there, but maybe now it matters?

Settings->System->About says:
Edition: Windows 10 Pro
Version: 1803
Installed on: 5/20/2018
OS build: 17134.950

I also use boost, and had to define WIN32_LEAN_AND_MEAN to eliminate a “winsock.h has already been included” message. I removed that define and came up with a way to #include <WinSock2.h> at the top of my files to get around the above error message in a different way. The original disconnect problem persisted though…so I think all of this is unreleated, but included here for completeness.

Also tried defining _WIN32_WINNT=_WIN32_WINNT_WIN10, but that led to a run time error on a mutex lock.