By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,771 Members | 1,698 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,771 IT Pros & Developers. It's quick & easy.

aspnet_wp in 100% lockup (framework 1.1, not 1.0)

P: n/a
Hi guys,

I'm getting a bit of a wierd one with my ASP.NET application. I'm
running under framework 1.1, which is a shame, because the following KB
articles looked interesting initially:

KB810280, and,
KB321792

Essentially, the app is running along reasonably happily, and then
suddenly a request comes in which locks up 1 of the processors (well,
one of the HT logical processors). Other requests start having some
problems after this (although some are still serviced fine).

Interestingly, when the problem initially starts, there is only one
"current request" according to the performance counters, and I'm not
mad enough to use my own threads in the application, so that would seem
to rule out a deadlock?

In the past, I'd have looked at accidentally left over mutex stuff
around the database access, but you cant really leave anything behind
when you use Synclock, can you? Also, if it was an "outstanding lock",
I'd expect processor to be 0, not 50%. I don't use any explicit
transactions (and have also checked that there are no outstanding
transactions using perf counters), and checking sp_who2 on the backend
database doesn't show any blocking (and again, I'd expect 0% processor
for aspnet_wp)

So, can anyone point me at where I'm going wrong, where I should look
next? The only way to resolve the problem is to kill aspnet_wp, which
is a bit of a shame for the people who are managing to carry on without
problem.

The application is quite spread out, it consists of six different VB
projects (one normal VB.NET DLL, plus five VB.NET ASP.NET projects),
makes moderate use of in-memory session, and is using cookie-less
sessions.

It mainly seems to affect one page, I've checked through the PageLoad
and PreRender for any obvious "possible" infinite loops, without
success. The page is reachable through two different routes (either
passing params in a query string or stuffing them into the session and
doing a redirect) and both routes seem to be equally affected. The
values of these parameters is not correlated with this problem.

Nov 19 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Damien wrote:
Hi guys,

I'm getting a bit of a wierd one with my ASP.NET application. I'm
running under framework 1.1, which is a shame, because the following KB articles looked interesting initially:

KB810280, and,
KB321792

Essentially, the app is running along reasonably happily, and then
suddenly a request comes in which locks up 1 of the processors (well,
one of the HT logical processors). Other requests start having some
problems after this (although some are still serviced fine).

Interestingly, when the problem initially starts, there is only one
"current request" according to the performance counters, and I'm not
mad enough to use my own threads in the application, so that would seem to rule out a deadlock?

In the past, I'd have looked at accidentally left over mutex stuff
around the database access, but you cant really leave anything behind
when you use Synclock, can you? Also, if it was an "outstanding lock", I'd expect processor to be 0, not 50%. I don't use any explicit
transactions (and have also checked that there are no outstanding
transactions using perf counters), and checking sp_who2 on the backend database doesn't show any blocking (and again, I'd expect 0% processor for aspnet_wp)

So, can anyone point me at where I'm going wrong, where I should look
next? The only way to resolve the problem is to kill aspnet_wp, which
is a bit of a shame for the people who are managing to carry on without problem.

The application is quite spread out, it consists of six different VB
projects (one normal VB.NET DLL, plus five VB.NET ASP.NET projects),
makes moderate use of in-memory session, and is using cookie-less
sessions.

It mainly seems to affect one page, I've checked through the PageLoad
and PreRender for any obvious "possible" infinite loops, without
success. The page is reachable through two different routes (either
passing params in a query string or stuffing them into the session and doing a redirect) and both routes seem to be equally affected. The
values of these parameters is not correlated with this problem.


I've found the problem now - my "possible" infinite loop in the
Page_Load, was, in fact, infinite.

While dtPaymentDue < .objCreditorServices_Client.StartDate
dtPaymentDue.AddMonths(1)
End While

I'd looked at that, thought "Is there some possibly fantastic value for
the StartDate which would cause it to loop?" and decided no.

What I should have looked at is the statement in the loop. I forgot
that with the simple types, the function calls you make on them do not
affect the value of the underlying variable. Fixed code:

While dtPaymentDue < .objCreditorServices_Client.StartDate
dtPaymentDue = dtPaymentDue.AddMonths(1)
End While

Doh. Cue me feeling rather sheepish, but glad I got to the bottom of
it. Admittedly, I only found it after adding a trace line after every
code line, and producing a massive logfile.

Nov 19 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.