Error: Descriptor: FD#….not available

[dav36rye]

I installed the free version of NoMachine onto a Windows Server 2008 R2 machine. I am able to connect without issue maybe 1 out of every 50 attempts. When it works, it works perfectly, but most of the time it throws the error during handshake of “Error: Descriptor: FD#20276 not available” where the 5 digits after FD# are almost always different. I’ve googled and searched the forums for a similar issue but haven’t found any help.

I’ve attempted to connect via multiple different Windows 10 machines with fresh installations of the free version of NoMachine. Checking the security audits for the server reveals that the client is successfully logging in as the user with full authentication and permissions, but then the handshake fails after that. When the connection happens to work, the logs don’t show any warnings or errors, and the connection is stable and problem-free up until I disconnect. I’ve tried using different ports and disabling UDP, changing pretty much every setting I can but to no avail. Software firewall on the server is currently disabled, as is all anti-virus.

Below is the most pertinent info from nxserver.log. It appears that the function “NXDescriptorCreate” is faulting, but I can’t for the life of me figure out what that function is doing and what server policy/configuration could be interfering with it.  I edited the user to “Username” and the IP address to “x.x.x.x” for privacy.

 

2016-09-21 03:40:23 522.519   564 NXSERVER User ‘Username’ logged in from ‘x.x.x.x’ using authentication method password.

2016-09-21 03:40:24 906.598  5920 NXNODE   ERROR! NXDescriptorCreate FD#20276 return -1

2016-09-21 03:40:24 907.598   564 NXSERVER ERROR! Received error message from node: localhost:4000. Error is: Descriptor: FD#20276 not available\n.

[Britgirl]

We’ve no idea why that’s happening. Can we send you a debug package?

 

[dav36rye]

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.

[kroy]

Can you send nx processes list with enabled option “Handles”?

Just run Process Explorer (Ctrl+Shift+ESC), choose “View” -> “Select Columns…” -> check “Handles” -> click “Ok”.

Now sort with name, scroll down list to see nx processes and do screenshot. You can attach the picture here or send to forum[at]nomachine[dot]com.

[dav36rye]

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:

1. 

   Untitled.png
   

2. 

   Error-1.png
   

[Britgirl]

We don’t need to send you a debug package. It will be enough for you to enable debug and then submit the logs: https://www.nomachine.com/DT07M00098.

Please follow the instructions and then send the logs to forum[at]nomachine[dot]com.

[dav36rye]

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

[shmyyy]

Hi, I am having the same issue with free version on Windows 7 (I am connecting to virtual display). Could anybody propose the solution for the problem?

[kroy]

Dear dav36rye,

did you try updating NoMachine to the latest version? If you are still seeing the problem, please write here also number of handles for the lsass.exe process.

[dav36rye]

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:

1. 

   Untitled2.png
   

2. 

   Untitled.png
   

[Cato]

Hello dav36rye,

Number of open handles of lsass.exe process which you attached to previous reply is pretty big. This may be due to handles leak, which might be caused by some of custom authentication packages installed on your host. Is there anything specific about your setup which could affect authentication process and behavior of lsass.exe process? Can you check the number of open handles of lsass.exe shortly after OS reboot? Does this number grow over time? If so, could you estimate the rate of growth in time?

[dav36rye]

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:

1. 

   Before.png
   

2. 

   After.png
   

[markybob]

Same problem here on Windows 10 with the latest updates (both NoMmachine and Windows). it was working fine before this last Windows update.

[Cato]

Hello,

We understood the problem and are working on proper solution. Thank you for cooperation. Fix will be officially released before Christmas. Perhaps you’re interested in trying out test packages in the meantime?

[dav36rye]

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!

[Author]

Posts