This is a general windows 7 question. I log in with my normal account and then runas a command-shell with my admin account. I use it so I can just up-arrow my last RDP connection and change a few letters to RDP into a different machine. The problem is that recently (I don't know what changed), when I'll do something outside of that elevated command-shell and then go back into it to RDP into a different machine (up-arrow, change a few letters from the previous RDP, then hit Enter), my Insert key is always active. So now I have to turn off Insert everytime my command-shell gains focus.
Does anyone know why this might be or what I can do to disable it? TIA!
A rebuild of my system stopped this behavior from happening. I know that's not a good answer but it's the only one I found--or anyone suggested.
Related
Good Afternoon, never seen this one before in my years of working with Windows but im at a loss to try and find the solution to this one.
When users log on to their desktops as Non-Admin accounts, there are particular applications they need to run as different users due to the way some of the systems work. A load of system policies where updated for security at group policy level however now something strange is happening when the user initiates a RunAs by holding the shift key down or if they attempt to remote desktop to another machine, the NLA Windows Security box that prompts for credentials takes 5/10 minutes to appear.
When the user hovers over the taskbar icon, then over the window without clicking the Windows Security box displays as full screen missing the username and password box but when you click on it nothing happens and just disappears. Eventually after a few minutes the windows security box will appear and can log in as normal however the users jump into systems adhoc and cant be waiting for minutes at a time to put their credentials in which could cost a lot of user down time during the day.
I have tried looking at the security log but as you can imagine its filled with all sorts and trying to locate one specifically without knowing the issue is difficult at best. Has anyone had this issue before that can point me in any direction. I have to assume this is permission related on the devices trying to access something locally because when i log on to the devices with an account in the administrators group all these issues disappear and the windows security works as normal. Also, if they click "Run as administrator" they get the UAC credential box so i don't believe this is UAC related as its working by design just anything with "Windows Security" prompts. I should point out that whilst this is waiting - the File Explorer icon highlights under "Run As" like the explorer is waiting to do something.
OS - Windows 10 Pro
Acc - Domain Joined
Group policy enabled
Local Policy Disabled
Update: 21H2
Never seen this before but hoping one of you legends has!
Dev
Full Screen Box - Screenshot
For anyone reading this - although bizzare as it is...
It turns out it was McAfee Disk Encryption - there was a bug in the local FDE security provider causing it to hang every time it was accessed.
Update your McAfee FDE Client/Agent to the latest version
I need to run a GUI script (AutoHotKey, which makes mouse clicks and press keys) on:
A different windows user (i.e. I run the script, then switch user
while keeping the session active)
A remote Amazon windows server (using remote desktop) where I also
run the script then close the Remote Desktop while keeping the
instance running
Unfortunately, in both cases, the script doesn't run as it seems that Windows enters a "GUI-less" mode where all GUI components are not active anymore.
Is there any solution to this?
Any hint would be greatly appreciated as I've now lost days trying to solve this!
Many thanks, Thomas
I do not believe this is possible due to the way Remote Desktop is implemented. When you close the RD connection, the GUI is no longer drawn. Therefore, AutoHotkey is unable to perform mouse clicks and key presses.
A possible workaround would be to make some registry tweaks (if possible on your server) which allow GUI interaction while minimized.
Locate HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client
Create RemoteDesktop SuppressWhenMinimized as DWORD with a value of 2
Registry Tweak Source
I need to create a program that can lock a Windows screen and prompt for a username and password.
It can be in any language but something without .net would be preferable in case I were to want to run it in an older version of Windows or WinPE.
I need it to not allow any other input in any way until the correct username and password have been put in.
It does not matter is the screen behind the prompt is blacked out or if it shows the desktop but doesn't allow the user to click.
Does anyone have any suggestions where I should begin?
I'm not entirely sure what you're trying to accomplish with this knowledge (sounds rather disruptive to the user imo), but you may be able to use the following knowledge to your advantage:
pressing CTRL+ESC simulates the Windows key
Windows key + L locks the computer
How can I unlock the windows lockscreen with Delphi? I didn't found anything on Google or Stackoverflow. I already tried to enter my password using keybd_event but it seems like the events dont work on the lockscreen.
You cannot unlock the lock screen programmatically from user space. That is by design.
OK, let's clarify that. Using documented APIs, you cannot do this. You need to reverse engineer undocumented APIs as #Remko has done for his SasLibEx product.
Remko Weijnen has very interesting projects in this direction. He has released a command-line tool (Winstation Locker) which is capable to unlock local/remote Windows XP station, without knowing the password of the user who has locked the computer.
For Windows Vista and later he has developed SasLibEx** library which can unlock even specific terminal services sessions, again without username/password.
Both methods require you to have Administrative privileges/account at the destination computer.
PLEASE NOTE, all these tools use nasty hacks that may be considered illegal, inappropriate, intolerant or criminal(?). It should be discussed with your Clients/Employer and should be used with caution!
** SasLibEx is a commercial product
Steamlink (a piece of hardware that allows you to stream your steam games to a big screen) currently has an issue, that if your screen is in a different part of the house, in order to play you need to walk to your PC unlock it and then walk back to your big screen.
In order to make it less painful, people in the community came up with this script:
#powershell -NoProfile -ExecutionPolicy unrestricted -Command "$sessionid=((quser $env:USERNAME | select -Skip 1) -split '\s+')[2]; tscon $sessionid /dest:console" 2> UnlockErrors.log
It can unlock your PC remotely. You can call tscon.exe from Delphi to emulate the same.
This actually can be done using powershell, psexec and windows onscreen keyboard. While a program cannot send input to winlogon, the windows osk can, and sure enough a program can send input to osk.
NOTE: The following is a remote solution.
As far as i know, Keyboard events wont work on lock screen unless you switch from Default Desktop to Winlogon desktop(Desktop referring to a container of all activities)
[Background]
Default desktop is the one you use when reading this post.
Winlogon would be the one that is set as active when you press Ctrl+Alt+Del
[XP]
You would need to Switch from Default to WinLogon Desktop[Check reference] and then you would be able to unlock machine by getting Window handle for Unlock Computer
IntPtr windowHandle = (IntPtr)FindWindow(null, "Unlock Computer");//Getting Window handle
Send username and password to respective edit boxes.
Reference
http://www.codeproject.com/Articles/16197/Remotely-Unlock-a-Windows-Workstation
[Win7]
Run tsdiscon.exe from remote. Not sure how this works; but for me, it unlocks the Locked Screen.
I have a user that is currently running my Winforms app on Win7. My app allows users to select rows from an open Excel spreadsheet and drag-n-drop them onto the app. However, this user cannot do the drag-n-drop. The cursor changes to the "no" cursor (little circle with line through it) and the operation won't complete.
I was researching drag-n-drop and Win7 and everything I found points to UAC and/or UIPI. I was looking for some solutions and am not sure if any of the below would work:
If the user logs in as admin (and as a result runs my app as admin) would that allow drag-n-drop to work?
Does the user need to turn off or change the settings of UAC/UIPI in order to be able to drag-n-drop?
I am not sure what the issue is. My app usually runs from C:/Documents and Settings/... (C:/Users/... on Win7). Does where it is running from matter? Does drag-n-drop not work because the user is not running my app with enough permissions? Are his Excel and my app on different permission levels? If so, what can be done about that? Note that even though my app allows users to just drag the file directly, that doesn't work either.
Also, is there any way I can have the user reproduce this issue with other apps? Are there apps that come with Win7 that he can see the same problem with. For example, can this be reproduced using Notepad?
Thanks.
Explaining this problem away by UIPI is a very long stretch. It doesn't have anything to do with whether or not the user is logged-in as an admin, that doesn't affect UAC and your program will be running with that same account anyway. The only way UIPI could kick in to stop a D+D is when your program is elevated and Excel is not.
To get yourself elevated requires work and doesn't happen by accident. You'd have to include a manifest so that the user gets the UAC prompt, you'd know about that. Or the user would have to change the desktop shortcut and tick the "Run this program as an administrator" option, she's know about that. While UIPI can be bypassed for Windows messages (ChangeWindowMessageFilter), it cannot for Drag and Drop so if any elevation is going on then your stuck. The ultimate test is to simply ask the user to put the UAC slider all the way down.
The much more likely scenario is that your DragEnter event handler simply isn't happy with the data it sees and therefore doesn't assign the e.Effect property. If you can't get a debugger on-site then write a little test program that logs the values of e.Data.GetFormats() plus whatever else you use to check if the drop is acceptable. And don't forget the obvious: the user simply fumbling the drag somehow.