.NET Framework Won't Install - Who's Locking My File?

At the company where I work, we develop in-house applications mainly for the .NET platform.  In addition to the many good things about the .NET platform, there is also the occasional annoyance of having to fix a problem with the .NET framework on a user's machine.  Usually it all works pretty seamlessly, but occasionally something goes wrong.  Sometimes this happens right after a Windows Update is pushed out - other times, there is no apparent cause.  In any case, the problem typically presents itself to the user as though all of our in-house applications are broken.  Since all of the other applications that the users typically use (such as Outlook, Excel, etc.) still work just fine, they tend to look to us, the developers, to fix the problem.  Although Desktop Support is nominally responsible for things like the .NET framework, as a matter of practice, it behooves us developers to do something about it.

Such was the situation that presented itself to me today.  Usually the fix is fairly straightforward - remove the offending framework version and re-install it.  Today, however, there was an added wrinkle, which was that the Framework installer was failing with an "Access denied" error.  The user had Administrator privileges, so there shouldn't have been a problem there.  Rebooting (needless to say, one of the first things to be tried for any software-related problem) also didn't work in this case.  The Installer still wouldn't run.  Eventually, after casting around the Internet for a possible solution, I had the good fortune to come across a helpful blog post by Aaron Stebner.  Stebner's blog is full of genuinely helpful information for resolving a myriad of .NET-related headaches - suffice it to say that he is a god among men.  This time was no different, and after following his advice and using msconfig to disable some inessential startup services, the installer ran like a dream.  So it appears that a service was holding a lock on a particular file that the installer needed to write to.  Why this was still happening even after all versions of the .NET framework had supposedly been removed from the machine is a mystery for another day.

So, with the user's problem resolved, I returned to my desk to perform other lower priority tasks, such as actually writing software.  However, I soon got to thinking, wouldn't it be nice if there was a way to see exactly which process was holding a lock on the particular file that was giving the "Access Denied" error?  It might have helped to speed up the troubleshooting, and in any case, it would have been an interesting thing to know.  So after (a bit more) searching on the Internet, it turns out that there is just such a tool, and it is provided for free, by Microsoft no less.  The tool is called the Process Explorer, and you can download it here.  Let me tell you, this is a pretty slick little app.  I played around with it a bit, and I was suitably impressed by the ability to drill-down on all the processes running on my machine.  You can even search by a particular file name to see exactly which processes are locking it.  There's a lot more it can do too, but alas, I had to get back to my coding.