TIP: Quick tip on how to Debug ASP.NET Web Application Deployed in IIS
Heres a real quick tip (+ info) on how to debug a ASP.NET Web Application/Site when running inside IIS itself. After the launch of Whidbey (Visual Studio 2005) we didn’t really need to have Internet Information Services (IIS) installed thanks partly to the bundled hosting engine (based on Cassini). But sometimes – just sometimes� 🙄 – when you deploy your ASP.NET web apps to IIS you’ll find things break – like we just experienced – unlike running via the internal web-server.
To debug an already running IIS process – with the project loaded.
- Debug > Attach to Process
- Select either
aspnet_wp.exeorw3wp.exe. (see note below) - Enter a break-point somewhere in your code
- Visit the page/refresh.
Sometimes you may need to untick “Enable Just My Code (Managed Only)” in the Options > Debugging list.
Why the aspnet_wp.exe and w3wp.exe difference?
If the IIS server is running under IIS 5.0 Isolation Mode, then you need to attach to the ASP.NET Worker Process (aspnet_wp.exe) where as if your running under the Worker Process Isolation Mode (which is the default in IIS 6.0) you will need to attach to the w3wp.exe process.
From the TechNet Documentation:
Worker process isolation mode delivers all the benefits of IIS 6.0 new architecture: robust application pooling; automated restarts, scalability, debugging; and finely-tuned performance tuning. Web applications run with the Network Service identity, which provides a security advantage: the Network Service account has lower access privileges than LocalSystem.
In version 5.x of IIS the ASP.NET ISAPI Filter (aspnet_isapi) which is an unmanaged piece of code that runs within the inetinfo.exe process that offloads the work to the ASP.NET Worker Process (aspnet_wp) that trickles the workload down the rabbit hole.
However in IIS 6.x the process is a little different, specifically we have a kernel mode HTTP driver (http.sys) which ships apart of the Windows Networking subsystem. This acts as the gateway for the incoming requests for the web-server. It first parses the request and dispatches it to the IIS 6.0 Worker Process (w3wp.exe) which then loads the ASP.NET ISAPI (aspnet_isapi) and follows on down the rabbit hole.
Read the TechNet articles on more information about the HTTP Protocol Stack in IIS 6.0.
Just how far down does the rabbit hole go?
If your interested in learning more about the internals of the ASP.NET Worker Process and inparticular how ASP.NET works ‘under the hood’ you’re best to look at Rick Strahl‘s *excellent* article – A Low-Level look at teh ASP.NET Architecture which just got updated late last month (24th)!