This is something I just hit at work again. IIS comes with a default web site, and application pools. It's ok to use for web sites that don't have any code, but if you going to be putting a ASP.NET or MVC (or purchased) applications on the server, don't use them.
Microsoft Updates, even just security ones, can at times change the bindings, and can reconfigure any of the default sites and app pools, on a rare occasion they might even alter the web.config files or steal bindings from other web sites on same server. It can even start the default sites if they are stopped. Simply renaming them doesn't fix updates plugging things into them.
It is best to stop the default site and app pools (don't delete them), and leave those in a stopped state. Then also point the default app site to a path with a single web page that lets you know when it gets activated by accident during an update.
Then install your .NET or MVC application to a new web site in IIS, and new application pool.
This is also more secure, as a hacker usually targets the default web site and app pools as those use known or easily generated identities on the server.
Another one I hit recently. If you are invoking web services, MVC API services or JSON/BSON services from another server there is a 2 connection limit from any .net application (or app pool) to another web server. If it's a moderate to high traffic site this can cause a bottle neck.
The solution is the maxConnection setting in the app or the web config file.