Since I patched to the above I now get lots of these in the error log.
00:0012:00000:00000:2015/06/24 11:40:15.74 kernel ncheck_quit: no pid associated with fd 99, vsn = 331, socket type = 2
00:0012:00000:00000:2015/06/24 11:40:15.74 kernel ncheck_checkconn: Unable to identify thread for fd 99
00:0012:00000:00000:2015/06/24 11:49:35.59 kernel ncheck_quit: no pid associated with fd 73, vsn = 25, socket type = 2
00:0012:00000:00000:2015/06/24 11:49:35.59 kernel ncheck_checkconn: Unable to identify thread for fd 73
00:0012:00000:00000:2015/06/24 12:08:17.54 kernel ncheck_quit: no pid associated with fd 91, vsn = 198, socket type = 2
00:0012:00000:00000:2015/06/24 12:08:17.54 kernel ncheck_checkconn: Unable to identify thread for fd 91
00:0012:00000:00000:2015/06/24 12:14:30.81 kernel ncheck_quit: no pid associated with fd 78, vsn = 49, socket type = 2
00:0012:00000:00000:2015/06/24 12:14:30.81 kernel ncheck_checkconn: Unable to identify thread for fd 78
Unfortunately each occurrence of one of these is matched to a connection leak in sp_who, these show as 'MAINTENANCE_TOKEN' spids (you can kill them off with kill spid BTW), I remember from years ago this really means that it was a failed connection process.
I know which client they come from, the IP is in master.sysprocesses, in fact I can prove it by stopping the client process from running.
The client process is a third party monitoring server (GEB / ServerCheck) that just pings the hostname:port to see if the ASE server is up.
I can't patch further up the environment with this hanging over, if the monitoring server can cause connection leaks. maybe something else out there could be port scanning for instance.
Anyone else tried SP134 yet ?