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

Hello Dave,

It would help a ton to have the actual exception message

If I were you I'd log the error in a more concise way (even if it were just 
for a limited debugging session):


> catch (Exception e)
> {
> SetError("Failed to load XML response from server " + e.Message + "\r\n" 

+ e.StackTrace.ToString());

> return(false);
> }



That should give you the exact location on which things go bad.

You could ofcourse also add a debugger breakpoint on the SetError call (in 
the try/catch block) and let it run. The exact error will be in the locals 
window under $exception

Jesse



> 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
>