- This topic has 7 replies, 2 voices, and was last updated 9 years, 1 month ago by
.
-
Posts
-
Greetings,
I’m running NoMachine 4.4.12 (free) on host and remote, both using Windows 7 Home Premium.
On the remote machine I virtualize a USB device to the remote. This works fine for 2 to 4 hours, and then the remote machine crashes.
I attempted this several times (and learned some really nifty things about NoMachine in the process) with the same results. Doesn’t seem to be a consistent amount of time (that I can tell) within the range given, but it is a certainty to happen, given time. Moving the virtualized device back to the remote machine and performing the operations manually as needed produced no crashes after 8+ hours. The device also works fine on the remote machine, I just don’t generally need to use it for that machine.
What have I done wrong and/or how can I correct this behavior of the virtualized USB port/device?
Many thanks!
Hi,
I have one question – what USB device are you connecting. We would like to simulate a similar situation in our laboratory and check what the problem is.
It is a Belkin Nostromo n52 (rev 1) game pad. I use it to run macros. It’s quite old, but perhaps you can achieve reproduction with similar devices.
I have one question still. What exactly do you mean by “the remote machine crashes”? What exactly is happening – does the session stop, does the player shut down or maybe NoMachine server shuts down. Please exactly describe this crash. We would like to simulate a similar situation in our laboratory and check what the problem is.
I honestly couldn’t tell you which is happening first. I don’t realize there is an issue until NoMachine closes of it’s own accord on the remote computer. Based on how things have been performing since I moved the device back to the local machine I think it likely that either the server or the client (NoMachine) is closing the open session if there is no mouse/keyboard input from the remote computer after a set period of time (that I can’t find a setting for, so I’m just guessing really). If this is the case, then the crashing was a symptom… I haven’t tested this yet, but I believe it likely that if I pulled the device from the local machine’s USB port I would get a similar system crash (the software associated with it isn’t very fault tolerant). So, if there is a session timeout due to “inactivity” this could totally be the reason. I still have NoMachine sessions close without my express intent for them to do so, just without crashing the local machine… I wait a couple minutes and reconnect fine.
What I am doing only requires occasional input from the remote (about every 3 to 4 hours): I set up the application to use the pre-programmed macro, hit the button on the n52, and from then until the 3 to 4 hours is up all I need to do (most often) is monitor progress in case of an error that needs intervention. Once that process completes I press the button on the n52 again to toggle it back off, do a bit of housekeeping in the application, set it up again and repeat the process.
So, now, when the NoMachine session closes I just reinitiate it and roll on. Before, when the session closed it effectively pulled the USB plug from the local machine causing the software to die horribly and take the system down with it (very bad, but they aren’t making/supporting that product anymore). Anyway, that’s my theory, and as much as I can tell you about what is happening from my end. The reason I was getting such a long time the night I reported initially might be because I was exaggerating a bit, or I was baby sitting the process a bit more because of the seemingly random issues I’d been having and wanting to make sure it was corrected. /shrug Either way, sorry if that didn’t help.
Are there log files for NoMachine that I could look at to get a better idea, or send to you for review?
Okay, I tried to cause the crash on the local machine.
I pulled the USB plug on the device while in operation… no crash.
I disabled the USB devices (that I could, not all had that option available) and hubs and ports in device manager (individually, and only one at a time). While the operating device stopped working in every case, it was still connected and operable (I just had to hit the button on the n52 for it to run the associated macro again, nothing fancy). Again, no crash.
Now, I will try hooking it back up remotely and forcing the client to close while the device is in operation (virtualized to the local machine) and see if that causes the Operating System to crash as seen in the OP. I’ll post results as I have them.
Okay, pulling it remotely doesn’t crash the OS either (without the application I run the device in executing). However, I noted that it does kill the NoMachine service on the local machine.
Which it apparently did when I pulled the device when it was connected locally but I hadn’t noticed at the time.
So, I’m still not sure what is causing the OS to crash, but pulling the device while in operation, whether locally installed or remotely virtualized, is killing the NoMachine Service. The service is not recoverable without a system reboot. Even if you re-run the service, it does not initialize properly and removes it’s tray icon after a brief period of time.
Thanks for your time. Sorry for the frustration.
This topic was marked as solved, you can't post.