If the interceptor can't connect to the pipe, it stops silently, as in production code you don't want exceptions to flood some log just because a client isn't available.
If the client is up and on the same machine, in process explorer you should see:
File \Device\NamedPipe\SD.Tools.OrmProfiler
If you're using the latest ormprofiler client (2.0.1) it's recommended that you use the v2.0 interceptor as well.
The factory is properly wrapped so messages should be send. What I'm a bit puzzled about is your remark: "installed latest dotConnect for PostgreSQL". The factory that's wrapped is v3.2.6, which is definitely not the latest npgsql (if that's what you meant with dotconnect for postgresql).
If the only other thing that has changed is windows 10 latest version it might be something with the firewall in windows, but then again, I have a bit of doubt why that would be a problem with a named pipe.
Additionally, the user the app runs under, is that the same as the ormprofiler client? Perhaps it doesn't have the right ACL to access the named pipe, although we never had problems with that.
I've attached a debug build of the interceptor for .net full (profiler 2.0) which will rethrow the exception if it runs into one while connecting. This might give more insight in why this is. If you're using R# or Rider, you could step into the code of the InterceptorCore.Initialize() method and see what's going on when it tries to connect in NamedPipeChannel.ConnectToPipeThreadBody