RE: aspnet_wp process stops after each request

Tech-Archive recommends: Fix windows errors by optimizing your registry

theyas_at_community.nospam
Date: 01/03/05 

Date: Mon, 3 Jan 2005 00:57:02 -0800

Aha!! I found the answer elsewhere! Kudos to Everett Munis (and whoever at
MS helped him out)!!

Go to "Properties" on the "Default Web Site" (In IIS management console) and
select "Home Directory" tab. Click the "Configuration" button. Under the
"Mappings" tab, make sure the "Cache ISAPI applications" is checked.

Here's the post that solved it for me, over in the dotnet.framework.aspnet
group. The first post appeared 11/30/2004 10:14 AM PST and was titled
"Problems with aspnet_wp.exe". The third reply (by the original poster)
recounted all (OK, well, some) of the gory details of the fix.

Dunno if this link will work, if not follow the directions above to get to it.

http://msdn.microsoft.com/newsgroups/default.aspx?pg=77&lang=en&cr=US&guid=&sloc=en-us&dg=microsoft.public.dotnet.framework.aspnet&fltr=

Lowell

"JP.Sklenka" wrote:

> There are a couple of possibilities here. For starters make sure that you
> can see the aspnet_wp.exe in the Tools -> Debug Processes screen once the
> aspnet_wp.exe has fired up.
>
> If you do not see it in the list check the Show System Processes and show
> processes in all sessions checkboxes. I have also run into scenarios where
> the CLR debugger is unselected and subsequently won't break on breakpoints
> set in .net code.
>
> To check this select the aspnet_wp.exe and click attach. In the subsequent
> dialog box, ensure that Common language Runtime is checked. I have found
> that sometimes when you are prompted to debug script this will magically
> uncheck the Common Langage Runtime checkbox leaving subsequent debugging of
> the CLR unsuccessful until you wire it up again as described above.
>
> Another thing to check if you suspect the aspnet_wp.exe has a high rate of
> turnover is any anti virus software scans that may be occuring on the .net
> Framework directories. Anytime certain files within those directories are
> modified the aspnet_wp recycles which leads to the problem you're seeing as
> well as loss of session data. http://support.microsoft.com/kb/821438/EN-US/
>
> JP
>
> "theyas@community.nospam" wrote:
>
> > Windows XP SP2, VS 2003, IIS 5.1, IE 6.0, Symantec AV 9.0.0.xxx
> >
> > I've been changing things around (and have re-installed IIS and VS 2003) and
> > am now at the point where I have things working--except that I cannot debug
> > IIS Server processes of ASP.NET anymore. When, in VS 2003, I select "Debug"
> > and then "Processes...." I get the list that appears to be the same as
> > before, except that I don't see the "aspnet_wp" process. Also, when my
> > application throws an exception and I get the dialog box for debugging, it
> > will attach to an ASP script, but not delve into the .NET code that is called
> > by the ASP script.
> >
> > And I've also brought up a data service page which before would always start
> > up the aspnet_wp process if I had just restarted IIS. It sure seems to me
> > like there's just some little setting somewhere that's missing.
> >
> > I've narrowed this down a bit. When I start up the Windows Task Manager and
> > then watch it while I navigate IE to an ASP.NET page on the local system, I
> > can see the "aspnet_wp.exe" process appear during the time it takes to
> > generate the page. Once the page is generated, the "aspnet_wp.exe" process
> > goes away.
> >
> > So apparently, something isn't configured properly anymore in IIS?
> >
> > I found that the "Enable ASP server-side debugging" box was not checked in
> > IIS configuration, the web site properties, "Home Directory" tab,
> > "Configuration", "Debugging" tab. I checked it, restarted IIS and still no
> > go.
> >
> > Any and all ideas welcome!
> >
> > Thanks!
> >
> > Lowell

Quantcast