views:

60

answers:

1

I have an ASP.NET repository site running on IIS6.0 and I have an issue that I can't reproduce, but three of the users have this problem every time (~20 other users run just fine). I'm pretty sure it has something to do with the IIS Authentication setup, but I certainly haven't ruled out a coding mistake.

The users tell me that the common factor between the 3 that get the error is that they have uploaded over 60 documents onto the site. All the users are in a different province so I only have screenshots they've taken and server event logs to debug by.

When attempting to go to the ViewPage.aspx page (but not any other page on the site) they are prompted for their user credentials. When they try to log on, they receive the logon prompt again. After they try to log on three times, they receive the following error message:

HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials.

The System Event Viewer has the following warnings (more than 10 of either one of them):

EventID:1011
Source: W3SVC
Description:
A process serving application pool 'SDAAppPool' suffered a fatal communication error with the World Wide Web Publishing Service. The process id was '3264'. The data field contains the error number.

and

EventID:1009
Source: W3SVC
Description:
A process serving application pool 'SDAAppPool' terminated unexpectedly. The process id was '2088'. The process exit code was '0x800703e9'.

The Security Event Viewer has several of the following Failure Audit:

EventID: 560
Source: Security
Category: Object Access
Description:
Object Open:
Object Server: SC Manager
Object Type: SERVICE OBJECT
Object Name: WinHttpAutoProxySvc
Handle ID: -
Operation ID: {0,557880730}
Process ID: 444
Image File Name: C:\WINDOWS\system32\services.exe
Primary User Name: EBTOPVNET01$
Primary Domain: EBSS
Primary Logon ID: (0x0,0x3E7)
Client User Name: NETWORK SERVICE
Client Domain: NT AUTHORITY
Client Logon ID: (0x0,0x3E4)
Accesses: Query status of service
Start the service
Query information from service
Privileges: -
Restricted Sid Count: 0
Access Mask: 0x94

The Application Event Viewer has the following Errors:

EventID: 5000
Source: .NET Runtime 2.0 Error
User: N/A
Description:
EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.3959, P3 45d691cc, P4 system.data, P5 2.0.0.0, P6 4889ece0, P7 1849, P8 0, P9 system.stackoverflowexception, P10 NIL.

My web.config has the following authentication/authorization code:

<authentication mode="Windows"/>
<authorization>
    <deny users="?"/>
</authorization>

and I use the following user check on the ViewPage.aspx page:

UsersService us = new UsersService();
TList<Users> currUser = us.Find("Ntid = '" + User.Identity.Name + "'");
int userID = 0;
if (currUser.Count != 0 )
{
    userID = currUser[0];
}

and use that userID for checking access and such. If the userID == 0 they get read access only (which I would think would give the users read access instead of 401 errors if User.Identity.Name returned empty). I do the same user check on another page and the users have no problems accessing it.

Based on my few days of googling the various sub-issues I'm not sure if all these facts are relevant, but I've included everything I could think of. If there is anything relevant that I missed let me know. Any ideas on where to start investigating or a way to be able to reproduce this on my localhost so I can debug would be greatly appreciated. Thanks.

+1  A: 

From the process exit code it looks like some kind of recursion is taking place and never unwinding. There's a great article by the amazing Tess Ferrandez that explains how to debug such an issue:

A .NET Crash: How not to write a global exception handler

Kev
I'm investigating the recursive methods I have to see if there's anything there. But wouldn't that give me an ASP.NET server error instead of a 401.1
Richard
@Richard - it's possible that's a side effect of the worker process crashing. I'd definitely get the crash problem fixed first, that's pretty serious and will affect all users of the site. You should also find out what browsers are being used, what their cookie settings are etc. The forms auth ticket cookie may be handled differently by these users. But I'm stabbing in the dark there. As I said, fix the worker process crash first and take it from there.
Kev
Well it seems that there is a loop that was adding every non-approved uploaded document the users have access to to a string. The loop is not infinite, but if a user had enough documents in this state it seems that the string gets big enough to overflow the stack. Once we approve these documents the string doesn't get big enough to overflow the stack and the 401.1 error does not occur again. So basically I was wasting time looking into that error (and changing ISS permissions and such). Thanks for pointing me in the right direction.
Richard
@richard - excellent. If you thought this helped could you mark this as the correct answer and/or upvote as well? Thanks.
Kev