IISRESET: the WORST way to restart your IIS website

IISRESET is a well-known tool used to restart your IIS services.

Unfortunately, that is also its biggest problem:

1. It is often used to pick up configuration changes/reset misbehaving IIS websites when it shouldn’t be.
2. It actively hurts the availability of your websites, and the overall stability of your server.

In this post, we’ll explore in detail why this is the case, and how IISRESET impacts your IIS services.

To learn more about the right ways to reset IIS, restart your applications, and recycle your application pools, see our Reset, restart, and recycle IIS guide.

Before we dig into all the ways restarting IIS with IISRESET affects your web server, let’s review why IISRESET is ever used at all.

If you’d rather jump straight into the gruesome details of how resetting IIS hurts your websites, jump forward.

Why is the IIS RESET command used?

Usually, for two types of reasons:

To pick up configuration changes

This harkens back to the days of old, when resetting IIS may have been necessary to pick up changes to registry keys and some IIS configuration.

Under the normal circumstances, all IIS services in IIS7.0 and above automatically detect and apply all configuration changes and application content changes. These changes either get handled automatically or result in the restart of the applicable pieces of the system, e.g. the application or the application pool.

Bottom line: It is never necessary to use IISRESET to pick up configuration changes. For complete details on this, see the Make sure IIS has picked up the website, application pool, or configuration changes section in the reset, restart, and recycle IIS guide.

To recover from performance or stability issues

This includes hangs and slow website performance, high CPU in your IIS worker process, memory leaks, and so on.

In reality, there are better ways to handle each of these issues than restarting the application.

Even when a restart is tactically beneficial, resetting IIS is never the right way to do it. Instead, identifying the right application pool and recycling it is (or in some specific cases, killing the IIS worker process). There are massive benefits associated with recycling, including:

• Affecting only the application pool in question.
• Zero downtime restart through overlapped IIS recycle.
• Ability to restart with full warmup, and zero startup delay! See our Maximum IIS application pool availability guide for this.
• No impact to other websites.
• No potential consequences to the web server overall.

For the complete details on this and how , please see reset, restart, and recycle IIS guide.

Now that you know that IISRESET is unnecessary, you may not care that it’s actively harmful. But if you do, let’s dig into that next.

How IISRESET works

The most accurate analogy is ripping the power cord out of your server to close a specific application. Sure, it will work - the application will be closed - but you are likely to cause some data corruption and possibly drop your server on the floor as you do it. At the very least, you are going to wait for the server to boot back up before you can use it again.

A more fun analogy I like more is using a rusty hammer to do, well pretty much anything. IISRESET is an old, rusty hammer that is definitively the wrong tool for any job.

This is roughly what happens when you use IISRESET:

1. It attempts to stop WAS, the the Windows Activation Service (also WPAS/Windows Process Activation Service).
2. This stops all services depending on WAS, including W3SVC.
3. WAS attempts to stop ALL active application pools.
4. This means all incoming requests to each website on your server will begin returning 503 Service Unavailable while WAS is stopping.
5. We are now waiting for all IIS worker processes to stop, i.e. waiting for any active requests to complete. Up to the shutdownTimeLimit, which is 90 seconds by default.
6. If a worker process fails to stop in this time period, it will be terminated.
7. Finally, 90 seconds or so later, WAS stops.
8. IISRESET then attempts to to start WAS and W3SVC again.

That is, unless IISRESET times out waiting for WAS to stop, and forcefully terminates them.

In that case, the command is also likely to fail, and fail to re-start IIS services it stopped, leaving your web server permanently disabled …

At this point, you can probably already see why this is a very, very bad idea.

How IISRESET hurts your web server’s availability

Let’s dig into the very real consequences next.

IISRESET causes downtime for your website(s)

Keep in mind that the first thing that happens is the W3SVC service stops. That means, there is noone listening on the website bindings, and connections getting refused. This happens immediately, and for ALL websites on your server.

We are not even talking a 503 Service Unavailable error message, and any kind of errors in the IIS logs. We are talking “this website does not exist” experience and no trace for any failed requests.

This is a fundamentally worse experience than what is offered by other ways to restart your applications on the server, specifically the IIS application pool recycle. By comparison the overlapped recycle offers a zero downtime restart experience. And this does not even mention the ability to reset your applications with full warmup, no startup delay method we explain in our Maximum application pool availability guide.

You can read all about the benefits of overlapped recycling as your primary method for restarting your IIS websites in the Recycling application pools section of the IIS restart guide.

IISRESET causes LONG downtime for the entire server

The other key point to understand is that, because IISRESET is not targeted at a specific website or application pool, it stops ALL application pools on the system.

This means that the downtime for ALL websites is the longest time that any application pool’s worker processes take to finish their currently executing requests (up to their shutdown time limit).

Because people reset IIS most often when there is a performance issue, e.g. a hang or a CPU overload, the chances of some of those requests taking a very long time to finish are HIGH. As a result, expect the full 90 second delay every time you call iisreset.

During this time, ALL websites remain down.

It can leave your server in a stopped state

Let’s get back to that shutdown timeout.

IISRESET has a default timeout, which is 20 seconds. Not 90 seconds, like the default application pool shutdown time limit.

This means that IISRESET on an active system will time out every time before WAS can stop. Causing it to attempt to terminate WAS forcefully.

Now, here is the kicker.

This can often cause IISRESET to experience a permission error, even when you are running it As Administrator. Here is the error:

