I have a consistent bug I can reproduce at any time.
KRC to any machine. Open windows explorer. Highlight a file, press Shift-Delete to delete a file without going via the recycle-bin. Release shift-delete and hit enter to confirm the "do you really want to delete" message.
At this point exactly what happens depends on the OS version - but basically the machine still thinks shift is being pressed - so from then on any click on explorer multi-selects a block of files/folders/whatever. I have to press and release the shift key once more to "clear" the shift-state. This is a really nasty bug because if you double-click another folder or file (for example) without clearing the shift state you can launch the open command on thousands of files....and if you're pressing delete, well you could delete most of the c: drive by accident. Nasty.
I believe the same thing happens with CTRL and ALT on occasion.
KRC seems to fail to remember the shift-state e.g. with ANY other VM OS environment, clicking into a VM window will switch your machine to match the keyboard state - e.g. caps & numlock change to reflect the VM's keyboard state. This doesn't happen with KRC.
Anyone else have these sorts of issues????
Hmm Craig, I really tried to reproduce this on about 5 servers, but didn't see the issue.
Not on customer's servers or on our own. Not sure what's going on here, must be something local. Did you try it in the 9.4 beta?
Craig, I think I ran into this issue and didn't even realize it was possibly a KRC issue. Are you still seeing it. I don't recall exactly what system I was on at the time but wondering if I should try to reproduce.
I've found that LiveConnect often disables our shift keys until it is closed out of - not just in the KRC session, but ON my local machine. Anyone else?
JosephH - We have had the exact same issue.
Also when connected to customers, whenever there is a password prompt ie UAC the caps lock key is on and can not be turned off remotly and we have to get the customer to physically do this on there keyboard
While I haven't seen that error, I do have a KRC error of my own that I haven't been able to reproduce consistently.
I have an issue where if i copy data while the KRC window is open, every once in a while the KRC window will close unexpectedly. It doesn't matter if I am copying in KRC or on my PC.
I can reproduce the bug any time, 100% consistently. It's the right-shift key that I use most frequently, and i'm EN-US keyboard layout with Australian English selected, if that helps.
I can confirm that this has happened to me on a daily basis (since the 9040000 update). Only a reboot fixes it ( or a log off if I am in a citrix remote session)
im on window s 10x64
To fix it, I just tap(press and release) the shift key a few times. Pressing and releasing each of the 'state' keys once and individually (i.e. tap each shift, alt, ctrl key) seems to 'clear' the stuck state by registering the 'release' of the key with the system.
I was having random keyboard issues, but so far .17 seems to have resolved them. :crosses fingers:
I am having the same issue. It definitely only affects my machine when I open a kaseya live session, and then it affects my entire machine even if I close the session.
I have found that a reboot or pressing both shift keys at the same time resolves the issue temporarily.
Demuzi Is it easily reproducible? If so, please create a ticket with support and reference AF-1883. We're looking for reproducible examples to bring to development.
KLC and KRC both show the shift-key bug.
The same thing happens for any keyboard state.
start with caps off on both KLC workstation and agent.
KLC into agent.
now press caps lock -> caps on in both KLC host and agent.
click out of KLC window - local PC now has focus. Turn off caps -> pc has caps off., agent has caps on,
click back into KLC window. shif state remains the same - now the agents caps lock state and the local PC disagree.
the same happens for numlock and scroll lock.
*very simply, kaseya doesn't save/restore they keyboard state across sessions*
As an example, if you use vmware, teamviewer or hyper-v, you'll note if you click onto a VM which has caps on, th caps light comes on on the host machine, and goes off again when un-focusing the vm window.
kaseya needs to properly preserve the keyboard stat between the host and the agents it's controlling.
WE raised a ticket, but it seems nobody is able to reproduce it, except this forum. Our technician got nuts of it. I wonder why not all have that problem.
Oliver Heymanns If your ticket is #193217, it was closed due to non-responsiveness. See if you can re-open the ticket. We will continue working with you to figure out the root cause.