Application_Start() called twice in IIS7.5 hosted MVC 5 application

Question

After moving all my solutions over to a newly installed machine (which makes me think this is a config issue), I am now having this problem with my MVC 5 web application(s).

When I build my web application (VS 2013), this of course regenerates all the web code and IIS will restart the application on next page load. However now it seems, when I go to my start/login page, the Application_Start() fires as expected, but when the page is submitted, before the HttpPost method is reached, the entire application seems to start again (Application_Start runs again). This second start seems to occur before the first Application_End() is called...but regardless of the sequence I have no idea why this is now an issue.

Checking the application shutdown reason in Application_End() I get the notorious vague (and apparently completely undocumented) "BuildManagerChange"...which MSDN gives some ridiculously vague description of.

Does anybody have idea why this would start after loading my development environment onto a new machine. Both machines are Win7 Pro running IIS7.5, and I believe the IIS config is identical to the old one (though, apparently not??). The source code/web.config/etc has not changed between machines.

The only documentation I could find on this issue was in regards to using IISExpress, however I am using the standard IIS7.5 installed with Win7 pro.

Edit: After removing all custom code from the entire startup of the site, and reverting my LoginController back to it's original simple form (no custom code), this still occurs.

Answer 1

Well, wasting 2 days on this was fun! But, this was resolved. Running procmon showed that hash.web was being accessed by mcshield.exe (McAfee AV). Apparently the live "on access scanner" checks the asp.net cache, and somehow IIS is aware of this and thinks it needs to rebuild the site again. For some reason McAfee does not check it after this first time so it functions normally after a second build/restart. I added a scanner exclusion to the c:\Windows\Microsoft.NET folder, and that seems to have solved the issue. –