A legacy Service that I work is freezing due to database issues. And I'm looking for a simpler solution than fixing it.
In Aplication Form Version (Delphi), Windows recognize and show message that application is not responding.
Can Windows recognize when a service is not responding and restart the service?
In Service Properties the Recovery is only for failures.
In Aplication Form Version (Delphi), Windows recognize and show message that application is not responding.
Only if the main UI thread is blocked, but you shouldn't ever do anything in the main UI thread that can block it. Bad code design.
Can Windows recognize when a service is not responding and restart the service?
Not automatically, no. You need to fix your database code so it doesn't freeze up anymore in the first place. If that is not an option (which I highly doubt) then you will have to write a separate watchdog thread/process to monitor your code/service and kill it if it freezes up. If you kill the entire service, then Windows failure actions can be used to restart it.
I have up until now been using my own restart application utility.
But I now see that there is a dedicated restart manager since Vista.
This is useful for me because I now limit my application to Windows 7 or higher.
Currently, I offer a manual restart when the user changes the application language.
Also, after they have downloaded an updated installer (Inno Setup) it shuts the app down and starts the setup program.
I can't work out how to do these thing with the MFC restart manager. It mentions about adding one line of code to my MFC app and how to simulate scenarios. But what about my specific situations?
If you can please direct me to a good tutorial?
Sorry if my question is off topic and I will remove.
I have an application that was installed as MSI package, I have next version of application that I plan to install in silent mode by special program.
When application is running I catch an issue: not all components of application installed
immediately, some of them will be really ready only after reboot. And I get unstable application.
I can check - is application running and wait until it closed, but I can't check the situation when user click on shortcut during silent installation.
How I can avoid this? Can I lock application during installation?
I suggest implementing Restart Manager support. Vista or later will attempt to shut down your application via the Restart Manager, you can decide how to handle it within your application (prompt user, autosave, something else, etc).
You won't catch the situation where the user starts the application during update, but it will handle multi-user sessions more gracefully than your custom code will.
I need a background application to support my client application, which should always run on the client machine regardless of the main client application is running or not.
Windows Service was my first choice but problems I faced with Windows Service were: ease of control over windows service through main client application, release and installation of patches to the windows service and troubleshooting if windows service fails to run.
So, I started thinking for alternatives to the Windows Service and found that a Windows Forms application with NO visible forms can do it for me. This invisible app should start with system startup and keep running all the time, doing all the work that a Windows Service would do. But before I go deeper into the development, I want to explore the pros and cons of this approach.
Any suggestions/comments on this approach?
Your requirements are more suited for windows service. Main advantage with windows service is that it will start as soon as system comes up, irrespective of anybody is logged into system or not.
To sort out deployment issues, you build your business logic into separate assembly and call the necessary function withing windows service. This way you can deploy just the modified assembly.
Winform application with invisible form will not serve the purpose. HTH
That's not possible. User-mode applications must be started by a user, and will not continue to run when that user logs off. That's the purpose of the SessionEnding event: to allow you to shut down your app gracefully when the user logs off or the computer is shutting down. You can't just start something at system startup and keep it running all the time.
You need a Windows Service for that. But you should be aware that under Windows Vista and later, a service cannot interact directly with the user. They run in a separate process and are restricted from displaying their own UI. It's not clear from the question exactly what your needs are, but this is an important limitation of a Windows Service that is worth considering. A proper design really shouldn't require this, but there are apparently a lot of people to whom this new, more secure behavior is a real surprise. I explain this in more detail in related answers to this question and this other question.
Does anyone have a good guide to capabilities of Windows Services under XP? In particular, I am trying to find out what happens when a program being run as a service tries to open windows, but hasn't been given permission to interact with the desktop.
Basically, I have a program that is/was a GUI application, that should be able to run as a service for long term background processing. Rewriting the program to not display the GUI elements when doing background processing is a major effort, so I'd like to see if there is just a way to ignore the UI elements. It is sort of working now, as long as too many windows aren't opened. I'm trying to figure out what limits I might be running into. Ideally, there would be an MSDN page that discusses this, but I've had no luck finding one yet.
Generally, services should be designed to not have any visible UI. The entire point of a service is to run in the background, without UI, unattended. (Think SQL Server, IIS, etc.)
In most scenarios, a separate application controls the service's operation, should a GUI be needed. (Continuing the samples I just mentioned, SQL Server Management Studio, IIS Manager, etc.) These separate applications configure and manipulate the service (and occasionally, if needed, bounce said service).
If your service requires occasional UI, and said UI can't be isolated to a control app, then you probably should reconsider the fact that you're using a service to begin with. Perhaps a UI application which resides in the system notification area is the right pattern to use? (E.G., Windows Live Communicator.)
A service in Microsoft Windows is a program that runs whenever the computer is running the operating system. It does not require a user to be logged on. Services are needed to perform user-independent tasks such as directory replication, process monitoring, or services to other machines on a network, such as support for the Internet HTTP protocol
Usually it is implemented as a console application that runs in the background and performs tasks that don't require user interaction.
The installed services can be configured through the Services applet, available from
Control Panel --> Administrative Tools in Windows 2000/XP.
Services can be configured to start automatically when operating system starts, so you dont have to start each of them manually after a system reboot.
Creating a Simple Service - MSDN Article
Writing Windows Services Made easy - Code Project Article
Five Steps to Writing Windows Services in C - DevX Article
If you should be thinking of eventually migrating to a newer OS such as Vista or Server 2008, you will find that you cannot give a service permission to interact with the desktop at all. Therefore, from the point of view of forwards compatibility, you should design your service to not require it.
A service in Windows XP can interact with the Desktop if its "Allow Service to Interact with Desktop" property (MMC -> service properties -> Log On tab) is checked. It is also possible to do so by doing the following:
hWinstation = OpenWindowStation("winsta0", FALSE, MAXIMUM_ALLOWED);
SetProcessWindowStation(hWinstation);
hDesktop = OpenDesktop("default", 0, FALSE, MAXIMUM_ALLOWED);
SetThreadDesktop(hDesk);
But be aware that presenting UI from a service process in Windows XP will almost always lead to a security problem (see Shatter attack). You should try to break out the UI part of your application from the service.
Usually the service won't have permission to write to the window station and desktop, so it will fail; even running applications that load user32.dll can fail simply because user32 has initialization code that wants to talk to the window station and can't get access to it unless the service is running as an administrator.