Hello again and welcome to the December '04 edition of the Support Voice Column. Once again, I would like to thank Jim Cheshire, a support engineer here at Microsoft supporting ASP .NET, for his contributions. Jim has great ideas for the Support Voice column and wanted to continue to share them. Look for Jim's contributions last month and over the next month or so, and as always, send us your suggestions for future columns. Thank you Jim!

Jim has been working with Microsoft for six years on the FrontPage, VB, and ASP .NET teams. During that time, he has written for the Office Developer Center on MSDN, and he is the author of a book on FrontPage, Special Edition Using Microsoft Office FrontPage 2003. Jim also has a Web site where he provides free add-ins for FrontPage to enable Web developers to make the most out of Microsoft products. Here is that website address:
So please pull up a chair, kick the shoes off, and read through our column all about Troubleshooting ASP .NET ,and remember, you can submit your ideas to us using the "ASK FOR IT" link included in every column we publish.

Jeremy

Back to the top

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.

Back to the top

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.

Back to the top

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.

1.	Copy Filemon.exe to the Web server.
2.	Have a user prepare to request the page. Make sure that they wait to actually request it until you’ve started Filemon.
3.	Press CTRL+E in Filemon to start capturing. Once again, make sure that you have cleared the window first with CTRL+X.
4.	Ask the user to request the page.
5.	Once the user reports that they have seen the error, press CTRL+E to stop Filemon.
6.	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.

Back to the top

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.

Back to the top

Until next time,
Jim Cheshire
Support Engineer
Microsoft Developer Support

As always, feel free to submit ideas on topics you want addressed in future columns or in the Knowledge Base, using the Ask For It (http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p 2=&p3=&p4=) form.

Back to the top