IME most ClosedChannelException issues are because the Windows VM is rebooting and/or has lost its network connection.
Modern versions of Windows are very reboot-happy and really don't care if the machine is in use or not - Microsoft seem to be of the opinion that downloading their latest code onto your machine and then rebooting is more important than allowing your applications to run unimpeded (Windows 10 especially).
Also, even the most transient of network blips gets turned (by Windows) into an application-level connection failure, which manifests as a ClosedChannelException at the Jenkins master (and a failure at the slave too, as it's Windows that's killing the TCP connection, not slave.jar and not the Jenkins master).
I'm running Windows on vSphere VMs here and I've yet to encounter a ClosedChannelException that hasn't (after much hair-pulling diagnostics) been traced to Microsoft's door. Windows updates are one source. Windows time service + Windows DHCP client is another. It's a constant battle to undo whatever well-meaning-but-misguided "improvements" have been made in the last patch to restore performance and prevent reboots.
I've heard that the LTSB variant of Windows may be a less reboot-ridden option.