- This topic has 7 replies, 3 voices, and was last updated 1 month ago by
.
-
Posts
-
The original thread https://forum.nomachine.com/topic/nxplayer-fails-to-open-on-win10 has been closed, I’m rewriting in a new one
Also with lastest version 8.14.2 I’ve same problem, nxplayer fails to open.
Same error in two different PC.
Same error when AVG is disabled.
nxplayer run only in safe mode.
I try again with every new version but I always have the same problems
Hi, in my last post I suggested to try monitoring the system calls when the player starts. I’ll paste my old reply here for convenience…
We don’t see much difference in the processes besides the Memory Integrity being enabled only on the troublesome system. We can only assume that the differences must lie in the way the two machines are configured. Maybe monitoring to know what happens in system calls could be useful when the player starts?
i) Download Process Monitor https://docs.microsoft.com/en-us/sysinternals/downloads/procmon (it doesn’t require installation)
ii) Right-click on Procmon.exe and select “Run as administrator”
iii) Click on “Filter” in the top menu, then “Filter…”, click “Add” and set the filter:
* Column: Process Name
* Relation: is
* Value: nxplayer.bin
iv) Click “Add” then “Apply”.
v) Click on “File” then “Clear”
vi) Start the NoMachine client, and let Process Monitor capture data for about 30 seconds
vii) Click the magnifying glass icon in the toolbar to stop capturing
viii) Click “File” in the top menu, then “Save…” (PML file)
ix) Create also a TXT summary. Click “File” > “Export…” > “Text File”After a full analysis, we know the client fails to open because a system library raises an exception that causes the process to immediately close. When starting the machine in safe mode, the player has no problems so it means something loaded on the system (and not loaded in safe mode) is triggering the wkscli.dll exception.
While the dump is useful to understand, more or less, when the problem occurs, we didn’t find clear reasons to explain the issue in detail and offer an analysis about the exception, and about how it affects NoMachine.
The only hint we can give is to debug WSL (Windows Subsystem for Linux) and wkscli that is creating a pipe giving problems. Specifically, the exception seems to occur after the following error:
CreateFile: \\wsl.localhost\PIPE\wkssvc Result: BAD NETWORK NAME
The pipe is legit and usually created for the IPC over SMB calls, so maybe the problem is caused by a buggy library or Linux subsystem. Disabling WSL should be a way to stop creating the wsl.localhost mount point and verify if the player starts correctly.
After disabling WSL Nxplayer is back to work
re-enabling WSL nxplayer not working again
I’m keeping WSL disabled for now thanks, with each new version I’ll try and see if you can figure out where the problem is.
We’ve noticed from your dump that the wkscli DLL which is crashing when it accesses your WSL mount point is version 10.0.19041. You could evaluate updating your Windows machine to something more recent, since the latest Win10 is 10.0.19045.
Hi biglia.
The version number 10.0.19041 was extracted from the dump you sent, and while we know that Microsoft has unclear rules about the DLL versioning (for example on all our full updated 22H2 machines, ntoskrnl has different versions!), we preferred to suggest to update your machine because this versions mismatch makes hard to compare systems and detect reasons for different behaviours, most of all when they occur in a deep system layer.
Troubleshooting your problem has been quite painful, as the NoMachine client process is closed before it can start doing anything meaningful: the Workstation Service DLL is loaded in a chain of dependencies and, when trying to do its stuff, raises an exception and causes the process to terminate. The exception description is “The network address is invalid”, and there is nothing the client did up there to cause an error like that.
After all our attempts to reproduce the issue and to progress in the debug through static analysis, we can certainly say that this problem is completely out of our control. A possible reason why it happens with NoMachine only (at least from what you’ve seen so far) is the sequence of DLLs loaded that badly interact with one or more configurations and third party services on your machine.
We tried to replicate your environment with WSL and WSL2, by publishing and accessing multiple resources on the network to extensively use Workstation Service, but we never succeeded to reproduce the same issue.
I remember you said that one of your machines with the same configuration works correctly. You could try to compare the services and configurations, and check event viewer to look for anything useful about wkscli. As of WSL, a good starting point could be the issue tracker on github. If you’ll find anything that you think valuable to be shared, we’ll be happy to know it. 🙂
You must be logged in to reply to this topic. Please login here.