Home/ Questions/Q 7042237
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T02:08:38+00:00

We’ve implemented a background service in our Asp.Net web app that receives messages from

  • 0

We’ve implemented a “background service” in our Asp.Net web app that receives messages from MSMQ at random intervals without requiring an HTTP request to start up the application. We auto start this web app using a serviceAutoStartProvider.

Everyhing works when IIS initially starts up, the server is rebooted and so on, we receive messages just fine. BUT if we just stop the site in IIS (not touching the application or app pool), the application stops receiving MSMQ messages. And when we start the web site again, the serviceAutoStartProvider is not called again, so our app does not start listening to MSMQ messages again!

If we issue a HTTP request against the web app after the IIS site has been stopped and started again, it starts listening to MSMQ messages again.

  1. Shouldn’t our “background service” web app continue to listen to MSMQ messages even if the IIS site is stopped? It won’t get any requests, but I think it should continue to run.

  2. What exactly happens in an Asp.Net application/app pool when the IIS site is stopped? Any events fired that we can hook up to? The app pool claims to be “started” in IIS manager, but code is not running in it.

  3. Why isn’t our serviceAutoStartProvider called when the site is started again? I believe it is “by design”, since the application isn’t really stopped. But the applications isn’t running, either, has to be waken up by an actual HTTP request.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    When the IIS Web App shuts down (eg. due to no new HTTP(S) requests for the timeout time) the .NET app domain (within the app pool worker process) completely closes and unloads. This includes all background threads, including those used by the .NET thread pool.

    A Web App can be configured with a longer (or no) timeout, then background worker threads could continue to process work.

    But better would be to either run such workers in a specialist service process managed completely separately.

    Or, even better, use IIS application hosting with WCF to create the MSMQ listener. I understand in this case the integration of Windows Process Activation Services with IIS would restart the Web App if a new message arrived after it had been shutdown.

    • 0