Something Sysinternals doesn't have: "Process DESTROYER"

[Volatus]

Is this even possible? Today I had to reboot my computer (an event in and of itself) for the dumbest reason. Windows Installer (I LOATHE Windows Installer) decided to hang and become one of those occasional "dead-locked processes". One that you can't kill, because it's waiting on some kind of I/O operation that will never complete. Will. Never complete. So your only option is to reboot, because the process will never die. Not through any fault of permissions, but just because it refuses to die.

However, what's sick is that Windows can end the process by means of the "process not responding" dialog box, during shutdown only! So that means it's obviously ABLE to kill it, but it just won't, unless you are in the process of rebooting... by which point, killing the process is useless anyway because the reset button is arm's length away!

By "dead-locked" process, I mean a process that only has one thread (shown in Process Explorer), and is stuck in "Wait:Executive" state (from what I remember). The thread can't be killed - you can try and try and try, but it just ignores your "kill" requests. Really bad for viruses, I imagine... when you can't even kill them! It also doesn't respond to closing handles, and especially not to killing the process (which it doesn't).

So, yeah. It's a process that won't die. Sometimes I can solve these by going into Standby, and resuming will kill the process by unlocking the locked I/O, which allows it to catch up to that "DIE ALREADY!" request I gave it much earlier. However, that's hit and miss - and if you miss, you're stuck with a computer that's locked at the "Preparing to stand by" screen and you can't do a **** thing about it - it's hopelessly frozen and you can't even save your work (I even forgot what I lost, but I know I had a full taskbar...).

A thorough Google reveals that no such tool exists, and that the problem itself hasn't even been identified. So, now there's a topic about it somewhere on the internet (should be able to be identified by my use of the "Wait:Executive" term...). But there's no solution and no tool to fix it.

I don't code desktop software so I don't think I can be the one to make that program. Does anyone have any insight into how to solve this problem? Create a tool that can kill a locked process like that? It happens all too often and it almost always results in having to restart the computer for the dumbest reasons. It drives me nuts!

[geezery]

There is a builtin command for that purpose at least in Windows XP and Windows 2003 Server.

taskkill

here is a small example how to kill a unneeded command prompt.

taskkill /im cmd.exe /f

There is also a command tasklist that you can execute to view all open processes.

[Volatus]

Somehow I'm not sure if that's what I'm looking for... it appears to just be a command line version (blech) of what Process Explorer or Task Manager already tries to do. But I'll keep that in mind if the situation ever does arise again... I'll try to come up with a reproducible scenario to try it on. I think I can make it happen again with what cause it the last time... Windows Installer is a huge flaming pile of crap after all. I can just try doing what I did a few minutes ago.

