We have a WCF service hosted in windows service. Unfortunately, the service has crashed and upon examining the event viewer logs, found the below error message.
Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in
the .NET Runtime at IP 000007FEF9A258EF (000007FEF98A0000) with exit
code 80131506.
We have already implemented proper exception handling and even though the service is crashing when an exception occurs. Also, we are unable to trace out what exactly is the error message from the event viewer logs.
Could you please guide me on the above error? Please let me know if you need any more information
Related
I use simple a configuration to run a Publish/Subscribe scenario using NServiceBus.
I'm getting this exception:
The remote server returned an error: (404) Not Found.
at System.Net.HttpWebRequest.GetResponse()
at Raven.Client.Connection.HttpJsonRequest.ReadJsonInternal(Func`1 getResponse) in
c:\Builds\RavenDB-Stable\Raven.Client.Lightweight\Connection\HttpJsonRequest.cs:line 332
It's not a fatal one, it's handled somewhere in NServiceBus/RavenDb code, but I wonder why it's happening. I see it only when I select "Thrown" option for "Common Language Runtime Exceptions" in Exceptions window.
I would recommend adding Log4Net (easiest is through the Visual Studio Package manager), and then telling NServiceBus that it should use log4net when configuring the Bus:
Bus = Configure.With()
.Log4Net()
.DefaultBuilder() //...
You'll find that NServiceBus logs plenty (either to the Console window of the NServiceBus host, or to the Visual Studio debugger window), and it's very likely to contain the reason why that 404 occurs.
I have a Silverlight client which is talking to a WCF Service and performing some actions
Most of the time these actions will be quick, but often they wont be so I need a way of avoiding WCF timeouts by essentially passing the work onto its own "thread" server side and having a way for the client to know when the operation has completed
I have searched on here and found reference to the article below
http://msdn.microsoft.com/en-us/magazine/cc163482.aspx
I have downloaded the sample
It was targeting .NET 2 so I have updated it to 4.5 and the required IDesign folder didn’t exist in c:\program files so I have created it
Once I installed MSMQ and tried to run the client I get the error below
HResult=-1072824317
Message=An error occurred while opening the queue:Unrecognized error -1072824317 (0xc00e0003). The message cannot be sent or received from the queue. Ensure that MSMQ is installed and running. Also ensure that the queue is available to open with the required access mode
Does anyone know what the problem is here? I am very new to MSMQ
I notice that this code is very old (2006), so is there a better way of doing this nowadays?
Paul
I am trying to access a remote WCF service (using netMsmqBinding) hosted in a windows service and am getting the error:
Message: System.TypeInitializationException: The type initializer for 'System.ServiceModel.Channels.Msmq' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'mqrt.dll': A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A)
at System.ServiceModel.Channels.UnsafeNativeMethods.MQGetPrivateComputerInformation(String computerName, IntPtr properties)
I have read that this error may come up if msmq is not installed, but msmq is not supposed to be installed on the local machine... it is installed on the remote machine it is trying to talk to.
What else can cause this?
Any machine wishing to participate in the transmission of messages requires MSMQ to be installed.
This is because MSMQ uses a messaging pattern called Store and forward, which is what makes MSMQ robust to transmission failures.
Go to Programs and Features and then Turn Windows Feature on or off. Find Microsoft Message Queue (MSMQ) Server and enable it.
credit to: https://stackoverflow.com/a/26705197/782856
My application has 50 service endpoints (such as /mysite/myService.svc). It's hosted in IIS. Intermittently (once every two or three days) a service stops responding. It's never the same service that hangs. While a service is hung, some of the other services work fine and some other are also hung.
All clients (from different computers) get this error:
ServiceModel.CommunicationException
Message: An error occurred while receiving the HTTP response to
https://server/mysite/myservice1.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 service shutting down).
See server logs for more details.
No exceptions are raised by the server when the client attempts to call the service that is hung. All I have is that error on the client side.
I have to manually recycle the application pool to fix the problem.
Do you know what could be the cause? How can I investigate this issue? I'm willing to take a memory dump of the worker process when a service is hung but I would not know what to search for in the dump.
Update (Aug 13 2009): I have almost ruled out the idea that the server runs out of connections (see comment in Shiraz Bhaiji's answer). I might have a new lead: I log all server-side exceptions in a log file. So in theory, when this occurs on the client, no exceptions are raised on the server; otherwise I'd have proof of that in my logs. But what if an error does occur on the server but is happening at a low level where exceptions are not routed to my exception handling code? I have posted this question about scenarios where low level exceptions cannot be handled. I'll keep you informed of the progress of my investigation.
Sounds like you are running out of connections.
By default WCF has a timeout and therefore holds a connection open for 10 mins.
When you recycle the app pool all connections are closed, and therefore things work again.
To fix it check your code to make sure that you close connections / dispose of proxies.
To resolve this, we set establishSecurityContext to False on the binding.
I have not come across this particular issue but would suggest to turn on tracing/message logging for the WCF service in the config for the service and/or the client app (if you have control over that). I've done this in the last few days for a service that I needed to troubleshoot.
The MSDN link here is a good starting point.
Also see the table in this post for the varying levels of trace detail you can configure. There are several levels which can go from exception only logging to full message details. It is quite quick to set this up in the app.config file.
To parse the log file output use the SvcTraceViewer.exe that comes with the Windows SDK, which if you have it installed should be located in this folder: C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin
Our WCF services occaisionally spawn a worker thread to handle something that the client doesn't care about. The worker threads do not report any status back to the client. In fact, the service has probably already returned results to the client by the time the thread finishes.
One of these background threads recently caused an exception. The exception went unhandled, so IIS crashed.
I can fix this particular exception, but in the future, someone may add some code that causes another unexpected exception. I want to prevent this from crashing IIS in the future.
I know System.Windows.Forms apps can handle thread exceptions by implementing Application.ThreadException. Is there something similar I can do from a WCF service? Or if Application.ThreadException is the way to go, how would I hook it up from a WCF service?
The MSDN documentation for AppDomain.UnhandledException says it does not prevent crashing. Docs for ServiceModel.AsynchronousThreadExceptionHandler suggest it is only for WCF threads.
At a minimum, I'd like to grab a stack trace from the exception before crashing, but avoid future crashes completely would be ideal.
Again, let me stress this is not an exception I want to return as a WCF fault to a client.
Since you don't know what caused the exception, the only sensible thing to do is crash. You have no idea what state the service is in, and you could make things worse by continuing.
Remember that IIS will restart the service for you, clean, and presumably working.
If you're spawning threads, you should always make sure they have exception guards. The AppDomain handling for unhandled exceptions only provides a way to log and trace the error, but it won't stop the host from crashing.
You could take a look at implementing IErrorHandler with a Dispatch Behavior:
http://msdn.microsoft.com/en-us/library/system.servicemodel.dispatcher.ierrorhandler.aspx