I have a windows service which gets the screenshots. But its creating only black screens. I know this happens because of session 0 isolation. I searched on internet and couldnt find any approved solution for this problem any working ideas will be really good.
1- Is there a way to change the session of a windows service and get the desktop screen of another user's session like session 1, session 2?
2- Is there a way to start a console application which runs in an another session other than session 0 from a windows service?
a windows service is designed to run also when there are no users connected, it works like a server process always up and listening, or up and doing something, or idle.
I think what you need is a client application which runs inside every logged user' session and eventually does the job then, if needed, communicates with the service to carry some job done.
I am saying here that instead of having the windows service running in another session than 0 you can create a small executable (probably with no UI at all) that starts up from the start up folder of all users at every user login. such application is then running inside the proper session and has access to it, it can get the screenshot then either store it somewhere itself or call some end points in your Windows Service (running always in session 0) and make the service to elaborate the screenshot taken from the client application of it.
this is the way I would do it, not trying some "magic" to tell Vista and 7 to start a service inside a session of a user that in the end is not logged in yet when the system starts.
Is there a way to change the session of a windows service and get the desktop screen of another user's session like session 1, session 2?
No.
Is there a way to start a console application which runs in an another session other than session 0 from a windows service?
This can be done but it's messy. It involves impersonation of the logged on user, manipulation of user tokens, and launching a process into a different session with CreateProcessAsUser(). This article describes what is needed.
As an aside, you don't want a console application because that will splat a console window on your screenshot. You just want a standard Windows app (using the GUI subsystem) but one that does not show any visible windows.
Related
I have searched everywhere and tried just about everything and I am starting to think this is not possible.
I have a service running in Session 0 (win7) as SYSTEM.I need to launch an external application. If I simply launch the external application as SYSTEM, the application launches and I can see the GUI (if I click over to Session 0 using UI0Detect). In addition to me being able to see it, my service that launched the application can actually take a screen shot of the GUI and send it back to my servers. - at this point all is good.
The issue - there are cases where the external application is not allowed to run under the SYSTEM context. In these cases I must launch as a different user. I have another service running as an actual user in Session 0. I then launch the external application as this other user. The external application is launched in Session 0, and I specify WinSta0\Default to ensure that the application GUI launches on the same desktop that my SYSTEM service can see. When this happens UI0Detect pops up giving me the impression that i will click over and see my window. When I get over to session 0 or when my service attempts a screen shot, there is just a small black box. It's almost like only the SYSTEM account can render windows in session 0 - is this true? anyone know if user accounts running in session 0 are able to render a GUI?
I am not looking for code on how to launch an application from session 0 to an active user desktop. That is well documented. What I need to know is how to pull off the reverse (sort of). I need to launch a GUI in session 0 from an account other than SYSTEM.
From MSDN: "If the service type specifies SERVICE_INTERACTIVE_PROCESS, the service must run in the LocalSystem account."
So there is no supported way to do what you're trying to do. However, it might be possible to get it to work by getting the service that runs as SYSTEM to change the permissions on the desktop (and perhaps the window station) in question. Keep in mind that sharing a desktop in this way means that if the application or the user account in question is compromised, it may be able to compromise the system account.
Alternatively, you could try creating a new desktop in session 0 (with appropriate permissions) and launching the application there. I'm not sure if the interactive user would be able to see this desktop, but you could take a screenshot by launching another application in the same desktop (and preferably in the same user context) to take the screenshot on your behalf.
At the moment we have .NET WinService started under LocalService user at windows start. The service launch another WinForms Application using Process.Start().
But there are several problems in this solution:
We don't wait for an interactive user logon and the Application falls because it tries and fails to initialize DirectX device.
Application launched under LocalService perfectly interacts with user desktop in Windows XP. But it doesn't work in Windows 7 because of there are different graphic stations for each user in win7.
Sometimes we need to run application with current interactive logon user rights.
Does anybody know how to wait for user interactive logon in the service and start WinForms Application with these user rights?
I think this helps to solve all problems.
You will need a separate client app. Check out this document, page 6: http://msdn.microsoft.com/en-us/windows/hardware/gg463353.aspx.
For your monitoring/restart scenario look at CreateProcessAsUser as mentioned in the document. You will almost certainly need to have your client app coordinate with the service for this, and it's still pushing a square peg into a round hole.
I would try using a combination of the answers above.
To solve #1
At user logon, launch the Winforms application using autostart in registry or startup folder. Make it notify the service that it was started successfully.
To make sure that the Winform app is started successfully after user log on:
Have your service that checks if application is started running in the background as you have now but don't let it do the initial startup.
Instead just let it register when user logs on, should be possible to do by listening to OnSessionChange.
Set a delay for X number of seconds to allow the login/startup process finish before it starts checking for a running application (ok maybe not the best solution).
If the service discovers that the application is not started or crashes, restart it from the service using the method Mark points out, CreateProcessAsUser.
Is it possible that this just isn't the right approach for what you're trying to do? It seems possible that you'd be better off putting the monitoring logic or whatever has the uptime requirements into the service so that it's "always on" so to speak. Then you would be left with UI logic in the WinForms app, which could be open or closed with no ill effect.
I have an application, written by me in C#.net 2.0 - when the application is opened, a timer will check every 3 seconds for x. If x happens, it shows a warning in a windows form.
Is there a possibility to install this timer and the windows form call in a windows-service? So that the timer ticks every time a system is up and shows the message then?
No, it is not possible to have a service display a form. This is by design, since a service is supposed to run without a user interface
You can have a regular application that communicates with your service and displays the warning, but I don't know how exactly this is done.
IMO, you don't need a service, just create a regular application without a main form that runs in the background, performs your check, and displays a warning when necessary. You can add that application to the Run section of HKLM or HKCU, so that it is always started when a user logs on to the system.
Windows Forms cannot be displayed from a Windows Service. A Service runs only in the background.
You can have a separate Windows application that communicates with the Windows service and display warnings, information, etc.
To do this, the service runs on the LocalSystem account, and you have to enable the property for the service to interact with the desktop.
Services are forbidden from interacting with the desktop, including displaying windows or forms. In windows 2003 and XP you could work around the issue by marking the service 'interactive' and this would allow the service to display on the user session, but as of Windows 2008 and Vista this is enforced and services can no longer interact in any fashion with the user.
When services need to display anything, the solution is to split the logic into two separate processes, one being the service and one being a normal user process. The user process runs launched by the user, in its session (it can be launched automatically at session start up) and it connects to the service via some IPC channel (shared memory, named pipes, sockets etc). The service can then display anything it wishes to the user by asking the user process half of the application to display what it needs to display.
As others have said, remember that a windows service is supposed to be a background, never-interacting-with-the-user program. Many services run even when the user is not logged on -- how would they go about displaying a form when there's no desktop for them to display it on?
That said, it shounds like you're trying to shoehorn something into a service that shouldn't be a service. If you want something that runs in the background and still interacts with the user, look into making a lightweight system try application. In fact... here's a helpful tutorial:
Lightweight System Tray Application (NotifyIcon Based)
I am working on a console application that I want to run in the background of machines from the moment they boot to shutdown. Now I know that it would be optimum to create a Windows Service, but in this case I need to be able to intetact with certificate stores and I do not believe that a local service account certificate store will do.
I am looking at System.Timers for keeping the application running rather than bludgening in to death with an infinite while statement, is this a logical way to handle this or is there a better way in which to keep the application open? The application will be checking into a SQL database frequently to see if there is any work to do.
You can run Windows Services under any user with appropriate privileges. You are not required to run it under Local Service account.
Alternatively, you could use a tray icon to keep you application running, see here for a sample.
Although, you can run the application as a windows service it requires additional installation overhead. Also = as far as I understand the OP - the application should close when the user logs out, this does not hold true for windows services. So you will have close it explicitly when this behaviour is required.
You could create a windows service and impersonate the user to access the necessary certificate stores. See this question: SO Question
Now I know that it would be optimum to create a Windows Service, but in this case I need to be able to intetact with certificate stores and I do not believe that a local service account certificate store will do.
In Windows XP:
Start->Settings->Control Panel->Administrative Tools->Services
Right click on your service->Properties->Log On tab->This Account->Specify account to run as
It's something similar for Windows Vista and Windows 7 but I'm on an XP machine right now.
I am looking at System.Timers for keeping the application running rather than bludgening in to death with an infinite while statement, is this a logical way to handle this or is there a better way in which to keep the application open?
A System.Timers is fine for periodically doing something. Again, you can implement this in a Windows service though.
We have to run a process from a windows service and get a screenshot from it.
We tried the BitBlt and PrintWindow Win32 calls, but both give blank (black) bitmaps.
If we run our code from a normal user process, it works just fine.
Is this something that is even possible? Or could there be another method to try?
Things we tried:
Windows service running as Local System, runs process as Local System -> screenshot fails
Windows service running as Administrator, runs process as Administrator -> screenshot fails.
Windows application running as user XYZ, runs a process as XYZ -> screenshot works with both BitBlt or PrintWindow.
Tried checking "Allow service to interact with desktop" from Local System
We also noticed that PrintWindow works better for our case, it works if the window is behind another window.
For other requirements, both the parent and child processes must be under the same user. We can't really use impersonation from one process to another.
Currently i can't find the corresponding links, but the problem is, that a windows service runs in another session than a normal user application.
In XP this was not fully true. Here are all services started in Session 0 and the first user who logs into the system will also run in Session 0. So in that case, tricks like Allow service to interact with desktop work. But if you fast switch to another user he gets the Session 1 and has no chance to interact with the service directly. This is also true if you connect through RDP to a server version (like 2003 or 2008). These logins will also start in a session higher than 0.
Last but not least there is another drawback by using the interaction with the desktop:
If you enable this option and your service is running under the (default) SYSTEM account it won't be able to create a network connection anymore.
The correct way to get a custom GUI that works with a service is to separate them into two processes and do some kind of IPC (inter process communication). So the service will startup when the machine comes up and a GUI application will be started in the user session. In that case the GUI can create a screenshot, send it to the service and the service can do with it, whatever you like.
Have you tried to run as Local System with the "Allow service to interact with desktop" checked?
I don't think this is possible.
We had to change our scenario where our application wasn't started from a service, but was a standard windows program that has a NotifyIcon in the corner.
If someone still finds a real answer, let me know.
It works using Local System with the "Allow service to interact with desktop"
You can set it programatically using this sample code:
http://www.vbforums.com/showthread.php?t=367177 (it's vb.net but very simple)