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 13 Nov 2008 14:40 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.
From: Trevor Benedict on 13 Nov 2008 19:27 Here's another one, PSKill http://technet.microsoft.com/en-us/sysinternals/bb896683.aspx Regards, Trevor Benedict MCSD <hoberto(a)gmail.com> wrote in message news:2c674219-0c39-42f7-adca-e77ac68d179e(a)r15g2000prh.googlegroups.com... > 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.
From: hoberto on 14 Nov 2008 09:33 Same result as taskkill, it returns like it was successful, but the process is still running. We haven't rebooted the box since we moved the domain to another server, so I still have 5 w3wp.exe belonging to this domain still hanging out if anyone has any other ideas. On Nov 13, 7:27 pm, "Trevor Benedict" <trevorn...(a)gmail.com> wrote: > Here's another one, PSKillhttp://technet.microsoft.com/en-us/sysinternals/bb896683.aspx > > Regards, > > Trevor Benedict > MCSD > > <hobe...(a)gmail.com> wrote in message > > news:2c674219-0c39-42f7-adca-e77ac68d179e(a)r15g2000prh.googlegroups.com... > > > 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.
From: hoberto on 17 Nov 2008 10:53 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 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 > // |