I’ve been trying to migrate a fairly large web application from IIS6 to IIS7 the past few days, but every time it seems like we’re about done, IIS7 fails to load aspx pages.
The application is a .net 3.5 webapp that makes heavy use of reflection and web services. We use 2 main components (each with their own web site in IIS7 although they share an application pool): the web UI (aspx pages), and the webAPI (asmx pages).
The webAPI portion runs perfectly (as far as we can tell; there are a few things we can’t test from the browser), and the web UI pages load static HTM pages just fine. The problem is that once we attempt to view an aspx page (any aspx page), the whole thing just comes to a halt; no error is logged in the event viewer until a few minutes later when we get an IIS 5010 warning (worker process ignoring ping).
We’ve attempted to migrate the app in two different ways:
- Manually: we moved all the necessary files and set up the virtual directories then converted them to Web Sites. Result: the worker process took up 100% of a single core and spun forever (until terminated manually)
- Automatically: Utilizing the MSDeploy application from http://www.iis.net we archived the entire IIS6 web server and unpacked it into a blank IIS7 install. We had to turn off Forms Auth to get rid of a 401.2 error, but after that the result here was that the webAPI component still works just fine, but instead of the web UI worker process taking up 100% of a single core, it grew to about a third of the required memory then hung out doing nothing.
Either way, what happened from the user’s point of view was the same.
Unfortunately, we can’t even attach a debugger to the worker process because it doesn’t seem to be loading managed code.
Details:
- .net framework: v3.5
- CLR version: v2.0
- IIS Authorization mode: Anonymous
- OS arch: x64
- App arch: x86
- Happens with both classic and integrated pipelines
Notes:
- New web projects seem to work just fine in IIS7 and, of course, xml web services are also fine
- temporary DLLs are created and stored in the temporary ASP.net DLLs folder, even though the worker process never seems to contain managed code.
- New pages added to the web UI project also show the same behavior (Didn’t hurt to try)
Updates:
- We’ve narrowed down the problem to a single assembly. It’s a wrapper for a third party web control. I’m looking into replacing it, we’ll see if it fixes the problem.
http://support.softartisans.com/kbview.aspx?ID=1318
Turns out it was an issue with the vendor control. Wish their solution actually worked though…