Random Crashes caused by a compilation error in the EntityServer.svc

 

WebHost failed to process a request.
 Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/12671853
 Exception: System.ServiceModel.ServiceActivationException: The service '/EntityServer.svc' cannot be activated due to an exception during compilation.  The exception message is: Object reference not set to an instance of an object.. ---> System.NullReferenceException: Object reference not set to an instance of an object.
   at System.Web.Compilation.DiskBuildResultCache.CacheBuildResult(String cacheKey, BuildResult result, Int64 hashCode, DateTime utcStart)
   at System.Web.Compilation.BuildManager.CacheBuildResultInternal(String cacheKey, BuildResult result, Int64 hashCode, DateTime utcStart)
   at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath)
   at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
   at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate)
   at System.Web.Compilation.BuildManager.GetVPathBuildResult(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean ensureIsUpToDate)
   at System.ServiceModel.ServiceHostingEnvironment.HostingManager.GetCompiledCustomString(String normalizedVirtualPath)
   at System.ServiceModel.ServiceHostingEnvironment.HostingManager.CreateService(String normalizedVirtualPath)
   at System.ServiceModel.ServiceHostingEnvironment.HostingManager.ActivateService(String normalizedVirtualPath)
   at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath)
   --- End of inner exception stack trace ---
   at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath)
   at System.ServiceModel.ServiceHostingEnvironment.EnsureServiceAvailableFast(String relativeVirtualPath)
 Process Name: w3wp
 Process ID: 4832

 

Specs:

 

Devforce version 6.1.2.0

Silverlight 4.

IIS 7.5
Really old version of DAF

 

I havent been able to get very far using google so a little nudging in the right direction would be nice.

 

Thanks,

John

 

 

 

 

Any of the types passed into or out of an RPC method has to be serializable and a "known" type.   Generally DevForce won't find these errors until you call the method, and the communication error you see is usually the result.  I wouldn't expect to see the compilation error you reported in your first post, but the problem with the types should be easier to resolve and could be the root cause, so let's tackle that first.

 

If you know the RPC methods in question, then check all parameters and all return values, and make sure every type is defined on both the client and server.  Here's some info on serialization and known types - http://drc.ideablade.com/xwiki/bin/view/Documentation/knowntypes.  If you find this article inscrutable, just post your RPC signatures and the type definitions here and we can take a look. 

 

If the type definitions all look good then we can look at the multi-threading aspect. 

I'm back. Could you post your RPC methods in question and all the types definitions involved? We have a theory and would like to do some tests.

 

If you're not passing in parameters, and your return type of ResponseObject doesn't contain any additional properties, then our initial theory concerning multi-threading problems with these types doesn't hold up.

 

But I'm now more concerned that there's a thread safety problem within the code in these methods.  These methods are all defined in the same class, which is OK, but you need to be careful accessing any instance and static properties.  Do you share any objects among these methods?  If so, you can't without locking.  Do you hold onto anything across method calls?  If so, don't.  :)

 

At this point it would probably be best if you try to reproduce the problem, since you have all the code.  Set up a parallel coroutine which calls these RPC methods, and put the whole thing in a loop for good measure.  You want to set up a situation where the methods are executing in parallel and the thread safety problem arises.   If this test doesn't show anything we can show you how to set up a console application which will synchronize multiple threads and helps in flushing out multi-threading problems. 

 

If you'd like, we can also take a look at the code in these methods to see if anything stands out as a red flag.

 

 

This means all of the customers who we had from the beginning were having the problem because they still had the registered COM object in the bin. I am guessing that when the process accessed the COM object from the windows service it caused the webservice to freak out and die (in not so technical terms). 

I unregistered it and registered it in an isolated place and it worked. This is also why we were not able to repo in test since we were always testing from a fresh install.

Thanks to all who chipped in and helped try to debug this issue.