I have a website in IIS 6 (on Windows 2003 Server) that has an application pool that keeps crashing because of too many unhandled exceptions being thrown by some processes. These exceptions are related to a windows service that executes every five minutes. Every time the service runs i get the below warning in the system log (in event viewer):
A process serving application pool
'AppPool1' suffered a fatal
communication error with the World
Wide Web Publishing Service. The
process id was '4172'. The data field
contains the error number.
(to note: I also get two errors in the application log, one which displays the stack trace and the second which displays the EventType)
I am trying to recreate this exact scenario in another website (on the same server) so that I can attempt to catch the exception in a development environment and then apply the working code to the live environment. I have created a second service, a second application pool, etc. My problem is that I cannot cause the same warning above for the second application pool (i.e. AppPool2). I have the theory that my second service is somehow connected to my first application pool (AppPool1) but have been unable to prove or confirm this.
My question is, am I right? Is there some sort of "connection/relationship" between the windows service and the application pool (i.e. can i configure a service to access a certain application pool)? If so, how would I configure this? If not, then I am wondering if is it possible that a process from my second service is accessing my first application pool?
Thanks.
Application pools are isolated processes. Your Windows Service process should not affect an application pool process unless it shares a vital resource to that process(like a file...etc), thus causes it to crash.
It sounds like your Windows Service is calling a Web Service in your application or maybe the same resource on the server as your application?
Related
I've been researching for days and I've gotten to the point where my WCF service creates an Access object via com/interop. I've ran the OpenCurrentDatabase call for the Access object without an error but Application.CurrentDB is still nothing/null. If the CurrentDB is nothing then I surely can't call Application.Run "myFunction" I realize WCF services aren't meant to be user interactive, but it's a long story why I'm trying to go this route. Basically I need to have a proof of concept ready sooner rather than later and the alternative (correct) route involves the complete re-writing of a large complex access VBA application. It's not a permissions issue, I have the IIS user names added to the security tab. What I really need is a way to set Environment.UserInteractive to true so my WCF service can create an instance of Access on my server machine, run the VBA functions, close out, return true. I'm using VS 2010 for the WCF, IIS 7 for my server, Access 2010 for the VBA application. Please help!
The answer is to have the WCF service write the access macro name to a database and have a desktop application on the server machine monitor the database. The desktop application loads access, performs the actions, and writes back to the database upon completion. The WCF service monitors the database waiting for an "operation complete" status and returns the result.
I have a wcf service and i want to call a method automatically , immediately after the publishing in IIS. Like an initialization of the WCF service without having to call the method manually or from somewhere else. Where should i place my Initialize method in WCF Service in order to run exactly after the start of the application?
If you're hosting in IIS you can use the application_start event within the Global.asax of the web app that hosting tHE WCF service to do any application initialization. If you are trying to call one of your services when it is first installed then this is likely the wrong approach.
What is the motivation for running some code on start up of the web service? If you are trying to get around a slow initial call to the WCF service I suggest you would want to do some work on the WCF client-side rather than in the service...but Im just guessing at your motivation here
Initialization of the WCF service? So do you have singleton service or do you want to initialize some global state? Otherwise initialization doesn't make sense because service instances will be created for actual clients.
By default IIS starts application when it is accessed first time. If you place initialization in Application_Start (HttpApplication or Global.asax) the code will run when the application is first accessed. But accessing the service is not something that your application can initiate.
IIS 7.5 (Windows 2008 R2) has warm-up module which can run some code when pool is recycled or worker is restarted. If you use other version of IIS you have to use some external solution like custom application pinging your service in regular intervals.
When IIS restarts an ASP.Net (2.0) web application, it can either:
Recycle the AppDomain: Unload the AppDomain and load a new AppDomain on the same process (e.g. when HttpRuntime.UnloadAppDomain() is called, when web.config is changed).
Recycle the process: unload the AppDomain and load a new one on a new process (e.g. when invoking Recycle command on an AppPool via inetmgr, or when memory limit is reached).
Due to some internal reasons (trouble with legacy native code we depend upon), we cannot allow the first option. We just can't load the application twice on the same process.
Can IIS be somehow told to never allow worker process reuse?
I've tried preventing it myself by tracking whether an application has already started on a process once using a Mutex, and if so - throwing an exception during Application_Start()); I've also tried terminating the process by calling Environment.Exit() during Application_End(). The problem with both methods is that it causes any requests that arrive during Application_End or Application_Start to fail (unlike a manual process recycle, which fails absolutely no requests because they are redirected to the new process right away).
I believe that "Recycle the AppDomain" comes under preview of ASP.NET runtime and IIS is not really involved anywhere (I am not 100% sure about this in case of integrated pipeline of IIS7). So I don't think that what you want is feasible. But there are couple of workaround that you may consider for your problem:
Ensure that you run start-up code (manipulating legacy code) to run only once - this should be possible via named system semaphores. Once system semaphore is created by app start-up in worker process, it will exists till process is recycled so you can have per process initialization.
If #1 is not possible then consider hosting code manipulating legacy code in a separate process all together - this process can expose relevant functionality via WCF services over named pipes. ASP.NET will consume them to use legacy code.
Couldn't find a way to tell IIS that worker processes are not to be reused. Can't afford fixing the underlying problem that forbids process reuse. Therefore, ended up calling Environment.Exit(0) in Application_End, although it may cause a small number of requests to fail with a connection reset.
I'm trying to start a Windows service on Windows Server 2003
from an ASP.NET page:
the code of line 35 is:
32. Dim controller As New ServiceController
33. controller.MachineName = System.Environment.MachineName
34. controller.ServiceName = "WindowsServiceRealName"
35. controller.Start()
The error code is
System.InvalidOperationException: Cannot open WindowsServiceRealName service on computer 'DARWIN'. ---> System.ComponentModel.Win32Exception: Access is denied --- End of inner exception stack trace --- at System.ServiceProcess.ServiceController.GetServiceHandle(Int32 desiredAccess) at System.ServiceProcess.ServiceController.Start(String[] args) at System.ServiceProcess.ServiceController.Start() at AfconParking.Import.StartService() in E:\ProjectsNet\AfconParking\AfconParking\system\Import.aspx.vb:line 35
The account used for the identity of your ASP.NET application pool ("Network Service" by default) does not have the permissions required to start a service.
To fix this issue, you have a few options:
Re-architect your site to not require interactions between ASP.NET pages and the service control manager. I really can't think of a good reason to require this (the service can simply be started at boot time, and remain running: if the service crashes, you should fix the cause of that, and/or use the corrective actions provided by the SCM. If a service restart is needed to kick of some kind of processing, use an IPC mechanism, such as sockets or named pipes, to communicate between your web app and the service instead).
Create a service account with the appropriate permissions (basically, membership of the local Administrators group) as described in detail here. Do note that this has several security implications, none of them particularly good.
Its a permissions issue, try to run the application pool with an Identity that has permissions to perform service control operations.
Read this kb to find out how to grant user such a permissions:
http://support.microsoft.com/kb/325349
Services have Access Control Lists (like files etc.). By default most normal and restricted user accounts (including the default account used by ASP.NET workers) do not have permissions to control or see the status any services.
You can either set an ACL on the service that allows the IIS worker to control the service, or run the web application with an account that already has rights.
The latter option would probably give the web application a dangerous level of access (e.g. what would happen if a web user found a security vulnerability), but is a quick approach to confirming that it is a service access permission.
Setting an ACL is the better solution, but I don't think there is a UI to set the ACL (except in group policy) which makes things harder. You'll need to use the command line tools (e.g. SUBINACL.exe)
Duplicate
This is a close duplicate of Dealing with a longer running process in WCF. Please considering posting your answer to that one instead of this.
Original Question
I'm implementing the business layer of an application that must run some background processes at scheduled times. The business layer is made up of several WCF services all running under the same web application.
The idea is defining a set of 'tasks' that must be run at different times (eg. every 5 minutes, everyday at 23:00, etc). That wouldn't be hard to implement as a windows service, but the problem is, the tasks need access to data caches that are living in the services, so this 'scheduler' must run under the IIS context in order to access that data.
What I'm doing currently is using a custom ServiceHostFactory in one of the WCF services which spawns a child thread and returns. The child thread sleeps and wakes up every X minutes to see if there are scheduled tasks and executes them.
But I'm worried about IIS randomly killing my thread when it recycles the application pool or after some inactive time (eg. no activity on any of the WCF services, which listen for requests from the presentation layer). The thread must run uninterrupted regardless of activity on the services. Is this really possible?
I have found an article by someone doing the same thing, but his solution seems to be pinging the server from the child thread itself regularly. Hopefully there is a better solution.
I have at some point implemented a Windows Service that would load a web page on a regular basis. The purpose of that was was that the site was hosting a Workflow Foundation runtime, and we wanted to ensure that the web application was brought back up after IIS recycling the application pool. Perhaps the same approach can be used in this case; have a service (or Scheduled Task in Windows; even simpler) run every x minutes and load a page that will check for tasks.
Is it a possibility to run either a Windows Service or place applications in the Windows Scheduler to execute methods in the WCF at certain times? Maybe use a BackgroundWorker inside the WCF. Another option would be for WCF to spawn other applications to do the business logic, passing the appropriate data, or pointers to the data in memory(unsafe).