«

One of the customer facing websites at the company I work for has been
locking up for awhile. To 'unlock' the server our support group has to
restart the application pool for this application. I have done some research
on the issue and added some additional logging and found that when this
lockup occurs we are receiving a "Server Error 500" when our login page is
calling an asp (legacy using remote scripting) page to check permissions and
setup the user. I also found that when this lockup occurs it does not affect
everyone; some people are still able to log in. I have looked at the users
that generate errors and there is no connection between them. I have also
verified that this happens when using secure and non-secure connections,
appears to happen at random and could be once a day or once a month, and it
continues until the application pool is reset.

This issue has not always happened and prior to it starting there were no
changes (that I'm aware of). Since it began the server has been setup again,
we've tried seperate application pools, and we've even tried a different
server (hardware) in case there was something odd going on with the hardware
itself that might be causing the problem. I've spent a good bit of time
looking at "Error 500" websites and so far I'm not finding anything that has
helped or that has pointed us in the right direction.

The server is a 64bit Windows 2003 R2 server. The website that locks up is
an older web site that runs a mix of classic asp, javascript, and a few .net
2.0 pages. We also use a fairly large amount of remote scripting and the site
is heavily database driven.

So to sum it up: we get "error 500" when our login page uses remote
scripting to call functions from a different file. It doesn't happen to
everyone. When it starts we have to restart the application pool to get it
working properly again. No correlation between the users or connection
(secure or non-secure). Server has been reconfigured and even replaced. The
function being called when we get the error is not always the same.

Sorry for the long post but wanted to try to give some information that
might help provide answers. Any advice or suggestions would be greatly
appreciated. Our goal is to try to isolate the issue to determine what is
causing the error and hopefully find a way to resolve it.

Thanks,
Michael

Michael H. wrote:
>
> So to sum it up: we get "error 500" when our login page uses remote
> scripting to call functions from a different file.

"500 error" covers a lot of territory. You need to discover what the
actual error is:
http://classicasp.aspfaq.com/general...sp-errors.html

--
HTH,
Bob Barrows

"Bob Barrows" wrote:

> Michael H. wrote:
> >
> > So to sum it up: we get "error 500" when our login page uses remote
> > scripting to call functions from a different file.
>
> "500 error" covers a lot of territory. You need to discover what the
> actual error is:
> http://classicasp.aspfaq.com/general...sp-errors.html
>
> --
> HTH,
> Bob Barrows
>
>
> .
>

Thanks for the response Bob. Unfortunately this is not a page that is viewed
by the user. The 500 error occurs when the display page calls a page that is
nothing but asp functions. It's the call to that second page that gets the
error. We have extensive error handling in our application (contractual
obligations) so the customer will never see any type of 'standard' error. I'm
not even sure if removing our error handling would allow the error message to
propagate back to the display. But even if that's the case we can't do it due
to our contracts. If we had some way to force the error we might could do it
off hours but even that would be risky.

To add some more info to this, we had this error yesterday while I was in
the office. While talking with our operations guy (they handle the physical
servers) we started getting the 500 error, then we got this error:
"Microsoft VBScript runtime error '800a01b6'

Object doesn't support this property or
method: 'StartPageProcessing'
"

After about 5 mins all of the errors went away and the web site started
functioning properly. This was without any changes or any restarts of
services.

One last bit of info regarding this is the fact that we actually have two
servers running this same code. One is at our HQ in AL and the other is at
one of our data centers in TX. The site at HQ is the one that errors and the
one in TX runs fine. However, the one in TX is just a back and is only used
by a limited amount of people on a daily basis so the traffic is much less.
Not sure if that has any impact but figured I would mention it.

Michael H. wrote:
> "Bob Barrows" wrote:
>
>> Michael H. wrote:
>>>
>>> So to sum it up: we get "error 500" when our login page uses remote
>>> scripting to call functions from a different file.
>>
>> "500 error" covers a lot of territory. You need to discover what the
>> actual error is:
>> http://classicasp.aspfaq.com/general...sp-errors.html
>>
>> --
>> HTH,
>> Bob Barrows
>>
>>
>> .
>>
>
> Thanks for the response Bob. Unfortunately this is not a page that is
> viewed
> by the user. The 500 error occurs when the display page calls a page
> that is
> nothing but asp functions. It's the call to that second page that
> gets the
> error. We have extensive error handling in our application
> (contractual
> obligations) so the customer will never see any type of 'standard'
> error. I'm
> not even sure if removing our error handling would allow the error
> message to
> propagate back to the display. But even if that's the case we can't
> do it due
> to our contracts. If we had some way to force the error we might
> could do it
> off hours but even that would be risky.
>
> To add some more info to this, we had this error yesterday while I
> was in
> the office. While talking with our operations guy (they handle the
> physical
> servers) we started getting the 500 error, then we got this error:
> "Microsoft VBScript runtime error '800a01b6'
>
> Object doesn't support this property or
> method: 'StartPageProcessing'
> "


Well, I'm not sure what you expect from us.
Do your contractual obligations forbid any kind of error-logging? That is
what I will typically do when I don't propogate errors back to the client.
Runtime errors are impossible to debug if you simply discard them when they
happen.

--
Microsoft MVP - ASP/ASP.NET - 2004-2007
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"