Last time I covered how to use Network Monitor and Fiddler to troubleshoot authentication issue with ASP .NET. This month I�ll cover troubleshooting file-access problems using Sysinternals�s Filemon, a tool that is available free from Sysinternals's Web site:
Here�s the scenario we�re troubleshooting.
Scenario
When users browse to your ASP.NET application, they see your custom error page. You aren�t sure what the error is, but you know that your application is writing data to a file with the details of the exception. Unfortunately, when you check for the file, it�s not there.
Whenever I have written an application that should be writing information to a file and nothing gets written to the file when it should, I assume a permissions problem. There are many ways that you can check permissions. You could just open up the Windows interface and look at the permissions there. The downfall to that method is that you are really only seeing the permissions for the specific object you are examining. If that object is a folder, the permissions may be correct at the folder level and wrong on a file within that folder.
Another way to monitor permissions is to audit object access. Auditing works great if you want to take the time to set it up. However, in the scenario we are working with in this article, there is a much easier way to tell if a permissions problem is preventing our user from accessing the file system: Filemon.
When you download Filemon from Sysinternals, you�ll get a small .zip file containing three files, one of which is Filemon.exe. That�s the only file you need to use Filemon, so unzip that file to your desktop or some other convenient location. Double-click
Filemon.exe to start Filemon. Once you start Filemon, you�ll see it start to fill up quickly with data, as shown in the following image.
When most people start Filemon for the first time, their immediate reaction is �Boy, this is a lot of stuff!� The next words out of their mouth are almost always, �I sure hope you guys have some internal tool that makes this stuff easy to analyze.� In fact, we do. It�s called Microsoft Excel! More on that later.
What Filemon Does
Filemon logs all file access on your computer. It logs the process that is accessing the file, the type of access that is requested, the path and file name of the file accessed, the result of that file access, and other information of interest. In most cases, the default Filemon settings are sufficient, but if you explore the interface, you�ll find that Filemon includes some powerful configuration options.
The trick to using Filemon for troubleshooting a permissions problem is to try and capture the least amount of data necessary and still capture the problem. You can do that easily using CTRL+E, a keyboard combination that toggles Filemon�s capture mode on and off. After you�ve started Filemon, press CTRL+E to stop it, and then press CTRL+X, which will clear the output window. Now you are ready to capture the file access problem.
Here�s how you would capture a Filemon log.
- Copy Filemon.exe to the Web server.
- Have a user prepare to request the page. Make sure that they wait to actually request it until you�ve started Filemon.
- Press CTRL+E in Filemon to start capturing. Once again, make sure that you have cleared the window first with CTRL+X.
- Ask the user to request the page.
- Once the user reports that they have seen the error, press CTRL+E to stop Filemon.
- If you intend to analyze the log in another application, like Excel, click Save on the File menu to save the log.
Now that you have a Filemon log captured, you are ready to review it and see if permissions are preventing the ASP .NET worker process from launching. You can review the log in Filemon itself, and in some cases, that�s the easiest method. However, if there is a lot of information in the capture, Excel is a great way to analyze the log. If you want to analyze the log in Excel, simply open the log file and use Excel�s filtering capabilities to search for errors.
Analyzing Data in Filemon
If you choose to analyze the data in Filemon, you might want to use Filemon�s highlighting feature to make it easier to detect a failure. On the
Options menu in Filemon, click
Filter, click
Highlight, and then type
ACCESS DENIED in the
Highlight textbox, as shown in the following image.
After configuring this highlight setting, any line that resulted in an Access Denied message will be highlighted in red. You can now quickly scroll through the Filemon log and attempt to identify where the failure was, as shown in the following image.
In this example, we can see that the local ASPNET account was denied access when trying to create a file in the C:\Inetpub\Wwwroot folder. Checking the file permissions at that location did in fact reveal that the ASPNET account did not have write access.
This is a good example of a common scenario that we see in Microsoft Product Support Services (PSS). Some kind of exception has occurred, which has then called into your exception logging code. Your code is supposed to be logging exceptions in a text file, but when that happens, another exception occurs because the process account cannot create the logging file.
If you think about what happens next, you�ll see just how bad this is. You�ve just gotten yourself into infinite recursion, and the end result will almost certainly be a crash in the ASP.NET worker process due to a stack overflow. To make matters worse, none of your exception logging ever happened, so you are going to have a tough time tracking down what caused the crash when it occurs.
We see these issues often, and unless you understand how to do post-mortem debugging, you are likely going to make yourself bald trying to figure out what�s going on. Fortunately, we provide you with an extremely robust toolset for debugging an ASP .NET application post-mortem, and it just so happens that I�ll be covering that topic in next month's article!
I�ll see you back here next month when I�ll teach you how to use Windbg and the SOS extension to analyze crash dumps.