1

I am looking to implement a feature when an application running as a windows service (as localsystem) will display a modal warning, something similar to a shutdown screen or UAC warning screen. Basically, something that is impossible to dismiss without noticing

There are 2 things that I don't know how to implement:

  1. It is my understanding that Windows Vista+ no longer allows an application to generate system modal windows. Is it possible to bypass that, and is there any easy way of doing that? The only alternative I could think of is opening a full-screen window and intercepting alt+tab, ctrl+alt+del, and such

  2. I also believe that it is not possible to display a UI in user session from a service, since it runs in another session. Is there a hack that allows bypassing that? One thing I could think of is: find and inject code into csrss.exe or winlogon.exe running in given session, and invoke remote thread. Another approach is to obtain handle to winlogon and CreateProcessAsUser(). Is there another, easier way?

galets
  • 17,802
  • 19
  • 72
  • 101

2 Answers2

2

If the service is running as local system, WTSQueryUserToken is the easiest way to get a token to run code in a given session.

Instead of a modal window, consider creating a new desktop (CreateDesktop) and switching to it. You can't suppress control-alt-delete, but I believe that when the control-alt-delete menu is dismissed the system will normally return to your desktop. All other special key sequences should be suppressed because hooks only affect the desktop associated with the application that installs them.

Harry Johnston
  • 35,639
  • 6
  • 68
  • 158
1

  1. I'm not sure what you mean by "system modal windows". Do you mean a message that gets displayed to the user even on the login screen?

  2. This is true, even if UserInteractive is set to true in the registry, Vista and later will not allow access to the Windows GUI from services. There are a few ways around this, the way I do it is I have a simple helper application that runs in the background (not as a service, just a continuous process) which uses IPC over .NET remoting to process simple messages which a service can easily connect to and send. If you want, I can post a more concrete example but for now here is a step by step of how you can implement this (I'll be using .NET Remoting for this example, but the same basic principle should apply for whatever IPC solution you use):

    1. Create a program that acts as a .NET remoting server (NOT as a service, just a continuous process) using the IPC protocol. The remotable interface should contain at least one member for accepting new data, in most cases strings work fine for me. The implemented class should also be able to continuously process new messages.
    2. Connect to the service using the remotable interface implemented in step one, and send a message to be displayed to the IPC server.
    3. The IPC service should process this message and display it to the user using your preferred means or displaying messages to the user. I personally use a modal form in a separate thread which allows the end user to copy the message if they like.
codewario
  • 19,553
  • 20
  • 90
  • 159
  • While this approach is simpler than launching a process in the user's context, note that it is less efficient; it requires an extra process to be running in the user's context at all times. – Harry Johnston May 21 '13 at 19:25
  • In my case, I stuck the listener in a tray application which is already used to manage/monitor the service. Yes it does require the presence of another process running at all times, but since we already had another process that runs at user login I just threw the listener in there. This technique also works when the service is not running as the LocalSystem account. – codewario May 21 '13 at 19:45