We are experiencing the same error for several developers here that are using a floating license, while the one developer with a static license doesn’t have any problems.  The floating licenses are all running a VS version that is earlier than what was released today, while the static license user is running today’s VS release.

Is it possible that Sysprogs is having a problem with their floating license server?

No problem, we will try to explain what is going on.

The problem is most likely related to the TLS versions (protocol used by HTTPS). In order to maintain backward compatibility with VS2008, VisualGDB binaries are built to be compatible with all .Net versions starting from 3.5. However, the actual .Net 3.5 requires the old TLS 1.1 protocol that has been dropped by the latest web server software.

So, as a workaround, VisualGDB uses configuration files (e.g. VisualGDB.exe.config) to explictly request Windows to prefer the newer .Net 4.0 that works with the latest TLS:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319"/>
<supportedRuntime version="v2.0.50727"/>
</startup>
</configuration>

The error would happen if you were using the old VS2008 (that depends on .Net 3.5) or somehow Windows would stop using the latest .Net version and would revert to 3.5. It is difficult to say why exactly it would happen on a particular machine, however we can suggest a few workarounds:

• Try replacing the SessionServer.exe executable in the VisualGDB directory with this version: https://sysprogs.com/files/tmp/SessionServer.exe
• Double-check that the visualgdb.exe.config and SessionServer.exe.config files are present and specify v4.0 before v2.0.

If nothing helps, you can work around it by using a separate forwarder that would fetch the session keys using TLS 1.2 and feed them to VisualGDB. Let us know if you nothing else helps, and we will provide more details.