My Scenario:
I have a Client\server set up on my desktop. I have 3 WCF Services installed through VS command prompt. Everything works fine during the installation but when i actually want to start the services it gives the following message
"The service on local machine has
started and then stopped.Some Services
stop automatically if they have no
work to do,for example the performance
logs and alerts service"
Can any one guide me to the solution ?
The Windows service actually has to do something; otherwise, it will shutdown immediately and you'll get the error you're seeing. "Doing something" usually entails starting a thread in the OnStart() callback of the service. As #sgreeve provided in his comment, refer to the following question for a code example.
Windows Service Stops Automatically
It is also possible that the Windows service is throwing an exception when starting up. In this case, you'll probably want to debug the service to see exactly what is going on. Refer to the following question for how to do that.
Easier way to start debugging a windows service in C#
Related
I want my service to be able to be restarted remotely (by a TCP client which is not part of this question). I configured the service to restart on failure on the Recovery tab for my service. In my code I set the ServiceBase.ExitCode to a non-zero number, say 1. I did not use Environment.Exit to stop the service because it isn't necessary to terminate the process. When I test my service it stops correctly and the Windows System Log reports that my service has stopped with an error. It also names the error. But my service does not restart! When I instead use Environment.Exit(1) the Windows System Log reports that my service has stopped unexpectedly without naming the error. It then does restart the service as if it has failed (like it should).
My question is, why doesn't the service restart with just a non-zero exitcode? The service stops with an error but that isn't failing? Is Environment.Exit the only way to properly trigger a service restart on failure? I liked using the ExitCode better because the System Log is cleaner and more accurate that way.
Did you check the "Enable actions for stops with errors" checkbox on the Recovery tab?
From the technical documentation, the service's exit code is only consulted if that option is checked.
I need to create a Windows Service to watch a folder on our network and action files that are placed within it. The process is quite slow and I need the ability to check the progress from a client application (which will be running in about 10 places on the same network as the machine running the Windows service).
Is hosting some WCF service in the windows service the right way to go about this and if so, are there any resources on how I would do this?
Thanks!
it seems a reasonable approach to me.
you can get details of how to host a WCF service inside a windows service in the MSDN how to
This code project page also has an example.
you might need to debug start up issues with the service, and I find adding a
Debugger.Launch();
to the beginning of the OnStart method is the easiest way of doing that. it enables you to debug through the start up process of your service and see any exceptions that occur.
I have some very odd situation at a client that wants me to maintain some of their software:
upon start/stop, the EventLog entries of a Windows Service are correctly appearing.
But during incoming WCF calls, they are not.
All EventLog creating is going through the same global static factory class.
When I put all classes in a console app, everything logs fine.
When sending those entiries to OutputDebugString, the same happens: windows Service Startup/Shutdown are coming through fine, but WCF execution not.
Where should I start digging?
These kinds of problems are hard to figure out. I would start by attaching the debugger to the WCF service and adding some breakpoints in the logging classes and see if the code actually stops. If not move the brake point to the service and see why it doesn't get into the logging code.
Given that the code works in a console app and only partly in a WCF service my first guess is that it could be a threading issue. But without more info that is just pure speculation.
I have a WCF test service and a test client in the same solution. The service is configured to run on localhost (Ie, "http://localhost:8731/Design_Time_Addresses/MyService/Service") I run the client app and it correctly invokes the service and gets back the correct answer. I've verified via logs that it's definitely running the service that's local to my machine.
However, I can't debug into the service when running the client. WCF is supposed to allow just stepping through, but no breakpoints on the service get hit, and stepping in to the service call doesn't work either. Has anyone ever seen this?
I've checked all the obvious stuff like "is the PDB file being generated?" -- yes, it is. If I run the service project by itself, then hit it with some test client, breakpoints get hit correctly. So debugging on the service works. I can even explicitly "attach to remote process" and debug the service that way. But WCF will not automatically step from the client to the service.
I've had this happen as well. Curiously it seems to happen after I make changes to the build configuration (from x64 to x86). Here's how I've been able to fix it:
Right-click the solution, select Properties.
Under "Startup Project" switch from "Single startup project" to "Multiple startup projects".
Set Action to "Start" for the WCF project.
Even though I'm hosting the project in the local IIS server (not the VS Development Server) this solves it, which is a little puzzling. I suspect that setting a project to "Start" also causes VS to attach to the process for debugging.
http://msdn.microsoft.com/en-us/library/bb157685.aspx
For Visual Studio multi-configurations:
In the Property Pages of your solution, ensure that the "Configuration" for your web-service is set for "Debug", not "Release".
Are you using the automatic WCF service hosting feature in Visual Studio? You can check this by opening the project properties of your WCF service project and navigating to the WCF Options tab. Is the Start WCF Service Host when debugging another project in the same solution checkbox checked? If it is, then this explains the problem.
What's happening is that when you run your client, a separate process is created to automatically host your WCF service. Because it is a separate process, you will not be able to "step into" it when debugging your client. You'll have to run two separate debug sessions, one for your service and one for your client.
An easy way to do this is to put a call to System.Diagnostics.Debugger.Break() in the startup logic for your service. When your service is automatically started by the WCF service host, you'll be prompted to debug it, allowing you to open a second instance of Visual Studio for its debug session.
Also when using VS debug and attaching it to the w3wp.exe process and you have specific port bindings other than http:80:* you must have the debug > web in VS set to the site and port http is running on.
Yes, I got the same problem, WCF uses another processs.
At last, I found a way, i start a new instance(debug->start a new instance) of WCF service first, then start the client side, the breakpoints in the WCF service hits!
One other reason for not stepping into WCF service may be the size of your data that is passed to the WCF methods.
For ex., I was passing an array of dobules of size 1000, and I was getting a bad request error (400) with seeing how the method is run. I made the size 500 and now it debugs the WCF.
In my case, I had published it using Release configuration. You need to select Debug here.
I had similar problem. WCF hosted by WCF Service Host, requests tested by WCF Test Client. My problem was caused by space in build configuration name. As soon as I used configuration name without spaces, debbuging worked.
I guess the real problem was the build output folder ending with folder named by the configuration name.
#msulis - yes, thanks, this remedied it for me. I had also changed recently, the target CPU from any to x86. I couldn't reply directly to you message for some reason so apologize if this comes up as an "answer".
I have a WCF service that does some document conversions and returns the document to the caller. When developing locally on my local dev server, the service is hosted on ASP.NET Development server, a console application invokes the operation and executes within seconds.
When I host the service in IIS via a .svc file, two of the documents work correctly, the third one bombs out, it begins to construct the word document using the OpenXml Sdk, but then just dies. I think this has something to do with IIS, but I cannot put my finger on it.
There are a total of three types of documents I generate. In a nutshell this is how it works
SQL 2005 DB/IBM DB2 -> WCF Service written by other developer to expose data. This service only has one endpoint using basicHttpBinding
My Service invokes his service, gets the relevant data, uses the Open Xml Sdk to generate a Microsoft Word Document, saves it on a server and returns the path to the user.
The word documents are no bigger than 100KB.
I am also using basicHttpBinding although I have tried wsHttpBinding with the same results.
What is amazing is how fast it is locally, and even more that two of the documents generate just fine, its the third document type that refuses to work.
To the error message:
An error occured while receiving the HTTP Response to http://myservername.mydomain.inc/MyService/Service.Svc. This could be due to the service endpoint binding not using the HTTP Protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the server shutting down). See server logs for more details.
I have spent the last 2 days trying to figure out what is going on, I have tried everything, including changing the maxReceivedMessageSize, maxBufferSize, maxBufferPoolSize, etc etc to large values, I even included:
<httpRuntime maxRequestLength="2097151" executionTimeout="120"/>
To see maybe if IIS was choking because of that.
Programatically the service does nothing special, it just constructs the word documents from the data using the Open Xml Sdk and like I said, locally all 3 documents work when invoked via a console app running locally on the asp.net dev server, i.e. http://localhost:3332/myService.svc
When I host it on IIS and I try to get a Windows Forms application to invoke it, I get the error.
I know you will ask for logs, so yes I have logging enabled on my Host.
And there is no error in the logs, I am logging everything.
Basically I invoke two service operations written by another developer.
MyOperation calls -> HisOperation1 and then HisOperation2, both of those calls give me complex types. I am going to look at his code tomorrow, because he is using LINQ2SQL and there may be some funny business going on there. He is using a variety of collections etc, but the fact that I can run the exact same document, lets call it "Document 3" within seconds when the service is being hosted locally on ASP WebDev Server is what is most odd, why would it run on scaled down Cassini and blow up on IIS?
From the log it seems, after calling HisOperation1 and HisOperation2 the service just goes into la-la land dies, there is a application pool (w3wp.exe) error in the Windows Event Log.
Faulting application w3wp.exe, version 6.0.3790.1830, stamp 42435be1, faulting module kernel32.dll, version 5.2.3790.3311, stamp 49c5225e, debug? 0, fault address 0x00015dfa.
It's classified as .NET 2.0 Runtime error.
Any help is appreciated, the lack of sleep is getting to me.
Help me Obi-Wan Kenobi, you're my only hope.
I had this message appearing:
An error occured while receiving the HTTP Response to http://myservername.mydomain.inc/MyService/Service.Svc. This could be due to the service endpoint binding not using the HTTP Protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the server shutting down). See server logs for more details.
And the problem was that the object that I was trying to transfer was not [Serializable]. The object I was trying to transfer was DataTable.
I believe word documents you were trying to transfer are also non serializable so that might be the problem.
Yes, we'd want logs, or at least some idea of what you're logging. I assume you have both message and transport logging on at the WCF level.
One thing to look at is permissions. When you run under Cassini the web server is running as the currently logged in user. This hides any SQL or CAS permission problems (as, lets be honest, your account is usually a local administrator). As soon as you publish to IIS you are now running under the application pool user, which is, by default, a lot more limited.
Try turning on IIS debug dumps and following the steps in KB919789
Fyi, I changed IIS 6 to work in IIS 5.0 Isolation mode and everything works. Odd.
I had the same error when using an IEnumerable<T> DataMember in my WCF service. Turned out that in some cases I was returning an IQueryable<T> as an IEnumerable<T>, so all I had to do was add .ToList<T>() to my LINQ statements.
I changed the IEnumerable<T> to IList<T> to prevent making the same mistake again.