Intermittent error with XmlDocument on ASP.NET app. Related to IIS and DefaultAppPool

Hi,

I have a very bizarre intermittent problem that occurs with some
ASP.NET 1.1 (C#) code I inherited. I'll try to state the problem
sucintly; if more detail is needed please ask! The code is in a
WebApplication. The web application is configured in IIS 6.0 to run
under Application Pools/Default App Pool.

The relevant code looks like this:
private bool ParseXML(string XmlResponseData, ref string
StatusMessage)
{
XmlNodeList List;
XmlNode AppServerNode;
XmlNode SubNode;

try
{
XmlDocument Document = new XmlDocument();
Document.LoadXml(XmlResponseData);

// lots of other code related to taking stuff out of Document
and putting into member variables omitted
}
catch
{
SetError("Failed to load XML response from server ");
return(false);
}

return(true);
}

Most of the time everything works fine. Once in a great while, the
code goes into the catch block. I can tell it goes into the catch
block because "SetError" is a function that ultimately logs the error
message. There is code right before this function that shows
XmlResponseData and logs it. As far as I can tell (and many others
who have stared at it) there is absolutely no difference between the
XML that works fine and the XML that causes the catch block to
execute. In fact, the evidence is stronger than that: we have the
ability to send the same message. Many of us are suspecting that the
lines "new XmlDocument()" or "Document.LoadXml(XmlResponseData)" are
failing (perhaps a memory problem?). Unfortunately, we can't
(currently) modify the code that is running to add more logging at key
places.

There is some more relevant information: Once the problem occurs, it
does not go away UNTIL someone does a "Recycle" on the DefaultAppPool
in IIS. I don't know much about IIS and Application Pools, so I have
no idea why this would fix the problem but it does (until the next
time of course). Another possibly related bit of information is that
the DefaultAppPool is set to auto recycle every 29 hours. Finally, we
occasionally have messages in the log of the form:

A process serving application pool 'DefaultAppPool' exceeded time
limits during shut down. The process id was '4244'

I realize that I probably need to give more details. The problem is
not well defined. I welcome all comments/suggestions/flames on how to
move forward or perform additional tests. Suggestions for more
appropriate newsgroups would also be most welcome. As you can see,
the problem seems to touch a few areas (ASP.NET, IIS, XML).

Sincerely,

Dave

Re: Intermittent error with XmlDocument on ASP.NET app. Related to IIS and DefaultAppPool

You're going to need to modify the catch block to say more than
"something failed". Exception code will be invaluable to determine
what is going awry.

Recycling simply restarts the process which then runs this code, and
the event log message indicates that you have code which takes >90
seconds to complete when IIS is trying to restart the process. Until
there is evidence to the contrary, I would treat this as two separate
issues.

1. The issue with XmlDocument isn't really related to IIS,
DefaultAppPool, nor ASP.Net. You've got code which appear to
intermittently fail to instantiate (which either indicates your
application uses too much and/or leaks memory [because it is not
garbaged collected fast enough] or your system has insufficient memory
to support the application)
2. The issue with hangs during shutdown will require you to look at
the shutdown path of your application. Like failure paths, shutdown is
another common place for faulty user code because it is often
overlooked and not traversed with great attention.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//



On Aug 3, 10:25 am, Dave wrote:
> Hi,
>
> I have a very bizarre intermittent problem that occurs with some
> ASP.NET 1.1 (C#) code I inherited. I'll try to state the problem
> sucintly; if more detail is needed please ask! The code is in a
> WebApplication. The web application is configured in IIS 6.0 to run
> under Application Pools/Default App Pool.
>
> The relevant code looks like this:
> private bool ParseXML(string XmlResponseData, ref string
> StatusMessage)
> {
> XmlNodeList List;
> XmlNode AppServerNode;
> XmlNode SubNode;
>
> try
> {
> XmlDocument Document = new XmlDocument();
> Document.LoadXml(XmlResponseData);
>
> // lots of other code related to taking stuff out of Document
> and putting into member variables omitted
> }
> catch
> {
> SetError("Failed to load XML response from server ");
> return(false);
> }
>
> return(true);
>
> }
>
> Most of the time everything works fine. Once in a great while, the
> code goes into the catch block. I can tell it goes into the catch
> block because "SetError" is a function that ultimately logs the error
> message. There is code right before this function that shows
> XmlResponseData and logs it. As far as I can tell (and many others
> who have stared at it) there is absolutely no difference between the
> XML that works fine and the XML that causes the catch block to
> execute. In fact, the evidence is stronger than that: we have the
> ability to send the same message. Many of us are suspecting that the
> lines "new XmlDocument()" or "Document.LoadXml(XmlResponseData)" are
> failing (perhaps a memory problem?). Unfortunately, we can't
> (currently) modify the code that is running to add more logging at key
> places.
>
> There is some more relevant information: Once the problem occurs, it
> does not go away UNTIL someone does a "Recycle" on the DefaultAppPool
> in IIS. I don't know much about IIS and Application Pools, so I have
> no idea why this would fix the problem but it does (until the next
> time of course). Another possibly related bit of information is that
> the DefaultAppPool is set to auto recycle every 29 hours. Finally, we
> occasionally have messages in the log of the form:
>
> A process serving application pool 'DefaultAppPool' exceeded time
> limits during shut down. The process id was '4244'
>
> I realize that I probably need to give more details. The problem is
> not well defined. I welcome all comments/suggestions/flames on how to
> move forward or perform additional tests. Suggestions for more
> appropriate newsgroups would also be most welcome. As you can see,
> the problem seems to touch a few areas (ASP.NET, IIS, XML).
>
> Sincerely,
>
> Dave

Re: Intermittent error with XmlDocument on ASP.NET app. Related to IIS and DefaultAppPool

David,

Thank you for your response. I will take your advice and put in more
descriptive exception code handling. As so often happens, I got new
and corrected information about the bug. It's not quite like it first
described.
Everything runs merrily along for 29 hours (which is the setting for
autorecycling of the pool). At this time a message is logged:
A process serving application pool 'DefaultAppPool' exceeded time
limits during shut down. The process id was '4244'

>From this point on, one always gets the exception in the ParseXml
method mentioned about UNTIL someone comes along and manually opens
IIS and does a recycle of the DefaultAppPool.

I will put in exception code handling and try to figure out what is
the difference between the autorecycling (avaiable under properties in
IIS) and manually recycling (rt. clicking and picking recycle).

Thanks again,

Dave
On Aug 3, 3:23 pm, David Wang wrote:
> You're going to need to modify the catch block to say more than
> "something failed". Exception code will be invaluable to determine
> what is going awry.
>
> Recycling simply restarts the process which then runs this code, and
> the event log message indicates that you have code which takes >90
> seconds to complete when IIS is trying to restart the process. Until
> there is evidence to the contrary, I would treat this as two separate
> issues.
>
> 1. The issue with XmlDocument isn't really related to IIS,
> DefaultAppPool, nor ASP.Net. You've got code which appear to
> intermittently fail to instantiate (which either indicates your
> application uses too much and/or leaks memory [because it is not
> garbaged collected fast enough] or your system has insufficient memory
> to support the application)
> 2. The issue with hangs during shutdown will require you to look at
> the shutdown path of your application. Like failure paths, shutdown is
> another common place for faulty user code because it is often
> overlooked and not traversed with great attention.
>
> //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David. Wang
> //
>
> On Aug 3, 10:25 am, Dave wrote:
>
>
>
> > Hi,
>
> > I have a very bizarre intermittent problem that occurs with some
> > ASP.NET 1.1 (C#) code I inherited. I'll try to state the problem
> > sucintly; if more detail is needed please ask! The code is in a
> > WebApplication. The web application is configured in IIS 6.0 to run
> > under Application Pools/Default App Pool.
>
> > The relevant code looks like this:
> > private bool ParseXML(string XmlResponseData, ref string
> > StatusMessage)
> > {
> > XmlNodeList List;
> > XmlNode AppServerNode;
> > XmlNode SubNode;
>
> > try
> > {
> > XmlDocument Document = new XmlDocument();
> > Document.LoadXml(XmlResponseData);
>
> > // lots of other code related to taking stuff out of Document
> > and putting into member variables omitted
> > }
> > catch
> > {
> > SetError("Failed to load XML response from server ");
> > return(false);
> > }
>
> > return(true);
>
> > }
>
> > Most of the time everything works fine. Once in a great while, the
> > code goes into the catch block. I can tell it goes into the catch
> > block because "SetError" is a function that ultimately logs the error
> > message. There is code right before this function that shows
> > XmlResponseData and logs it. As far as I can tell (and many others
> > who have stared at it) there is absolutely no difference between the
> > XML that works fine and the XML that causes the catch block to
> > execute. In fact, the evidence is stronger than that: we have the
> > ability to send the same message. Many of us are suspecting that the
> > lines "new XmlDocument()" or "Document.LoadXml(XmlResponseData)" are
> > failing (perhaps a memory problem?). Unfortunately, we can't
> > (currently) modify the code that is running to add more logging at key
> > places.
>
> > There is some more relevant information: Once the problem occurs, it
> > does not go away UNTIL someone does a "Recycle" on the DefaultAppPool
> > in IIS. I don't know much about IIS and Application Pools, so I have
> > no idea why this would fix the problem but it does (until the next
> > time of course). Another possibly related bit of information is that
> > the DefaultAppPool is set to auto recycle every 29 hours. Finally, we
> > occasionally have messages in the log of the form:
>
> > A process serving application pool 'DefaultAppPool' exceeded time
> > limits during shut down. The process id was '4244'
>
> > I realize that I probably need to give more details. The problem is
> > not well defined. I welcome all comments/suggestions/flames on how to
> > move forward or perform additional tests. Suggestions for more
> > appropriate newsgroups would also be most welcome. As you can see,
> > the problem seems to touch a few areas (ASP.NET, IIS, XML).
>
> > Sincerely,
>
> > Dave- Hide quoted text -
>
> - Show quoted text -

Re: Intermittent error with XmlDocument on ASP.NET app. Related to IIS and DefaultAppPool

When running managed code, I recommend disabling the periodic recycle
every 29 hours. That setting is relevant for legacy ASP/COM based
applications but is not good idea for managed applications like
ASP.Net. This is alright because Application Settings always need to
be tuned, and the defaults are not necessarily tuned towards ASP.Net
at all.

It really sounds like you have code which hangs during shutdown, keeps
some resource or file open, and thereafter always causes ParseXml to
fail because it tries (and fails) to use that resource.

I would try to turn off periodic recycling to see if that avois the
hanging. Then, try to figure out what is wrong.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//




On Aug 3, 8:56 pm, Dave wrote:
> David,
>
> Thank you for your response. I will take your advice and put in more
> descriptive exception code handling. As so often happens, I got new
> and corrected information about the bug. It's not quite like it first
> described.
> Everything runs merrily along for 29 hours (which is the setting for
> autorecycling of the pool). At this time a message is logged:
> A process serving application pool 'DefaultAppPool' exceeded time
> limits during shut down. The process id was '4244'
>
> >From this point on, one always gets the exception in the ParseXml
>
> method mentioned about UNTIL someone comes along and manually opens
> IIS and does a recycle of the DefaultAppPool.
>
> I will put in exception code handling and try to figure out what is
> the difference between the autorecycling (avaiable under properties in
> IIS) and manually recycling (rt. clicking and picking recycle).
>
> Thanks again,
>
> Dave
> On Aug 3, 3:23 pm, David Wang wrote:
>
>
>
> > You're going to need to modify the catch block to say more than
> > "something failed". Exception code will be invaluable to determine
> > what is going awry.
>
> > Recycling simply restarts the process which then runs this code, and
> > the event log message indicates that you have code which takes >90
> > seconds to complete when IIS is trying to restart the process. Until
> > there is evidence to the contrary, I would treat this as two separate
> > issues.
>
> > 1. The issue with XmlDocument isn't really related to IIS,
> > DefaultAppPool, nor ASP.Net. You've got code which appear to
> > intermittently fail to instantiate (which either indicates your
> > application uses too much and/or leaks memory [because it is not
> > garbaged collected fast enough] or your system has insufficient memory
> > to support the application)
> > 2. The issue with hangs during shutdown will require you to look at
> > the shutdown path of your application. Like failure paths, shutdown is
> > another common place for faulty user code because it is often
> > overlooked and not traversed with great attention.
>
> > //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David. Wang
> > //
>
> > On Aug 3, 10:25 am, Dave wrote:
>
> > > Hi,
>
> > > I have a very bizarre intermittent problem that occurs with some
> > > ASP.NET 1.1 (C#) code I inherited. I'll try to state the problem
> > > sucintly; if more detail is needed please ask! The code is in a
> > > WebApplication. The web application is configured in IIS 6.0 to run
> > > under Application Pools/Default App Pool.
>
> > > The relevant code looks like this:
> > > private bool ParseXML(string XmlResponseData, ref string
> > > StatusMessage)
> > > {
> > > XmlNodeList List;
> > > XmlNode AppServerNode;
> > > XmlNode SubNode;
>
> > > try
> > > {
> > > XmlDocument Document = new XmlDocument();
> > > Document.LoadXml(XmlResponseData);
>
> > > // lots of other code related to taking stuff out of Document
> > > and putting into member variables omitted
> > > }
> > > catch
> > > {
> > > SetError("Failed to load XML response from server ");
> > > return(false);
> > > }
>
> > > return(true);
>
> > > }
>
> > > Most of the time everything works fine. Once in a great while, the
> > > code goes into the catch block. I can tell it goes into the catch
> > > block because "SetError" is a function that ultimately logs the error
> > > message. There is code right before this function that shows
> > > XmlResponseData and logs it. As far as I can tell (and many others
> > > who have stared at it) there is absolutely no difference between the
> > > XML that works fine and the XML that causes the catch block to
> > > execute. In fact, the evidence is stronger than that: we have the
> > > ability to send the same message. Many of us are suspecting that the
> > > lines "new XmlDocument()" or "Document.LoadXml(XmlResponseData)" are
> > > failing (perhaps a memory problem?). Unfortunately, we can't
> > > (currently) modify the code that is running to add more logging at key
> > > places.
>
> > > There is some more relevant information: Once the problem occurs, it
> > > does not go away UNTIL someone does a "Recycle" on the DefaultAppPool
> > > in IIS. I don't know much about IIS and Application Pools, so I have
> > > no idea why this would fix the problem but it does (until the next
> > > time of course). Another possibly related bit of information is that
> > > the DefaultAppPool is set to auto recycle every 29 hours. Finally, we
> > > occasionally have messages in the log of the form:
>
> > > A process serving application pool 'DefaultAppPool' exceeded time
> > > limits during shut down. The process id was '4244'
>
> > > I realize that I probably need to give more details. The problem is
> > > not well defined. I welcome all comments/suggestions/flames on how to
> > > move forward or perform additional tests. Suggestions for more
> > > appropriate newsgroups would also be most welcome. As you can see,
> > > the problem seems to touch a few areas (ASP.NET, IIS, XML).
>
> > > Sincerely,
>
> > > Dave- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

Re: Intermittent error with XmlDocument on ASP.NET app. Related to

This may help your issue;

http://support.microsoft.com/default.aspx?scid=kb;en-us;8212 68&Product=asp


"David Wang" wrote:

> When running managed code, I recommend disabling the periodic recycle
> every 29 hours. That setting is relevant for legacy ASP/COM based
> applications but is not good idea for managed applications like
> ASP.Net. This is alright because Application Settings always need to
> be tuned, and the defaults are not necessarily tuned towards ASP.Net
> at all.
>
> It really sounds like you have code which hangs during shutdown, keeps
> some resource or file open, and thereafter always causes ParseXml to
> fail because it tries (and fails) to use that resource.
>
> I would try to turn off periodic recycling to see if that avois the
> hanging. Then, try to figure out what is wrong.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
> On Aug 3, 8:56 pm, Dave wrote:
> > David,
> >
> > Thank you for your response. I will take your advice and put in more
> > descriptive exception code handling. As so often happens, I got new
> > and corrected information about the bug. It's not quite like it first
> > described.
> > Everything runs merrily along for 29 hours (which is the setting for
> > autorecycling of the pool). At this time a message is logged:
> > A process serving application pool 'DefaultAppPool' exceeded time
> > limits during shut down. The process id was '4244'
> >
> > >From this point on, one always gets the exception in the ParseXml
> >
> > method mentioned about UNTIL someone comes along and manually opens
> > IIS and does a recycle of the DefaultAppPool.
> >
> > I will put in exception code handling and try to figure out what is
> > the difference between the autorecycling (avaiable under properties in
> > IIS) and manually recycling (rt. clicking and picking recycle).
> >
> > Thanks again,
> >
> > Dave
> > On Aug 3, 3:23 pm, David Wang wrote:
> >
> >
> >
> > > You're going to need to modify the catch block to say more than
> > > "something failed". Exception code will be invaluable to determine
> > > what is going awry.
> >
> > > Recycling simply restarts the process which then runs this code, and
> > > the event log message indicates that you have code which takes >90
> > > seconds to complete when IIS is trying to restart the process. Until
> > > there is evidence to the contrary, I would treat this as two separate
> > > issues.
> >
> > > 1. The issue with XmlDocument isn't really related to IIS,
> > > DefaultAppPool, nor ASP.Net. You've got code which appear to
> > > intermittently fail to instantiate (which either indicates your
> > > application uses too much and/or leaks memory [because it is not
> > > garbaged collected fast enough] or your system has insufficient memory
> > > to support the application)
> > > 2. The issue with hangs during shutdown will require you to look at
> > > the shutdown path of your application. Like failure paths, shutdown is
> > > another common place for faulty user code because it is often
> > > overlooked and not traversed with great attention.
> >
> > > //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David. Wang
> > > //
> >
> > > On Aug 3, 10:25 am, Dave wrote:
> >
> > > > Hi,
> >
> > > > I have a very bizarre intermittent problem that occurs with some
> > > > ASP.NET 1.1 (C#) code I inherited. I'll try to state the problem
> > > > sucintly; if more detail is needed please ask! The code is in a
> > > > WebApplication. The web application is configured in IIS 6.0 to run
> > > > under Application Pools/Default App Pool.
> >
> > > > The relevant code looks like this:
> > > > private bool ParseXML(string XmlResponseData, ref string
> > > > StatusMessage)
> > > > {
> > > > XmlNodeList List;
> > > > XmlNode AppServerNode;
> > > > XmlNode SubNode;
> >
> > > > try
> > > > {
> > > > XmlDocument Document = new XmlDocument();
> > > > Document.LoadXml(XmlResponseData);
> >
> > > > // lots of other code related to taking stuff out of Document
> > > > and putting into member variables omitted
> > > > }
> > > > catch
> > > > {
> > > > SetError("Failed to load XML response from server ");
> > > > return(false);
> > > > }
> >
> > > > return(true);
> >
> > > > }
> >
> > > > Most of the time everything works fine. Once in a great while, the
> > > > code goes into the catch block. I can tell it goes into the catch
> > > > block because "SetError" is a function that ultimately logs the error
> > > > message. There is code right before this function that shows
> > > > XmlResponseData and logs it. As far as I can tell (and many others
> > > > who have stared at it) there is absolutely no difference between the
> > > > XML that works fine and the XML that causes the catch block to
> > > > execute. In fact, the evidence is stronger than that: we have the
> > > > ability to send the same message. Many of us are suspecting that the
> > > > lines "new XmlDocument()" or "Document.LoadXml(XmlResponseData)" are
> > > > failing (perhaps a memory problem?). Unfortunately, we can't
> > > > (currently) modify the code that is running to add more logging at key
> > > > places.
> >
> > > > There is some more relevant information: Once the problem occurs, it
> > > > does not go away UNTIL someone does a "Recycle" on the DefaultAppPool
> > > > in IIS. I don't know much about IIS and Application Pools, so I have
> > > > no idea why this would fix the problem but it does (until the next
> > > > time of course). Another possibly related bit of information is that
> > > > the DefaultAppPool is set to auto recycle every 29 hours. Finally, we
> > > > occasionally have messages in the log of the form:
> >
> > > > A process serving application pool 'DefaultAppPool' exceeded time
> > > > limits during shut down. The process id was '4244'
> >
> > > > I realize that I probably need to give more details. The problem is
> > > > not well defined. I welcome all comments/suggestions/flames on how to
> > > > move forward or perform additional tests. Suggestions for more
> > > > appropriate newsgroups would also be most welcome. As you can see,
> > > > the problem seems to touch a few areas (ASP.NET, IIS, XML).
> >
> > > > Sincerely,
> >
> > > > Dave- Hide quoted text -
> >
> > > - Show quoted text -- Hide quoted text -
> >
> > - Show quoted text -
>
>
>