From: Rob on
The thread itself is created by a service process (a web server's ISAPI that
handles authentication). It makes some calls to a dll (msvcrt.dll) and the
info from ProcessExplorer shows it as msvcrt.dll!endthreadex+0x2f.

Other threads that are spawned like this go right back to zero CPU, and just
go away. But sometimes they get stuck (with 25-50% of the CPU) and just hang
around. I've use the Process Explorer tool to suspend and to kill the
threads, and its had no detrimental effect on the service. The web service
call that generated the issue completes successfully, and subsequent calls
all work fine. That's what I meant by 'while it was exiting'.

The reason we're looking at this is that these hanging threads can eat up
100% CPU with just 2 or 4 of these calls hung. Not a perfect reason to
terminate the thread, but, while we're waiting on the vendor, it beats us
having to term serv into the web server and run the Process Explorer to kill
it there.
From: Willy Denoyette [MVP] on

"Rob" <LandstarRob(a)nospam.nospam> wrote in message
news:61136B70-6FEA-44F8-8AFB-BCFCB29258D8(a)microsoft.com...
| The thread itself is created by a service process (a web server's ISAPI
that
| handles authentication). It makes some calls to a dll (msvcrt.dll) and
the
| info from ProcessExplorer shows it as msvcrt.dll!endthreadex+0x2f.
|
| Other threads that are spawned like this go right back to zero CPU, and
just
| go away. But sometimes they get stuck (with 25-50% of the CPU) and just
hang
| around. I've use the Process Explorer tool to suspend and to kill the
| threads, and its had no detrimental effect on the service. The web
service
| call that generated the issue completes successfully, and subsequent calls
| all work fine. That's what I meant by 'while it was exiting'.
|
| The reason we're looking at this is that these hanging threads can eat up
| 100% CPU with just 2 or 4 of these calls hung. Not a perfect reason to
| terminate the thread, but, while we're waiting on the vendor, it beats us
| having to term serv into the web server and run the Process Explorer to
kill
| it there.

I assume that both ISAPI and the DLL are implemented using pure native C++,
please correct me if I'm wrong, this is extremely important.
Ok assumed all is unmanaged, so you have a ISAPI DLL that runs a thread
procedure (from the third party DLL) and this thread procedure gets stuck
when it returns (that is when it calls _endthreadex as a result of the
return or explicitly). That means that your webrequest hangs (does not
progress) until you kill that thread, right?
Now what happens in _endthreadex is not something that would cause an
endless loop, so I doubt the explorer info is accurate, my guess is that
_endthreadex is actually running ThreadExit(..) which calls the attached
DLL's (all of them) DllMain function to indicate that the thread is
detaching from the DLL. So, I think your thread is looping in a (the third
party?) DLL's detach function, or you are kind of deadlocking on a detach
(DllMain can only be entered by one thread at a time!). The only thing you
can do to be sure of this is to attach a debugger (instead of explorer),
find out which thread is 'stuck and where (which DLL). Another thing you can
do is ask your vendor what he is doing in the DllMain detach function.
Again, it's very bad practice to kill such a thread, don't forget that you a
running inside IIS and that when killing a thread you will leak a thread
handle, the TLS and the stack assigned to the thread, so after some time
your IIS server will die taking all applications running inside the worker
processes with him, not a pretty picture.

Willy.




From: "Yuan Ren[MSFT]" on
Hi,

Thanks for your reply!

>"I'm not sure if it makes a difference, but its not a thread from another
.NET application."
No matter want kinds of the application, I think using the way which I
mentioned before is an only way to do this, if you can not obtain any fix
for the current issue.

Regards,

Yuan Ren [MSFT]
Microsoft Online Support
======================================================
PLEASE NOTE the newsgroup SECURE CODE and PASSWORD were
updated on February 14, 2006. Please complete a re-registration process
by entering the secure code mmpng06 when prompted. Once you have
entered the secure code mmpng06, you will be able to update your profile
and access the partner newsgroups.
======================================================
When responding to posts, please "Reply to Group" via your newsreader
so that others may learn and benefit from this issue.
======================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================