A common question I see come up is someone working with ASP.NET tries to push a new deployment to their server but then sees errors from aspnet_compiler or during JIT which says that the compiler can not access certain files in either the web root or the Temporary ASP.NET Files.
Almost always this is caused by either not shutting down IIS before pushing large updates, or by not excluding your web root and Temporary ASP.NET directory from AntiVirus. If you’ve tried those things and are still having an issue, or you just really want to see what is causing the problem, Process Monitor can help make sense of it all.
Let’s use a simple example. I have an application which logs information to a file. Occasionally the logger dies that another process is using the file, and I’m rather confused why. I create the file, and as far as I know no one else is using it. My code looks like:
static void Main(string[] args)
{
FileInfo info =
new FileInfo(@”C:\logger\logfile.txt”);
try
{
using (StreamWriter writer = info.AppendText())
{
writer.WriteLine(“Hello, World”);
writer.Flush();
System.Threading.Thread.Sleep(10000);
}
Console.WriteLine(“Finished write”);
System.Threading.Thread.Sleep(10000);
using (StreamWriter writer = info.AppendText())
{
writer.WriteLine(“Goodbye, World”);
}
}
catch (Exception ex)
{
Console.WriteLine(ex.ToString());
}
Console.WriteLine(“All Done”);
}
As simple as this code is, I still see:
C:\logger>FileLockSpike.exe
Finished write
System.IO.IOException: The process cannot access the file ‘C:\logger\logfile.txt
‘ because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, I
nt32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions o
ptions, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access,
FileShare share, Int32 bufferSize, FileOptions options)
at System.IO.StreamWriter.CreateFile(String path, Boolean append)
at System.IO.StreamWriter..ctor(String path, Boolean append, Encoding encodin
g, Int32 bufferSize)
at System.IO.StreamWriter..ctor(String path, Boolean append)
at System.IO.FileInfo.AppendText()
at FileLockSpike.Program.Main(String[] args)
All Done
So let’s track down why. First, I download and extract ProcessMonitor from the Microsoft Sysinternals site. It can be a little overwhelming at first – within 30 seconds of startup you see:
Yes – over 56,000 events. How will we ever find what we need? Luckily, we have a single file we can focus on – logfile.txt. So we can use Process Monitor’s filters to discard everything but interesting events that happen to it. We do that by going into Filter -> Filter… and adding an exclusion filter for anything that isn’t our path:
We should now see all the events go away, and a message that the current filter is excluding all events. So far, so good. So let’s fire up our logger and see what happens:
With our application running, we now see all of the file access calls happening in the event log. We can see that it’s all coming from our FileLockSpike.exe which looks good. Let’s keep watching and see what happens. Aha! We got the error:
So let’s see what Process Monitor says. That’s strange. There are two different processes – FileLockSpike.exe, and FileLockSpike.vshost.exe. And that right after FileLockSpike.vshost.exe does a CreateFile, we get the exception in our app:
Let’s double click on that vshost CreateFile line. This brings up the properties, and I can click over to the Process tab to see where it is coming from:
Interesting. It’s coming from my \Documents\Visual Studio 2005\Projects\FileLockSpike\bin\Debug\ folder. And since the only thing I was doing at the time was debugging a new version of the logger application…
Well, that’s a bit contrived. It’s also what I get for hardcoding a path into my application. But Process Monitor is definately a valuable tool for tracking down what the heck is going on with your files and your system, and it is great fun just to watch what happens when you start up various things.
Happy monitoring!