(edit: guess i don't need to quote the whole post...)

(edit edit: Nope! The unpredictable piece of crap actually didn't jam up this time. Long story, remembered to the T, exact same lead-up, but it actually finished properly this time. Ugh. Sometimes I loathe Windows (and I always loathe Microsoft) but I guess I've got to live with it...)

Edited May 19, 2008 by Volatus

[cluberti]

Consider simply attaching a debugger (like windbg) to the process, and then forcibly closing the debugger. Any process attached should "die" as well.

The real question/problem you face is that your apps are getting into a state where they're hung like this - I think troubleshooting HOW they get into a single thread wait state is probably going to do more for you, long term, than figuring out how to band-aid the problem by killing the apps.

[Tripredacus]

Sometimes ProcessMonitor gives you an option to close handles, which is what I had used in the past to kill processes that won't die. Recently, however, it seems like I can't find that option anymore.

[Volatus]

Consider simply attaching a debugger (like windbg) to the process, and then forcibly closing the debugger. Any process attached should "die" as well.

Hm, that could work... I'd be willing to try that in the future as long as the debugger doesn't take up several hundred megs (or require some kind of IDE installed). Google is my friend here.

The real question/problem you face is that your apps are getting into a state where they're hung like this - I think troubleshooting HOW they get into a single thread wait state is probably going to do more for you, long term, than figuring out how to band-aid the problem by killing the apps.

Well, I guess everyone's dying to know how I most recently got into this "mess". Reader's digest version: s***ty, unreliable Microsoft software and their installers, combined with a lack of patience for MS software's "managed" code. Not so reader's digest version...

A long time ago (in a galaxy far far away), I installed Microsoft Virtual PC. And life was good. An equally long time ago, I emptied out my \Windows\Installer folder of a metric a**-ton of unnecessary bloat (in the form of .msi files of software that's ALREADY INSTALLED). I already knew that this stuff would give me an error when trying to uninstall it (thank you Microsoft for your ridiculous "make them hold onto the installer in order to uninstall it" policy) but I failed to care. Now, after installing VMware and moving all my virtual machines over to VMware (and finding how much faster and better they run), I want to ditch MS Virtual PC in order to keep my computer running smooth. I add/remove programs it, click it, Uninstall. "Urr, where's Virtual PC.msi?!!". Grr... I cancel it and frustratedly dig out the installer (ambiguously named "setup.exe" which I renamed to "VirtualPCSetup.exe"...). I run the installer, naturally it doesn't TELL me that it's extracting files but the process goes so quick I didn't notice a delay before I got the message that, paraphrasing from memory, "Virtual PC must be uninstalled before it can be reinstalled". Now isn't that great. Most, if not ALL other Windows Installer (bleh) -based software I've used always gives you an option to repair, modify, or uninstall, when the installer is run when the software is already installed.

So I reach for my temp folder and make a copy of Virtual PC 2007.msi (iirc), then click OK to exit the error. The original MSI file stays in the temp folder and the installer quits (oh, Microsoft, how I love your litter policy as well). So I go back to add/remove programs, and start the uninstall. It seems to have dropped a copy of itself in my Windows folder as well, because it didn't ask me for the file. It runs through "gathering information" and stops right before the end of the progress bar. Stuck. Clicking Cancel does nothing except change the dialog to say "Well, I'll cancel eventually, but long after it's too late" (whatever happened to software that knew to drop what it was doing and ABORT when a user says "cancel"?). I go into Task Manager, sort by name, and kill two msiexec.exe processes (as I usually do for hung/broken InstallShield/Windows Installer crap processes). First one I killed didn't exit and didn't close the dialog box, so I killed the other, which made the uninstaller go away. But that other one stayed behind. I go into Process Explorer, and found it, with no parent process (evidently it was started by the one I was able to kill?), and totally frozen. It had one thread - something to the effect of CreateThread (IIRC), and stuck in Wait:Executive state.

I try everything I can think of (including Googling for a solution) then I go for the age-old, tried and true solution - Standby. If it can get into standby (which will typically work if a "zombified" process is caused by a dead I/O operation like a CD drive I unplugged, or jammed while burning, etc), then I can just resume and everything will be happy again. Not this time. I get stuck at a "Preparing to stand by" screen that won't go anywhere. Can't Ctrl+Alt+Del it, can't use Remote Desktop to get around it (it just kicks me right back out the moment I log in), can't kill the process (obviously!), can't do pretty much anything. Spent about 15 minutes at that standby screen trying to find a way to save the work that was hidden behind that Standby screen before irritatedly mashing my Reset button and cursing Microsoft to the depths of Hell.

So yeah, that's how that happened.

Edited May 19, 2008 by Volatus

[nmX.Memnoch]

Wait a minute...

First you go and do something that you know is going to break stuff?

I emptied out my \Windows\Installer folder of a metric a**-ton of unnecessary bloat (in the form of .msi files of software that's ALREADY INSTALLED). I already knew that this stuff would give me an error when trying to uninstall it

And then you want to blame it on Microsoft?

Well, I guess everyone's dying to know how I most recently got into this "mess". Reader's digest version: s***ty, unreliable Microsoft software and their installers, combined with a lack of patience for MS software's "managed" code.

Yeah, let's shift the blame.

You do know that any installer, including InstallShield, leaves files behind so that it knows how to properly uninstall the application, right?

"What'd you do?"

"Nothing honestly, it's just the crap Micro$oft software!" <--'Cause you know it's funny when people use the $.

"Are you sure you didn't do anything?"

"Well, I did delete some files that shouldn't have been there to begin with!"

Stories like this are what keep me in a job...

[Volatus]

Please enlighten me as to what Windows Installer does that requires it to constantly keep copies of ALL the installed data on the hard drive... as opposed to real, reliable, and stable "third party" installers like NSIS, that are more powerful and don't require you to use the installer to uninstall it? What makes Windows Installer so special?

And believe me, dealing with this kind of crap almost every day, this is FAR from the only beef I have with Windows Installer. Keeping copies of the installer data on the hard drive as a "requirement" is just the tip of the "insatiable bloat" iceberg... let's not even get into the registry problem.

[cluberti]

A long time ago (in a galaxy far far away), I installed Microsoft Virtual PC. And life was good. An equally long time ago, I emptied out my \Windows\Installer folder of a metric a**-ton of unnecessary bloat (in the form of .msi files of software that's ALREADY INSTALLED). I already knew that this stuff would give me an error when trying to uninstall it (thank you Microsoft for your ridiculous "make them hold onto the installer in order to uninstall it" policy) but I failed to care.

To play devil's advocate, you deleted the installer (MSI) from the uninstall location, and then tried to uninstall it, and it broke?

And your quote about other installers, they are not managed, but install an uninstaller with the product. However, this makes it impossible to centrally manage these without a 3rd party product in an enterprise (like SMS can do) - whereas an MSI can be installed from anywhere and then removed again via policy.

It is also a way to allow for a repair of an application that may have broken without having the installation media available, also a nice touch if you, say, have just a laptop with you when some MSI-installed app breaks and you have to repair it. Possible with an MSI-based package because the data to fix it is on the machine, and not possible with other installer types without having the installer somewhere (either elsewhere on the disk, or on installation media you carry with you).

It's 6 of one, half-dozen of the other. And having been bit by a broken non-MSI-installed application before without the media with me, I do like having the ability to repair the app without finding or having the media on-hand.

I don't want to sound like a jerk, but I am just playing devil's advocate. I don't have all of the "registry" problems or "installer bloat" issues you complain of in my environment, but I'm also pretty on top of things when it comes to installed apps and such. I don't have to support anything truly old either, so maybe that just makes me lucky. But, to be fair, I've not found any real issues with MSI packages that you are complaining of either, so it is possible it is something specific to your environment.

[Volatus]

On the flip side, there's the rampant mismanagement of MSI installations that cause embarassing "Huh... uh... well, my computer decided that for no apparent reason, Microsoft Powerpoint is no longer installed properly (during my presentation), so it's trying to repair its--... wait, why is it asking me for the installation media? I don't have it with me... uh, cancel, ffs, it's already working fine! CANCEL! Ugh... anyway, uh, as I was saying"... for no reason other than that Windows Installer felt like doing it, it found some reason to fire up the whole installer and screw with whatever I was doing. Sometimes I've had no resolve other than to just place the dialog box below the screen and continue working. Sometimes this happens even without changing anything out of the ordinary (like deleting the Installer files). Even if it did happen because of deleting the installer files, what business is it of Windows' that a working program is now "broken" because it can't find the installer for it? Used to be common practice in the computer world to delete the installer after it's installed...

Never before, with any, say, old InstallShield, or NSIS-installed program, have I had something just mysteriously "break" and need "repairing". If I did, carrying the lightweight and much less registry-bloated installer with me, and just re-running the installer over the top of the existing installer, would fix the problem immediately. Only with MSI would reinstalling over an existing installation "break" something due to its unprecedented amount of unnecessary bloat. The sad thing is, as in the case of Microsoft Office, even if you opted to keep a copy of the whole install file on your drive, it'll STILL find some reason to prompt you, without even telling what file it's looking for, for the installation media in order to continue. Love you guys, Microsoft. I knew the MS train was headed for the Vista brick wall when I saw Windows Installer being adopted...

As for companies, well, that's understandable, but I highly doubt there's a single corporate environment that's being run entirely with MS tools anyway. I doubt even Microsoft is run without some kind of tool to install non-MSI software. And with that, it essentially defeats the purpose, because if you've got to use that software for one, you could just as easily install everything with it. Sigh...

Ceaseramble.

Simply put, it seems there's a reason Foxit Software offers Foxit Reader in two different flavors - one MSI installer, and one of their own installer (EXE). MSI is just no good for end users. Good for companies, sure, because at the cost of reduced performance and higher disk space requirements, there are less help desk calls for figuring out why a program isn't working right. However, for end users, it's just an unnecessary overhead. I wish more companies would take the Foxit Reader example.

edit: Even more simply put, this is so far off topic... the point of this topic is being able to kill "frozen" processes, Windows Installer or otherwise. Hoy...

Edited May 19, 2008 by Volatus

[cluberti]

Well, MSI doesn't "just randomly" find a problem and pop-up to fix it, something in the original install is missing and then it tries to "fix" it (the reason old installers don't do this is they lack the functionality to detect when an installed product is no longer matching the installation manifest, but that's another discussion). As to Office, they have some of their own logic to handle this and they do have installation options to place the right files on disk, or just the MSI to do the "detection logic". You can install office without the need for media, but it does place a cache on disk (not done by default for obvious reasons), so if your complaint is mainly around Office MSIs, I feel for you.

As to the original post, I still say it's probably better to "fix" the problem that got you into the mix, but if you can't (for whatever reason), then consider the debugger approach if taskkill or pskill do not do the trick.

[Volatus]

Well, as you found yourself, I typically get myself into strange situations - that's how I learn to fix Windows, by finding all sorts of new and creative ways to break it. There's just usually a tool - or a way - to fix pretty much any problem, so I'm not afraid to do seemingly stupid things like unplug a CD drive that locked up, then rescan for hardware changes. There's just that occasional process that gets hung up on something and kinda ruins the day, y'know? Sometimes you just can't fix the cause. =P

[frog357]

I have seen processes that can't be killed, normally they are being debugged by dwwin.exe or similar. Check to see if you have a doctor watson active the next time you can't kill a process. Also try using a root-kit scanning program like "Rootkit Unhooker" and see what hooks are active on your system.

Have you tried Windows Installer Cleanup Utility?

I think if you become more familiar with Process Explorer you'll find a way to terminate your tasks. If this program can let you terminate winlogon.exe and cause a blue screen, I am fairly confident it should be able to kill your stuck task. If not, close the thread or handle and forcefully crash the program.

[Volatus]

Oouuuuhhh... I totally forgot about those dang hung drwtsn32 tasks. I've had a small stack of those in the past (evidently, debugging each other...) and when I killed the chain, the problem task (in my case, the print spooler) started working again. Not sure why I didn't think of that. I need to start remembering that in the future.

As for the ICU, well, I don't find that utility to be very useful. It's come in handy once or twice when Windows Installer exhibited another of its infamous problems - the Half Installed State in which you can neither install (because it's already installed) nor uninstall (because it's not properly installed) nor repair (because the option is never presented) - but that certainly wouldn't help a generic hung task that happened to be Windows Installer. I think my best bet there is, as you mentioned, checking for drwtsn32 tasks (because on my system, drwtsn32 itself does nothing but crashes since I have Error Reporting uninstalled).

And yeah, Process Explorer can kill anything, but that's because it gets above and beyond the "permissions" problems that Task Manager imposes. It can kill tasks that are responding normally, but... it seems there are still some that don't feel like responding all the time