How can I debug an windows service when it is starting?
I have an windows service that is falling to start and I add all the logs that I could but something is happening behind the scenes (between the installed service and Windows) that I cannot see (as far as my knowledge go).
I am not looking for code debugging here but windows message between the service and Windows, but I can't find any in event log, maybe I need to turn it on?
I am thinking that something between the lines of windows think my service is a virus, or windows is not been able to connect to my service by name, something like that.
Does anyone know how I can see this kind of information on Event Viewer or similar?
Debugging of Windows services is quite challenging as they are running in session 0 with no desktop and user interaction possible.
One way to debug your service is to setup a remote debugging session with windbg as described here.
Another way is to use my winsvcdiag tool which should make the process simpler and possible to debug from VS: https://lowleveldesign.wordpress.com/2015/06/22/how-to-debug-windows-services-written-in-net-part-ii/
And I'm not sure what type of event logs you want to see. When a windows service is failing there is usually a brief message in the System log. You may always look if process monitor is reporting any errors for your service.
Related
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.
this question has been asked before but there is no conclusive answer.
I've written a Windows service in Delphi, which needs to generate a beep under certain condition. This works fine on XP, however fails in Windows 7 or 2008.
Note:
Beep can work if i create a console program instead of a service - using PC speakers.
Beep cannot work in a service even if i enable "allow service to interact with desktop" or even assign administrator rights to the service.
My question: Is there a way I can call beep API such that it works in a service? Thanks.
You can't do this in Vista and up. Services run in a different session and so don't have access to the speaker.
Update: Someone found a way here. it involves IOCTL, and is available to drivers and services.
Original answer:
The only way I know of to interact with the user would be to have your Service communicate with a small user-agent process which would be added to HKEY_LOCAL_MACHINE\CurrentUser\Run to autorun.
This is the usual pattern in vista and win7 where no user interaction is possible directly from the service:
MyLittleService.exe has no access to the user. But it can communicate via a named pipe with a tray icon utility.
MyLittleTrayIcon.exe communicates to the service, and can also be told to signal the user with message boxes, beep via whatever method (windows sound effects probably would be better than trying to access the PC speaker which is not guaranteed to exist on every PC anymore), etc, and maybe even can be used to control the service (restart it, reload the configuration etc).
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.
As part of my app, my users install a Window Service (msi file written in C#) that uploads data to me. These Windows servers are usually behind all kinds of firewalls etc. and run by IT staff so it's difficult to get in touch with anyone to debug.
What can I put inside my application that would make it easier to figure out things? I'm not looking to do anything that would be considered "shady" but here are some ideas I've thought:
Open log files that are relevant to me in a separate thread and stream it back up to the server
Setup some kind of reverse tunnel (not sure if there is a sane shell environment on Windows that I can connect to)
Any ideas or thoughts would be appreciated.
The author of the logging framework we use (the object guy's) has a service that might be useful for you.
You can debug .NET and native code through remote debugger with Visual Studio, see the post of John Robbins about it : http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/06/15/vs-remote-debugging-across-workgroups-or-domains.aspx
I'm looking to pass parameters into a Windows Service not only upon launch but while it's still running as well. I've heard the best way to do this would be through the COM but I have no idea where to even get started. Are there any good places you can recommend where I can find some helpful information about how to get started with the COM and Windows Services? Thanks in advance!
You can't just get a piece of duct tape and magically "attach COM" to any Windows service. While it is true that you can host a COM object in COM+ and activate it in a Windows service process, but this is not just adding new functionality - it will change the behavior significantly.
In addition to named pipes you can use RPC - start RPC server in the service and make calls to it from the other process.