Forum Replies Created
-
Posts
-
No update in two weeks? I’m guessing the issue was abandoned, which is a shame since I was hoping to convince management to take a look at an Enterprise solution – that’s a no-go since we can’t even connect to a session reliably.
I just tried using the latest installation of NoMachine (nomachine_5.1.62_1.exe) by installing it on both the server and client today.
I am still getting the same type of error messages. (The session negotiation failed. Error: Descriptor: FD#19136 not available)
Please advise if you were delayed on releasing the update before Christmas or if you weren’t able to solve the problem?
Thanks,
Dave
If there’s a package you need me to test out in order to help fix the problem I’ll be happy to assist, but otherwise I’ll just wait for the official update since it’s just a couple weeks away now. I appreciate you tracking down the problem!
Cato,
It took me a while to get to a point where I could safely reboot the server since it’s a live server being used at all hours. I attached the screenshots below, one from before and one from after the reboot. The handles stayed almost exactly the same.
There isn’t any custom authentication on the server, and I rebooted at a time when there wasn’t any file sharing active on the local network, so that leaves the IIS web service as the reason why handles might be higher. I can’t tell whether that’s typical for IIS being active since I don’t have an equivalent server around that I can compare against, but the handles are stable at just under 5k, and don’t increase or decrease noticeably over time.
The screenshot after reboot was taken in the first 5 minutes after reboot. Prior to reboot, the server was online for several weeks – there isn’t any growth in memory or handles over time. I currently connect via RDP and occasionally via VNC with no problems whatsoever, nor are there any authentication issues with any connecting machines on the network or with any of the web sites being hosted.
Attachments:
I re-installed when the problem first happened, and I’ve already been on the latest version (5.1.54_1) but I reinstalled just prior to this post just in case. The problem happened immediately despite the fresh install.
As requested, I’m posting screenshots of the lsass.exe process as well as the error that the client gets (Bear in mind the number after “FD#” always changes with each attempt.)
Attachments:
Britgirl,
I sent the debug info you requested to the email you specified. I made three consecutive login attempts today (10/01/16) before sending the logs in order to make them easier to read and with recent data. Attempt 1 was successful, but attempts 2 and 3 both had the “FD#…. not available” error.
nxtrace.log file was not present, so it wasn’t included, but all other directories requested in the instructions were included.
NOTE: If you need to test the connection using the .nxs file you may do so in order to try and reach the Windows login screen. However, this is a live server containing HIPAA-sensitive data so your ability to log in to the actual desktop has been disabled by security policy. This change was made immediately prior to sending the debug logs AFTER all data was gathered, so I can assure you this security policy was not interfering with NoMachine.
– Thanks, Dave
Kroy, I sent the email you requested with the handle column. In that email I also noted how the nxservice64.exe process was using 100% CPU on 5 of 6 physical cores while idle with no connections. Total CPU across 6 cores was still at about 17% while idle even after restarting the service, so I rebooted the whole server and the usage has gone down to the usual 0% while idle.
I haven’t seen the nxservice64.exe jump up to those crazy CPU levels in 24 hours now, but I still am getting the same FD# not available error and can’t connect.
Attachments:
Yes, please do… anything would help! I was hoping to be able to transition our admin and management away from RDP/VNC since the speed is just as fast if not faster using NoMachine, but it’s kind of embarrassing that it’s unable to connect on our primary server.
I’ve looked at the logs with debug level messages on (KERN_DEBUG) and still didn’t see anything odd other than NXDescriptorCreate unexpectedly failing. I’ll be more than happy to work with you in any way that I can to get this issue resolved.
