I want to create a program for a computer lab. The computers in lab are running Windows 7 and are connected via LAN. The program should freeze keyboard and mouse when PC gets disconnected from LAN and also show a fullscreen message.
Currently I have created the first version of this program that works almost fine. It runs with startup. But the problem is that the users can kill it from Task Manager. I've tried running it as a windows service and it runs but cannot interact with desktop, so it cannot freeze the keyboard and mouse.
Any suggestions is appreciated. Thanks in advance.
So I finally solved it.
The reason my program could not interact with desktop is that it runs in Session 0.
This is because the Windows services run in session 0 and cannot directly interact with desktop. Here by interaction I mean receiving keyboard, mouse events and creating or accessing windows in user's desktop.
So I created a service that runs with SYSTEM account. It will create the "freezer process" in user's session. Also this process will run with SYSTEM account, so the normal user will not have privileges to kill.
Related
In a personal project, I want to display my application before (or above) the Windows Logon, ie just before entering the Windows password.
The application must "hide" the password entry screen. I used to launch an application at Windows startup but this after viewing the Windows desktop.
Is it possible to do this please? Should I create a Windows service that will launch my application?
Thanks for your help
If this is just a personal project on your own machine you could set Windows to autologon and then just run your application like a normal startup shortcut.
A NT service is the only documented way to run code before a user logs on. However, spawning a new process in another session and interacting with the Winlogon desktop and putting yourself on top of LogonUI.exe is going to be a hack.
I understand that desktop/GUI apps are not supported in Windows containers. They do run but there's no built-in way to interact with them. I had the following idea - maybe I could use the Desktop Sharing API (https://learn.microsoft.com/en-us/windows/win32/api/_rdp/) for this purpose, the idea is to run a desktop app, then run a sharing program that uses the Desktop Sharing API, and connect to it using a Desktop Sharing API viewing program from the host.
I had to do some recap about window stations and desktops, and I noticed that when starting the container with cmd in interactive mode, I'm logged with ContainerAdministrator as a service (logon type 5). I tried running some WinAPI functions that deal with desktops and winstation and got some access denied results, so I switched to running cmd as system.
The window station of the cmd process (and other child processes) is not the interactive WinSta0, but instead some other service window station, which makes sense since I'm logged on as a service, and I figured that I can't use this window station, so I used a little program I wrote to run notepad in Winsta0 in the Default desktop. Afterwards I ran another program that enumerates the windows on WinSta0\Default, and the notepad window does get enumerated and I also get it's title, so it's running somewhere.
So now I tried running the desktop sharing API program (also on WinSta0\Default). It runs and I can connect from the host, but I only get a black screen without anything on it. I also tried running a program that takes a screenshot of the windows but I get an empty bitmap.
So I thought maybe the Default desktop is not the active desktop, and by using the OpenInputDesktop function I could confirm it - the current desktop was the Winlogon desktop, so I used the SwitchDesktop function to switch to the Default desktop (I used OpenInputDesktop again to verify that it actually worked).
Unfortunately, this didn't change anything, I still get an empty screen and empty bitmaps.
I know that containers are built for micro services and are not supposed to run GUI apps and so, but still - is there a way to make this work? Or any ideas of what else I can check? Alternatively, if you know that it can't work - I would also be happy to hear a good technical explanation of why it doesn't work.
As in title. Is there any way to achieve this?
I have problem, because when you close remote desktop, gui and whole interface is being locked and any gui based applications or my autoit scripts won't work (they are crashing constantly).
I tried using 'tscon.exe' but this works only on windows server 2008.
I have the same issue, and I resolved it doing the following:
Connect to RD to your server with user "A"
From the remote computer, connect to RD to localhost to user "B" (create it if necessary)
From the new session, run anything you need.
Disconnect the FIRST session, with user "A".
In this way, the session running with user "B" will not be locked, and it will continue running your GUI controls.
Log off means the current session (created by logging in during RDP) is terminated. What you want is to keep the Logon Session live but disconnect the RDP.
Why not use AutoLogon to boot into console and run the scripts? However if the screen locks or someone RDPs and disconnects, the problem you are facing will reoccur.
What I have is to keep GUI and whole windows interface alive when i close remote desktop. Session is alive but gui and whole workstation is getting locked everytime I close rd.
I have a requirement of simulating Ctrl+Alt+Del in remote system.I loaded sas.dll and called sendsas function but it is not working.How to display winlogon screen on remote system.
Thanks
As discussed here, you can try using Ctrl+Alt+End instead. This will bring up the Task Manager.
If this doesn't work for what you need, you can open the on-screen keyboard in the remote desktop, and click the Ctrl+Alt+Delete keys with the mouse.
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