I need to lock the workstation from a windows service written in VB.Net. I am writing the app on Windows 7 but it needs to work under Vista and XP as well.
User32 API LockWorkStation does not work as it requires an interactive desktop and I get return value of 0.
I tried calling %windir%\System32\rundll32.exe user32.dll,LockWorkStation from both a Process and from Shell, but still nothing happens.
Setting the service to interact with the desktop is a no-go as I am running the service under the admin account so it can do some other stuff that requires admin rights - like disabling the network, and you can only select the interact with desktop option if running under Local System Account.
That would be secondary question - how to run another app with admin rights from a service running under Local System Account without bugging the user.
I am writing an app to control my kids computer/internet access (which I plan to open source when done) so I need everything to happen as stealthily as possible.
I have a UI that handles settings and status notifications in the taskbar, but that is easy to kill and thus defeat the locking. I could make another hidden Windows Forms app to handle the locking, but that just seems a rather inelegant solution.
Better ideas anyone?
Am am not totally satisfied with my answer but Window's security leaves me little alternative. Anything opened bu the service (through Process, Shell whatever) will not have desktop access. I understand the reasons behind the limitations Microsoft has created but still frustrating!
My Service uses IPC to tell my UI to lock the computer. Here is a basic link on doing that:
http://anoriginalidea.wordpress.com/2007/08/09/simple-inter-process-communication-in-vbnet/
See his reference links for additional data.
However, that still does not quite work. Also see this link for how to do it without the Access Is Denied messages:
Make sure your URIs are correct. The portName property on the server side is the first part of the IPC path in the GetObject method call. The second part maps to the second parameter of the RegisterWellKnownServiceType call on the server side.
And apparently the portName properties need to be DIFFERENT on the sever and client sides.
If you get "Failed to connect to an IPC Port: The system cannot find the file specified." on your client then the server has not started yet so there is nothing to hear you scream.