From: hoberto on
There was no debugger installed prior to this morning, that I am aware
of (unless it's something built-in to Plesk). I installed MS's
DebugDiag tool, and can run user dumps on the processes, but don't
know how to interpret what it outputs. Is there a debugger that comes
standard with W2K3 that I could look for in the process list or a
specific configuration file where I could look to see if the
"OrphanWorkerProcess" is set?



On Nov 14, 3:22 pm, David Wang <w3.4...(a)gmail.com> wrote:
> On Nov 13, 11:40 am, hobe...(a)gmail.com wrote:
>
>
>
> > We have a Parallels Plesk server running on Windows 2003 R2.  The
> > server is up to date on Plesk patches and Windows patches.  All of the
> > domains that Plesk provisions on here are automatically set to a limit
> > of 1 worker process.  We recently had a single domain begin spawning
> > multiple w3wp processed.  Not at any great rate, maybe 20 in a 24 hour
> > period.  The problem was that only one of these processes was active
> > at any given time, and the rest of the processes could not be killed
> > in any manner I'm familiar with.  Task manager would return a success
> > message, but the process never stopped.  Taskkill /f would report
> > success, but the process was still there.  Recycling the app pool for
> > this domain did not help, and restarting IIS entirely left all of the
> > orphaned processes.  I attempted to stop the processes while IIS was
> > stopped, and I tried with the particular domain's app pool was
> > stopped, neither worked.  Has anyone seen this before?  Is there
> > another method to kill processes that I missed?  The only relevant
> > entry I can find in the logs is EventID 1002 in the System log for
> > that domain's app pool.  We eventually moved that domain onto an older
> > Windows 2000 server by itself, where it seems to be running fine.
>
> It sounds like you have "OrphanWorkerProcess" debug option enabled for
> that Application Pool (non-default configuration), which means that
> when an application crashes the w3wp.exe and a debugger is configured
> and listening, IIS will simply leave it behind for debugging purposes.
> And in some situations, you won't be able to kill the w3wp.exe with a
> debugger attached. Kill the debugger and the debugee (w3wp.exe) will
> naturally go away.
>
> //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David.Wang
> //

From: hoberto on
There was no debugger installed prior to this morning, that I am aware
of (unless it's something built-in to Plesk). I installed MS's
DebugDiag tool, and can run user dumps on the processes, but don't
know how to interpret what it outputs. Is there a debugger that comes
standard with W2K3 that I could look for in the process list or a
specific configuration file where I could look to see if the
"OrphanWorkerProcess" is set?



On Nov 14, 3:22 pm, David Wang <w3.4...(a)gmail.com> wrote:
> On Nov 13, 11:40 am, hobe...(a)gmail.com wrote:
>
>
>
> > We have a Parallels Plesk server running on Windows 2003 R2.  The
> > server is up to date on Plesk patches and Windows patches.  All of the
> > domains that Plesk provisions on here are automatically set to a limit
> > of 1 worker process.  We recently had a single domain begin spawning
> > multiple w3wp processed.  Not at any great rate, maybe 20 in a 24 hour
> > period.  The problem was that only one of these processes was active
> > at any given time, and the rest of the processes could not be killed
> > in any manner I'm familiar with.  Task manager would return a success
> > message, but the process never stopped.  Taskkill /f would report
> > success, but the process was still there.  Recycling the app pool for
> > this domain did not help, and restarting IIS entirely left all of the
> > orphaned processes.  I attempted to stop the processes while IIS was
> > stopped, and I tried with the particular domain's app pool was
> > stopped, neither worked.  Has anyone seen this before?  Is there
> > another method to kill processes that I missed?  The only relevant
> > entry I can find in the logs is EventID 1002 in the System log for
> > that domain's app pool.  We eventually moved that domain onto an older
> > Windows 2000 server by itself, where it seems to be running fine.
>
> It sounds like you have "OrphanWorkerProcess" debug option enabled for
> that Application Pool (non-default configuration), which means that
> when an application crashes the w3wp.exe and a debugger is configured
> and listening, IIS will simply leave it behind for debugging purposes.
> And in some situations, you won't be able to kill the w3wp.exe with a
> debugger attached. Kill the debugger and the debugee (w3wp.exe) will
> naturally go away.
>
> //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David.Wang
> //

From: hoberto on
OrphanWorkerProcess is set to FALSE, and there are no processes of any
kind attached to the orphaned worker processes. But, they remain
unkillable.



On Nov 17, 10:14 pm, David Wang <w3.4...(a)gmail.com> wrote:
> Look up documentation on MSDN for OrphanWorkerProcess.
>
> Use the following command to see if there is any configuration in IIS
> set:
>   ADSUTIL.VBS Find OrphanWorkerProcess
>
> Looking for a standard debugger name in the process list is not useful
> because if something could have configured these settings, it could
> have done anything to your computer and hence used any program name.
> You need to see what is ACTUALLY configured to run and look for it
> specifically.
>
> Alternatively, you can use the Microsoft Debugging Tool:
>   TLIST.EXE -t
>
> And list the process tree of w3wp.exe. When debuggers are attached to
> w3wp.exe, they show up in the process tree for w3wp.exe.
>
> //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David.Wang
> //
>
> On Nov 17, 7:54 am, hobe...(a)gmail.com wrote:
>
> > There was no debugger installed prior to this morning, that I am aware
> > of (unless it's something built-in to Plesk).  I installed MS's
> > DebugDiag tool, and can run user dumps on the processes, but don't
> > know how to interpret what it outputs.  Is there a debugger that comes
> > standard with W2K3 that I could look for in the process list or a
> > specific configuration file where I could look to see if the
> > "OrphanWorkerProcess" is set?
>
> > On Nov 14, 3:22 pm, David Wang <w3.4...(a)gmail.com> wrote:
>
> > > On Nov 13, 11:40 am, hobe...(a)gmail.com wrote:
>
> > > > We have a Parallels Plesk server running on Windows 2003 R2.  The
> > > > server is up to date on Plesk patches and Windows patches.  All of the
> > > > domains that Plesk provisions on here are automatically set to a limit
> > > > of 1 worker process.  We recently had a single domain begin spawning
> > > > multiple w3wp processed.  Not at any great rate, maybe 20 in a 24 hour
> > > > period.  The problem was that only one of these processes was active
> > > > at any given time, and the rest of the processes could not be killed
> > > > in any manner I'm familiar with.  Task manager would return a success
> > > > message, but the process never stopped.  Taskkill /f would report
> > > > success, but the process was still there.  Recycling the app pool for
> > > > this domain did not help, and restarting IIS entirely left all of the
> > > > orphaned processes.  I attempted to stop the processes while IIS was
> > > > stopped, and I tried with the particular domain's app pool was
> > > > stopped, neither worked.  Has anyone seen this before?  Is there
> > > > another method to kill processes that I missed?  The only relevant
> > > > entry I can find in the logs is EventID 1002 in the System log for
> > > > that domain's app pool.  We eventually moved that domain onto an older
> > > > Windows 2000 server by itself, where it seems to be running fine.
>
> > > It sounds like you have "OrphanWorkerProcess" debug option enabled for
> > > that Application Pool (non-default configuration), which means that
> > > when an application crashes the w3wp.exe and a debugger is configured
> > > and listening, IIS will simply leave it behind for debugging purposes..
> > > And in some situations, you won't be able to kill the w3wp.exe with a
> > > debugger attached. Kill the debugger and the debugee (w3wp.exe) will
> > > naturally go away.
>
> > > //Davidhttp://w3-4u.blogspot.comhttp://blogs.msdn.com/David.Wang
> > > //- Hide quoted text -
>
> > - Show quoted text -