Attempting stop...
Stop attempt failed.
Access denied, you must be an administrator of the remote computer to use this command. Either have your account added to the administrator local group of the remote computer or to the domain administrator global group.

As a result, your WAS and W3SVC services are now stopped and your server is permanently down:

Now, say you were using the IISRESET NOFORCE command like Microsoft support suggests. The /NOFORCE command will likely exhaust the timeout and stop (without killing the services), resulting in the same stopped state.

iisreset /stop /timeout:60
taskkill /F /FI "SERVICES eq was"
iisreset /start

Using IISRESET denies you the ability to solve your performance issues

Are you using IISRESET as a bandaid for hangs, high CPU in your IIS worker process, memory leaks, or just generally poor website performance?

Then you are simply perpetuating the problem. These problems are guaranteed to return, and you’ll forever be stuck in a “cause downtime to solve downtime loop”.

Instead, you can use these moments as high value opportunities to diagnose and resolve your performance issues … and judiciously use high precision recycling to clear them when you are ready.

See the When to restart or recycle section in our IIS restart guide for tips on how to solve hangs, slow requests, queueing, 503 Service Unavailable errors, high w3wp CPU usage, and memory leaks.

How to diagnose IIS hangs with LeanSentry

You can use LeanSentry Hang diagnostics to automatically detect and analyze IIS and ASP.NET website hangs:

LeanSentry will then identify the application code causing the hang so you can resolve it quickly:

It denies you the benefits of overlapped recycle and 100% warmup

Seriously. If you are trying to restart a broken or struggling application pool, the recycle method instead grants you a zero downtime, fully warm, and no startup delay restart.

Compared to downtime, no warmup, full startup delay option brought to you by IISRESET.

To see how to restart an application pool with full warmup, go to our Maximum application pool availability guide.

Conclusion

In conclusion:

Don’t use IISRESET. IIS resetting your server is never necessary.

It causes extended downtime to your websites, and can leave your web server in an inoperable state.

Instead, head to our Reset, restart, and recycle IIS guide to learn WHEN and how to properly restart your IIS services, and while you there, check out our guidance on how to configure your website for 100% warm, zero startup delay operation.

You’ll be glad you did.

IISRESET FAQ

Here are the answers to a number of frequently asked questions about IISRESET.

Why is iisreset required?

The correct answer is, it’s not! IISRESET is deprecated in any IIS version after 7.0, and was only included due to backwards compatibility.

In all cases, you should always try to perform an app pool recycle instead. Please see how to correctly reset, restart and recycle IIS websites guide for the best practice recommendations.

What does IISRESET do?

IISRESET restarts all IIS services, shutting down any active IIS worker processes in the process and killing them if they do not stop in time. During the restart, the web server stops listening for incoming requests and causes downtime for all websites on the server. The services stopped include the Windows Process Activation Service (WPAS), The World Wide Web Publishing Service (W3SVC), IISADMIN, and any other services that depend on them.

The IISRESET command is deprecated and should not be used on IIS version 7.0 and above. Instead, you should use application pool recycling to restart the specific application pool that is experiencing problems. Please see how to correctly reset, restart and recycle IIS websites guide for the best practice recommendations.

How do I use IISRESET?

You should not use IISRESET on any version of IIS after 7.0. This is both because IISRESET is unnecessary, and causes extended website downtime. In addition, it introduces a high risk of permanent webserver outage if the command fails to start the IIS services back up.

In all cases, you should always try to perform an application pool recycle instead. Please see how to correctly reset, restart and recycle IIS websites guide for the best practice recommendations.

When should I run IISRESET?

The correct answer is never. It is no longer necessary to perform an IISRESET on IIS 7.0 and above.

In addition, IISRESET causes many undesirable effects on your web server, including prolonged downtime, and risk of IIS becoming permanently down if the command fails to restart the IIS services. Instead, you should always try to recycle the target application pool instead. Please see how to correctly reset, restart and recycle IIS websites guide for the best practice recommendations.

Does IISRESET recycle the application pools?

The correct answer is no. Instead, IISRESET causes the shutdown of all active IIS worker processes, kills them if they do not stop in time. This is majorly different from the overlapped application pool recycle, which starts a new worker process immediately to handle any new requests such that no requests are lost.

IISRESET stops the application pools instead, which causes immediate and prolonged downtime. The downtime is extended because ALL application pools must stop to complete the IISRESET process, instead of just the application pool that is being recycled. Please see how to correctly reset, restart and recycle IIS websites guide for the best practice recommendations.

What is IISRESET stop?

The IISRESET STOP command stops all IIS services. This includes shutting down any active IIS worker processes, and killing them if they do not stop in time. During the stop, the web server stops listening for any incoming requests. After the stop completes, the web server is deactivated until the server restarts or you manually start the World Wide Web Publishing Service (W3SVC).

The IISRESET command should not be used in IIS version 7.0 and above. Instead, if you are looking to stop IIS, you should stop and disable the WAS service, e.g. net stop WAS /yes && sc config WAS start= disabled.

What IIS services are restarted by IISRESET?

IISRESET primarily restarts the Windows Process Activation Service (WPAS/WAS). Here are the additional IIS service names for services that are affected as a result: World Wide Web Publishing Service (W3SVC), IIS Admin service (IISAdmin), FTP Publishing service (FTPSVC), and the Web Management Service (WMSVC).