NoMachine connection to Windows 11 freezes up

[smalltalk]

I’m having lots of issues running NoMachine server on a Windows 11 Pro system. The client is an MX Linux 23 XFCE desktop based on  Debian 12. I’ve had few issues using the same Linux client with a Windows 10 Pro server. All systems are on the same LAN.

The Windows 11 system is a very recent clean install that began with Windows 10 Pro on a new to me refurbished PC. I have very consistent entries in Event Viewer that repeats each time.  Basically I can log in fresh to W11 from Linux and everything is okay for a while. Then after some time the connection freezes up.

One fix always works. That is to restart nxservice on the W11 server system. This can be either by remoting with [removed] or through open ssh and entering:

Restart-Service nxserver

in the terminal. Either way works. But then after a period of time, everything freezes up again, but can be fixed by restarting nxservice.

I can post some log files. But they are quite vague. The Event Viewer is a little more detailed with the same exception error code and offset each time. I’ve also the log files can be configured to be more detailed, but haven’t tried it yet.

This is my first post on this though I’ve used NoMachine for about 8 months now. Please let me know what logs to upload and how to configure the logs for more detail.

[Britgirl]

Hi, we aren’t aware of similar issues on Windows 11. Are you able to send us the server-side logs from the Windows machine, so we can check them? You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243.

Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!

[Britgirl]

Hi, can you try disabling HW encoding on the Windows and see the freezing still occurs? On the Windows machine, open NoMachine settings > Server > Performance > Untick the box ‘Use hardware encoding’.

If it does, player logs from the Linux client this time would be useful. Please refer to the same document I pointed you to last time.

[smalltalk]

Since my last reply, I simply uninstalled NoMachine on the Windows 11 server side and deleted the configuration files under the home directory. Then I reinstalled it and now everything is fine! I didn’t touch the Linux desktop client side as suggested. Also everything worked fine with a similar Windows 10 Pro system on the server side using the same Linux client.

That said I’ll never know exaclty what caused it. I’m fairly certain NoMachine was installed before the Windows 11 upgrade. That’s the only thing I can think of. But in any case everything is fine now.

Thanks for you attention!

[smalltalk]

Please disregard my last post, at least partially. After several hours of testing, the problem reappeared even after reinstallation on Windows. This time there’s nothing posted to the Event Viewer application log. Haven’t checked the log files yet. It happened just after the screen saver on the Linux side started up. This could be  a coincidence.

And I just unchecked User hardware encoding.

There’s certainly an improvement after reinstalling on the Windows side. This could indicate multiple issues. So far the access violation hasn’t reappeared in Event Viewer. In the meantime I’ll look at the Linux client side logs.

[Britgirl]

Thanks for submitting the logs. Player logs are showing HW decoding is not being used. Did you also disable also hardware decoding (on Linux) besides disabling hardware encoding on Windows?

Also useful for the investigation:

1) Run this command on the client machine and send us the file (‘xdpyinfo.out’).:

xdpyinfo -ext all > xdpyinfo.out

2) Does closing the player and reconnecting help?

3) Does the problem appear after the screensaver starts up?

4) You say you reinstalled the server and it solved the crash which is good news. We would appreciate a new set of logs, including both server and client logs, just after having reproduced the issue. This will allow us to compare with the earlier ones you sent.

5) Is the monitor of the server attached and turned on all the time when the issue is reproduced? Or if it’s a laptop, is the lid open?

[smalltalk]

1. Sent xdpyinfo.out as an attachment

2. Closing the player and reconnecting always helps. That’s why I switched to running PowerShell “Restart-Service nxserver” from the Linux client terminal. It’s easier than manually reconnecting the player.

3. It doesn’t necessarily happen after the screen saver starts up. I forgot to mention I also have sleep mode setup for 1 hour of idle on both client and server. Perhaps it’s asking too much to survive sleep mode on each end. But my original problem was occurring way before sleep mode kicked in. And since the reinstall, it’s only frozen once. Also I think after the server (Windows) wakes up, sometimes it seems to need a keyboard or mouse click directly to fully wake up, although the screen is display a login. A quick [removed] connection works too. My two machines are NOT that remote in a physical sense. I’m using NoMachine as a way to share keyboard, mouse, and monitor saving on multiple KVM switches. Also I have two other remote desktop services running on the Windows side: [removed] and [removed]. I use the latter when remoting from an iPad.

4. I’m fairly certain you already have my before and after reinstall logs. I was always getting error code 0xc0000005 (Access Violation) on the Windows server side Event Viewer application log before the reinstall. That error has completely disappeared. I’ll try to send new server side logs, but the errors are much less frequent now. I may have to collect logs after the sleep timeout on both machines.

5. The machines are both desktops. There’s no laptop lid involved. I have a single monitor with multiple inputs. The Linux client is on the DisplayPort monitor input, while the Windows side is on the VGA input. But only one input at a time is active.

[Britgirl]

The output didn’t proffer any useful hints unfortunately.

Completely disable hardware decoding on the client if you already didn’t do so by following the instructions here:
https://kb.nomachine.com/AR07U01202

Attach gdb so we can get the dump of threads of the client not updating the screen:

$ sudo gdb -p <pid of the client process>
$ set height 0
$ set logging file /tmp/backtrace.txt
$ set logging on
$ threads apply all bt full
$ quit

Also, when the connection freezes, is the client still responsive?  ie. Can you open the menu and interact with it? While the window appears to be frozen, is the CPU usage of the client process normal?

[Author]

Posts