Debug Diag log analysis

Hi,
We have a web application which is intermittently crashing but is
reproducable on a test environment. I have read about using Debug Diag and
have traced the error, apparently down to an access violation exception
within the ntdll.dll as it tried to write to memory.

Unfortunately I now have no idea of how to proceed. I followed the
advice of changing the analysis method to include CombinedAnalysis but this
only tells me that "The COM+ STA ThreadPool may have been depleted prior to
the time of the dump" and "The pool has grown to its maximum allowable size,
but some threads do not currently have any activity bound to it".
Given the fact that this is a test system with only myself connected I'm
a little uncertain as to what to do with the above information.

I tried running a memory leak rule for w3wp.exe but this didn't catch
anything when my application crashed again.

Can anyone shed any light on what further investigation I can do?

Thanks in advance,
Andy

Re: Debug Diag log analysis

On Nov 27, 9:42 am, AKA Bones
wrote:
> Hi,
> We have a web application which is intermittently crashing but is
> reproducable on a test environment. I have read about using Debug Diag and
> have traced the error, apparently down to an access violation exception
> within the ntdll.dll as it tried to write to memory.
>
> Unfortunately I now have no idea of how to proceed. I followed the
> advice of changing the analysis method to include CombinedAnalysis but this
> only tells me that "The COM+ STA ThreadPool may have been depleted prior to
> the time of the dump" and "The pool has grown to its maximum allowable size,
> but some threads do not currently have any activity bound to it".
> Given the fact that this is a test system with only myself connected I'm
> a little uncertain as to what to do with the above information.
>
> I tried running a memory leak rule for w3wp.exe but this didn't catch
> anything when my application crashed again.
>
> Can anyone shed any light on what further investigation I can do?
>
> Thanks in advance,
> Andy


You need to look at the stack backtrace from DebugDiag for the
offending thread and see what is causing ntdll.dll to write to bad
memory because that is more likely to be the culprit.

You really don't need to do anything more with DebugDiag once you find
the root culprit of the crash, especially when you have the offending
stack backtrace.


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