Unkillable w2wp.exe processes
in [IIS]
|
Prev: FavorUTF8 and PercentUAllowed Http.sys registry settings
Next: An unhandled win32 exception occurred in inetinfo.exe [3428]
From: hoberto on 17 Nov 2008 10:54 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 17 Nov 2008 11:20 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 18 Nov 2008 08:14
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 - |