I'm sure to have to look this up again, largely care of:
http://social.technet.microsoft.com/Forums/windowsserver/en-US/504017c7-1a92-415e-b12c-03d44145e1db/how-to-find-which-process-locked-the-log-file?forum=winservergen
Process Explorer (ex Systernals) is good for troubleshooting/ resolving file locks.
You can download it from Microsoft http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx.
Use the icon that resembles a pair of binoculars... or use the Hotkey Ctrl+F(find).
Type the name of the file... it will show you which process is presently running and has locked the file for use.
You can then release the lock should you so wish.
In the case which prompted this quick post the issue was actually the locking level in use with log4net but maybe next time ... ;)
When I upgraded my main dev laptop from Win7 to Win8 (then 8.1) I had problems with ASP.NET under IIS. I put off sorting the issue out as I had IIS Express working adequately for development but this was never going to be a long term solution. Hopefully the issue arose due only to my upgrade path but it has come time to sort this out and surely this path must be fairly common?
My first issue was a HTTP Error 500.19 which http://stackoverflow.com/questions/12208209/iis-8-0-asp-net-and-error-500-19 helped with - as per one contributor
I tried running
aspnet_regiis.exe -i
But I instead received the message that this wasn't supported in this version of windows and that I should instead try one of: turning windows features on and off, the server management tool (N/A) or the dism.exe command line tool.
So in lieu of the command line option I next tried uninstalling and installing again (2.X and 4.X) - the thought did occur that this might be just an ASP.NET 3.5 problem, as that was the version of my test site. No joy. Next, brute force approach and I tried adding all features under ASP.NET under windows features. Still no joy. Then I happened across a response someway down in
http://stackoverflow.com/questions/3762287/script-not-served-by-static-file-handler-on-iis7-5 which referred to Windows 8 and hence possibly my problem as there was remarkably little from google on such Windows 8.X/ IIS 8.X issues. This referred to an additional 3.5 setting within Application Development Features. I had to google again as this is several levels down in the config:
Got there in the end and it worked for 3.5 though as I'd broken a few things along the way I'm not sure if I'm ready to try 4.X as well!
Microsoft sure don't make life easy sometimes!