Help: ASP.Net broken (tried usual suspects...)

[Mike]

Of course, I have a delivery today...

All of a sudden ASP.Net is no longer operating properly:

- Serving of non-ASP.Net pages works fine
- Trying to use ASP.Net (acessing page from browser, or new/load VS 2003 web
project) results in
- "normal-sounding" pre-load of .Net and my DLL. (Yes, I mean the sound
of the disk - I know that's scary...)
- followed by a System Error beep (with no dialog presented)
- at which point the accesing program will hang forever
- or until I stop/restart IIS

Also:
- No log entry is generated for the asp.net page access
- The CPU is spinning 100% in inetinfo.exe

I've tried:
- Uninstalling/re-installing IIS
- Re-installing the .Net 1.1 redist
- re-running aspnet_regiis -i

Any help ASAP would be appreciated!!

thanks,
m

 

[Jim Cheshire]

All of a sudden ASP.Net is no longer operating properly:

- Serving of non-ASP.Net pages works fine
- Trying to use ASP.Net (acessing page from browser, or new/load VS
2003 web project) results in
- "normal-sounding" pre-load of .Net and my DLL. (Yes, I mean the
sound of the disk - I know that's scary...)
- followed by a System Error beep (with no dialog presented)
- at which point the accesing program will hang forever
- or until I stop/restart IIS

Also:
- No log entry is generated for the asp.net page access
- The CPU is spinning 100% in inetinfo.exe

I've tried:
- Uninstalling/re-installing IIS
- Re-installing the .Net 1.1 redist
- re-running aspnet_regiis -i

If you're seeing CPU spinning up in inetinfo, that doesn't sound like
ASP.NET's broken. The way to troubleshoot that is to gather perfmon data and
a user-mode dump of the inetinfo process to see what threads are spinning
the CPU.

I'm not sure what the public symbols will show for an inetinfo dump, but you
could try it.

--
Jim Cheshire
================================
Blog: http://blogs.msdn.com/jamesche

Latest entry:
Getting the PID and TID of a COM Call

Describes how to get the PID of the
dllhost process a COM call is executing
in and how to locate the thread as well.

 

[Mike]

....
If you're seeing CPU spinning up in inetinfo, that doesn't sound like
ASP.NET's broken.

The rest of IIS seems to be working fine - serving up static pages like a
champ.

The way to troubleshoot that is to gather perfmon data and a user-mode
dump of the inetinfo process to see what threads are spinning the CPU. I'm
not sure what the public symbols will show for an inetinfo dump, but you
could try it.

Sounds like fun , but I just want to get back to work...

I tried again from a fresh boot, and I still see all the same behavior,
except no CPU spin in inetinfo -
that may be been due to a bad state when IISadmin failed to stop things (it
hung too) and I had to get nasty.
BTW, killing aspnet_wp doesn't free the calling app (the browser still shows
"loading"), but killing innetinfo does free things.
(Both of course are quickly replaced when terminated.)
I don't understand why neither IE nor VS ever time out either - they'll stay
hung forever, despite any timeout settings.

Any other ideas?

thanks,
m

 

[Guest]

Mike,
Killing the InetInfo process is a bit heavy-handed. All you need to do is
type
IISRESET from a command prompt.

Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com

 

[Jim Cheshire]

The rest of IIS seems to be working fine - serving up static pages
like a champ.

Doesn't matter. If inetinfo.exe is consuming CPU, the problem is there and
not in the worker process.

Sounds like fun , but I just want to get back to work...

It is fun, but that's not the point. If you want to find out why the
process is doing this, that's how you do it. You might be able to continue
to guess at what might be causing it, and you might even get lucky enough to
track it down. However, if you want to really troubleshoot it, debugging it
is the key.

Any other ideas?

Not really. There's only one way to correctly troubleshoot an issue like
this. What you can do is open a support incident with us and someone can
walk you through creating a user-mode dump. They can then get that to my
team for some analysis. That would be my recommendation.

--
Jim Cheshire
================================
Blog: http://blogs.msdn.com/jamesche

Latest entry:
Getting the PID and TID of a COM Call

Describes how to get the PID of the
dllhost process a COM call is executing
in and how to locate the thread as well.

 

[Mike]

Mike,
Killing the InetInfo process is a bit heavy-handed. All you need to do is
type
IISRESET from a command prompt.

Sure - it's when that hung (and from the services applet as well) that I
started to take things into my own hands.

thanks,
m

 

[Mike]

Doesn't matter. If inetinfo.exe is consuming CPU, the problem is there and
not in the worker process.

As I said in the followup, I'm seeing the same hangingn behavoir without the
spinning in inetinfo as well.
(AlsoIt happened again -- seems random.)

It is fun, but that's not the point. If you want to find out why the
process is doing this, that's how you do it. You might be able to continue
to guess at what might be causing it, and you might even get lucky enough
to track it down. However, if you want to really troubleshoot it,
debugging it is the key.
... There's only one way to correctly troubleshoot an issue like this.
What you can do is open a support incident with us and someone can walk
you through creating a user-mode dump. They can then get that to my team
for some analysis. That would be my recommendation.

I'll try if I can -- I may just need to call it DOA for now and scramble to
another machine. (Although moving from this laptop another machine would be
a PITA, work-wise.) I'm only a mile or two from MS (ex-msft) -- can't I just
give your team my machine and have them lay hands on it?
(Off-campus lunch anywhere + beer on me )

I'd love to know what causing the System.Error beep when things go awry -
something's trying to tell me something...

thanks,
m

 

[Mike]

FYI, if anyone ever comes across this -- it looks like the problem may have
been caused my the installation of Sprint PC-5740 EDVO modem card software.
Uninstalling this seems to have done the trick - though I have no idea what
the interaction was. (It was not necessary for the card to be pluged in for
the problem to occur, which would be more understandable somehow.)
I got things working, then re-installed the software, and started seeing the
problem again -- although I'm not 100% sure, I can't spend the time trying
to completely isolate the issue.

thanks,
mike