We have a .NET Windows Service that occasionally shuts down on one particular server, about three times in the last month. Logging shows that the OnStop method is being called, so I don't think the service is crashing. However, we don't know what's shutting down the service.
Is there any way to find out what's shutting down the service? Is there anything I can log during OnStop? The Windows Event Viewer just shows application shut down and the security log does not show any user account authenticated at the time.
The service is running in .NET 3.5 SP1 on Windows Server 2003 SP2 (5.2.3790).
There are no service dependencies. This service doesn't depend on any other services and no other services depend on this service.
There is no way to tell from within the service since this called from the SCM - whoever asked SCM to stop your service isn't visible to the service...
I think your main option is checking the EventLog around that time... are other services being shutdown too ? is any scheduled taks running etc. ?
A "rather dirty" option (last resort/desperate) would be to set CanStop to false... in this case there will be someone seeing a problem in stopping your service and "hopefully" ask you why your service is not stoppable...
From my limited experience, permissions and security can tend to cause all sorts of problems for windows services.
Under what account does the service run? (E.g. System account, network service etc).
Something I've had to do in the past is setting up the service to run under a network account with appropriate permissions. You can do this from the Properties window (right-click on the service in the 'Services' management console. In the Log On select This account and choose the account you want to use and enter the account password.
Related
I created a server application that always need to be online and running.
In case that my application is been shutdown i want to restart the application.
Is there a way that "Windows service" will be my online insurance?
If not is there another way?
Thanks.
Yes, windows services can be set to restart if they fail.
In case that my application is been shutdown i want to restart the application.
This makes NO Sense and you should not do it.
If the admin shuts you down (and that is the only way a service is shut down) then he has a reason - maybe he has to apply emergency patches or something else.
If the app CRASHES that is another thing (and windows services can be set up to automatically restart when crashing), but if you geta shutdown request do NOT restart as a service. Never. I can name you a dozen cases where it would be stupid - mostly around system maintenance that you would interfere with. You basically risk being terminated because the computer is switched off.
If your application is not a windows service you need to learn the basics how windows works, because it is ridiculously crappy to have a normal application act as sever process. For anything, a user must be interactively logged in. Next time I see a server with a logged in user because some stupid programmer could not do his job I promise I (censored).
I have a WCF service hosted in a Windows service.
This service the WCF have one metohd and in this method I have one important line :
Process Browser = Process.Start("iexplore.exe", hostUrl);
I install Windows service as local system, but when I'm trying to invoke that method, everything seems to execute, except that one important line... and IE didn't open.
I would like to add that the method itself is not in the service itself but in one of the service dll reference
Any idea why?
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/63a7d1ec-7077-489a-a250-f7422f04317b
" in order to get the service to actually show the UI, you'd have to set the service in Computer Management to allow it to interact with the desktop. In the services window in computer management, go to the properties of your service, and on the Log On tab, check "Allow service to interact with desktop" "
Since Windows Vista MS has been adding lots of security-related changed esp. in the area what Windows Services can/can't do. Anything "desktop-like" (printing, accessing network shares, using Office Interop etc.) is harder and harder to get working.
You should rethink your design since IMHO any "server-like process" (for example a WCF service) can be accessed in parallel by multiple requests and thus should NOT use processes which are NOT designed for this type of interaction... what happens if your webservice starts multiple IE instances that way ? Will IE behave as you need/expect it ?
IF you really really MUST do it this way you should have
a normal desktop process hosting the WCF service
OR
two processes, one your Windows Service and one running as a normal desktop process dealing with IE... these two process communicate via IPC
Under what user is the service running? Try running it under the currently logged in user, with privileges to interact with the desktop and see if that helps.
In general, its not a great idea to have services launching GUI processes. For example, what if no one is logged on. What if many people are logged on? Should it open in all sessions... etc. Have you considered exposing a simple (e.g. Net.NamedPipes) endpoint on your service, and writing a small client UI to interact with it?
Is it possible to spawn a process on a remote server, from a WCF service hosted as Windows Managed Service, when the service is running as LocalSystem?
I need people to be able to execute things on remote servers under the context of their own accounts (basically like PSExec - which isn't an option).
I've made some half-hearted attempts to do this before, but when using process.start, cannot get the process to run as a specific user, if the Windows service hosting the WCF component is running as LocalSystem.
I know this can be acheived by other methods, but I specifically would like to know if the above is achievable - Windows service running as LocalSystem & hosting WCF service, then spawning a process as a specified user.
Thanks
Mick
You could use the Process.Start method which allows you to specify the user under which the process will run.
I have created an SMS application in .NET.
I wanted that the application should run when the computer starts, even before the user logs in.
Just like the SQL Server.
You need to create your application as a Windows Service. The linked MSDN page will provide full details.
Microsoft Windows services, formerly known as NT services, enable you to create long-running executable applications that run in their own Windows sessions. These services can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface. These features make services ideal for use on a server or whenever you need long-running functionality that does not interfere with other users who are working on the same computer. You can also run services in the security context of a specific user account that is different from the logged-on user or the default computer account. For more information about services and Windows sessions, see the About Services section in the Platform SDK documentation in the MSDN Library.
You could consider making it a Windows Service.
You'll have to write a service. Start here...
Wrap your application in a Windows Service, using the .NET System.ServiceProcess namespace.
The System.ServiceProcess namespace provides classes that allow you to implement, install, and control Windows service applications. Services are long-running executables that run without a user interface. Implementing a service involves inheriting from the ServiceBase class and defining specific behavior to process when start, stop, pause, and continue commands are passed in, as well as custom behavior and actions to take when the system shuts down.
Use ServiceEx to make a service from your executable: http://serviceex.com/ , just write one INI file, you can choose if application's window is hidden or showed etc.
We have encountered a very strange situation when we deployed an application at a customer site. This application is implemented as a service using C# on .NET 3. The application communicates with a web service that is written using gSOAP. In our .NET application, the classes that wrap the web service were created by performing "Add Service" in Visual Studio and referencing the WSDL. Communication is performed using HTTPS, but using port 35000.
What we are seeing is that when our application runs as "Local Administrator account" everything works well. However when our application runs as any other account, including "Local System account" and even a user account with network admin privileges, web service method calls sometimes time out. Other times they succeed but after a very, very long time, e.g. 100 seconds instead of less than 1 second as expected.
This customer is using Cisco switches in their network.
We have not encountered this behavior at other sites. Any insights or suggestions would be greatly appreciated.
Does the customer have BI rules on the firewall hardware? (I'm grasping at straws, but we got similar behavior from one of our clients consuming one of our services a few years back because they had enabled some funky BI rules on the firewall.)
Any event log messages for timeouts, exceptions, etc?
Is the application a windows service? Are you using RunAs to run under a different user context? Does it require desktop interaction or have any references to System.Windows.Forms?
#Comment 1:
Windows service, Web Service, WCF Service?
Enable security auditing for both the local and remote machines for resources the service is likely to use.
Another thing is to add debug level logging like this... (Sorry for the pseudo VB)
Sub OnStart(args())
LogToFile("Starting Service, processing arguments")
'process args'
LogToFile("ArgsProcessed calling main worker method")
'call main worker method'
End OnStart
Sub LogToFile(message as String)
If (AppConfigKeys[debugLogging] = True) Then
'writes "DateTime.Now.ToString() & "-" & message" to a text file log'
End If
End Sub
Embed this kind of logging into the application before and after any process that is likely to fail.