Forum Replies Created
-
Posts
-
“might cause unexpected behavior in the future”
There’s the rub. I appreciate the information, and will try it on a virtual machine to see how it performs over time.
Changing the Name of the account only changes what it displays to the user — what it reports to everything else remains as it was.
In another place (not forums) Microsoft actually uses the term “friendly name” in reference to the changed name of the account.
I don’t particularly like this behavior on MY computer(s), but I can see how that would be handy for corporate machines.
I think it might be nifty to have the option in NoMachine for alternative authentication, but… it could be a hassle beyond value for you all. I just really dislike the name that was used on initial setup, and was hoping to be able to forget it. LOL
Personal lesson learned: Always get the OS disk when you buy, never install anything before wiping the HDD and installing a CLEAN OS, carefully pick the Primary Administrator name and password (then save that info for use later), and immediately create a working admin user account separate from that primary. A shame that clutters the login screen. There’s always something!
Thank you for your attentiveness and concern… and your tolerance!
Last night THIS happened:
I logged into the machine I’m having the account name/password issue with from another computer via WINDOWS NETWORKING using Windows Explorer, standard stuff…
Guess what!? Wrong Account Name (ie old one) required, just like I’m seeing with NoMachine. I have never run into this before, and in over 15 years of networking my computers together you’d think I would have at least once, or heard of it…
Perhaps this issue is NOT the fault of NoMachine. Windows seems to be at fault, and I’ll investigate with MS and post back if I find anything. If you find something first, however, I’d love to hear about it.
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.
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.
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?
After posting this, and doing all those changes, I again tried renaming the Windows Account, NoMachine still does not recognize the name, but it now does recognize the password.
I’m not really sure what happened there, and it makes no sense to me (seems random, but maybe it isn’t /shrug).
Still, would be nice if NoMachine reflected the same Administrator name as Windows.
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.