I have got a custom GINA (Windows Server 2003 R2) that is launching a modal window within WlxLoggedOnSAS and WlxLoggedOffSAS that contains all my workflow. It chains to MS GINA.
When I try to execute a remote script using telnet (like shutdown), it fails. Does any one know why this happens? And is there a way to handle this? Possibly handle an event in the GINA?
I have been hunting for a solution for a while and haven't found any.
I managed to figure this out. Just answering my own question for the benefit of anyone else running into the same scenario. Basically, I have classified GINA in 3 states -
Secure Access Seq (CAD) Screen : This is the one which prompts users to type in Ctrl-Alt-Del. Remote telnet commands will work here.
WlxLoggedOffSAS Screen : This is the login state where the custom GINA UI or MS GINA UI gets created. Generally, this thread is blocked. At this point, remote shutdown commands won't work. To deal with this situation, read on.
WlxLoggedOnSAS Screen : This is the desktop lock state where the custom GINA UI or MS GINA UI gets created. At this point, the shutdown command will work with the /f switch (force shutdown).
To get around state 2, you can do one of two things:
Use something like Windows Task Scheduler to initiate the restart.
Add a new method to your custom GINA DLL that essentially switches to the CAD screen (state 1). You can invoke that DLL method using rundll32.exe. One switched to state 1, just invoke the shutdown and it will work.
Related
In my usecase i need to send API call upon Windows machine shutdown/reboot.
The script i created works as expected from the PowerShell console, but not when defined in gpedit.msc's shutdown scripts location.
I am assuming this is because WiFi adapter somehow gets down before the script gets executed. Added some debug prints and seems that it is a corect observation.
To prove it more i re-defined the same script in user login scripts location - and it worked as expected indeed.
My question is whether it is really correct that a WiFi adapter disconnects before the shutdown script steps into the process, and if yes - is there any way to outsmart it with PowerShell script?
(My theory is that trapping/delaying a WiFi adapter in a shutdown could adress the case, but even if i knew how to do that i smell the same issue here - the adapter will go down before the trap pops up...)
EDIT: the thing is definitely with the adapter power on shutdown call. If i define the User Logoff script - the script works even if i do reboot or shut down.
So despite i didn't find a way to intercept the NW adapter power supply on shutdown (as well as no comprehensive technical documentation of this feature), i definitely found out a way to acheive my usecase - define the user logoff scripts instead of shutdown scripts.
We have a service running on a Windows Server 2003 machine. This service watches a particular folder on an FTP server, and when files appear there, it invokes one of a few different executables to process them.
I've been asked to find a way for staff to be alerted in some way when this service hangs or stops.
Can anyone suggest anything with just this much information? If not, what else would you need to know?
Seems we could write ANOTHER service to watch THIS service, but then there's a chance THAT one would stop ... so we haven't resolved anything.
About the only thing that I know if is writing another application or service that monitors if that service is running; something like that shouldn't have any unexpected behavior and stop, hopefully.
Another thing to do is go to the service in Windows, go to its properties, and then go to recovery options. From here, you can set the behavior of a service if it is to fail. The options in Windows 7 are to restart the service or computer, or run a program. This program could send some sort of notification. However, I don't know if any or all of these options exist in Server 2003. This would also not likely work if the service were to just hang, but a service watching it probably wouldn't either.
Also, if you have the source code, you can override some of the service-related methods such as OnStop() (for C#) to send a notification, but I don't believe this works with a failure.
My personal choice would be to set the recovery options just to restart the service on failure, unless it repeatedly fails, which there is also an option for. But just do what you think will work best for you; there isn't really a fail-safe method to do it.
UPDATE:
I did check, and Server 2003 does indeed have the same recovery options in the service manager. As the guys said above, you can deal with that, but it is only in C++ from what I have seen; there is also a command prompt way to do it:
sc failure [servicename] reset= 0 actions= restart/60000
I found that command here and you can look at it more in its MSDN documentation. You could call this command from C# or other languages if you are not using C++, or use it directly from the command prompt if you do not have the source code.
Use ChangeServiceConfig2() to define Failure Actions for your service. You could use that to invoke an external command to issue the alert (or do pretty much anything else you want) if the service terminates unexpectedly.
The SCM (the component which handles services) has built-in auto-restart logic that you can take advantage of to restart your service, as necessary. Additionally and/or alternatively, you can configure 'custom actions' to be associated with a failure of the service - the custom action can include launching a program of your own, which could then log the failure, and perhaps manually restart your service.
You can read more about such custom actions on MSDN by looking at the documentation of the structure used to configure such actions: SERVICE_FAILURE_ACTIONS. Once you fill that structure, you notify the SCM by calling the ChangeServiceConfig2 function.
Please don't ask "well, what happens if my failure handler program crashes" :)
First off, I know some proper ways of making a truly interactive Windows Service.
The situation is, I do have a tool that does not interact with the user as such. However, it does display non-blocking notifications both via popup windows and via the Windows Notification Area (aka System Tray). It also writes a logfile of the notifications it displays.
This tool is normally spawned by a main user application and as long as the main application is a normal application, these notifications do work as intended.
When this tool is spawned by a Windows Service, no notifications are displayed, naturally. (The Desktop Session for the service isn't visible.) But this would be OK, we have the logfile and these notifications are just - notifications, nothing the user absolutely must see under all circumstances.
The question now becomes: Is a process running in the context of a Service (the Service itself or any process it starts) "allowed" to make Windows API calls that display a visible GUI?
Will most Windows API calls (e.g. creating and showing a window, using Shell_NotifyIcon, etc.) behave the same in the invisible session of the service?
Or would I have to make sure throughout the source code, that no GUI displaying/modifying stuff is called in the context of the service?
And yes, calling ::MessageBox is a bad idea because it will block. But I can handle these calls.
And yes, this could be designed better, but it's what I have at the moment and it would be nice if I hadn't to rip the whole tool apart to make sure no GUI related code is run in the service.
GUI elements from a Windows Service are shown on Session 0. On Windows XP & 2003, users were allowed to log in to Session 0 and interact normally with the windows created by a service, but Microsoft put a knife in the heart of interactive services in Vista (and beyond) by isolating Session 0.
So, to answer your specific questions:
Is a process running in the context of a Service (the Service itself
or any process it starts) "allowed" to make Windows API calls that
display a visible GUI?
Will most Windows API calls (e.g. creating and showing a window, using Shell_NotifyIcon, etc.) behave the same in the invisible session
of the service?
Yes, GUI calls are allowed and should succeed as normal. The only notable exceptions that I know of are those related to tray icons because the process providing the task bar (explorer.exe) is not running in the isolated Session 0.
Or would I have to make sure throughout the source code, that no GUI displaying/modifying stuff is called in the context of the service?
That should not be necessary, though you should proceed cautiously with any GUI interaction from your service. Test thoroughly!
I would like to provide some info wrt. Raymonds Chen's comment to the other answer
You should avoid presenting UI in a service because you may trigger
the UI Detection Service which will switch the user to your service UI
temporarily. – Raymond Chen
I find these good articles:
What is Interactive Services Detection and Why is it Blinking at Me?
Inside Session 0 Isolation and the UI Detection Service, Part1, Part2
Where one can find explanation on what the UI detection service (UI0Detect) is and does and how it's supposed to work.
Interactive Services Detection (the blinking button on the taskbar) is
a mitigation for legacy applications that detects if a service is
trying to interact with the desktop. This is handled by the
Interactive Services Detection (UI0Detect) service.
However, one must note that this only can work if the service that is trying to view a GUI has the flag "Allow service to interact with desktop" set, because only then the service process will be running on WinSta0of Session0 even allowing it to show anything at all.
Alex Ionescu mentions this:
If UI0Detect.exe ...
the SCM has started it at the request of the Window Hook DLL. The
service will proceed ...
The service first does some
validation to make sure it’s running on the correct WinSta0\Default
windowstation and desktop and then notifies the SCM of success or
failure.
So, to come back to Raymond's comment: As far as I can see, as long as a service doesn't tick the type= interact option (see sc.exe), and normally you don't tick this, the UI0Detect service doesn't do anything and there shouldn't be any "danger" of triggering it.
Note: The information above is based on my limited research and tests on only a single Windows 7 PC.
I have a C++ application which used Mutex, Events,Semaphores for synchronization. While hosted in windows 2008 server/Windows 7, this application is not starting from a remote client.
I used telnet client to connect remotely to this application and saw that telnet server is running under session 0 and therefore it is trying to start my application under session 0. My application is trying call OpenMutex to open a mutex which was created by another application running locally (in session 1).
I can make my application work by perpending "Global\" to mutex name. What I am looking for is a way run application without making this code change. Is it even possible? Is it possible to launch telnet service under session 1.
CreateMutex(&sa,FALSE,Buffer, "MyMutexName"));
I can modify this to CreateMutex(&sa,FALSE,SYS_ID2(szSysIdBuffer, "Global\MyMutexName")); but is there any other way other that making this change.
Thanks
You probably know the document http://www.microsoft.com/whdc/system/sysinternals/session0changes.mspx which describes problems with the Session 0 isolation. The old way to make a service interactive which are described in http://msdn.microsoft.com/en-us/library/ms683502.aspx not works on Widows 7 because Terminal Services are active per default.
So it seems to me that in your case the way with the "Global\" prefix, which you currently use, is really the best one. To understand the complexity of an other possible way you can read following Process with administrative privileges run on user logon.
I want to stop the shutdown / log off API which appears when you have programs open to confirm a shutdown/logoff.
I have an application already that send a reason to the API.
I know this is bad practice but I really need to override / cancel the shutdown with out displaying the API after 5 seconds.
is there any way to hack this or run a custom shutdown script to override the shutdown.
thanks in advance
it doesnt matter about holding it for5 seconds just catching it if it is pressed once. I can do that but vista shows a API screen after 5 seconds which All i want is vista not to show that.
vista shows that because I prevent it from shutting down.
You may want to look at this:
http://msdn.microsoft.com/en-us/library/aa376871(VS.85).aspx
When I did this functionality I had to do everything in unmanaged C++ as I had problems trying to set the priviledge by using Interop.
You need this flag: EWX_FORCE in ExitWindowsEx.