Guest Post: The Case of the FrontPage Error

Welcome to the first guest "Case Of" blog post! I've received numerous great troubleshooting cases over the last two months and have selected this one, submitted by Troy Wolbrink, a corporate web master, as the first to share with you.


Troy ran into a problem with his web server and instead of rebooting, reinstalling, or calling Microsoft Product Support Services (who would have undoubtedly suggested the same steps Troy followed on his own, but cost Troy an incident), he used basic troubleshooting techniques to solve it in a few minutes. Like for everyone else that's submitted a well-documented case with screenshots and log files, I sent Troy a signed copy of Windows Internals as a thanks.


I'm including some of the cases I've received in my "Case of the Unexplained..." talk again at TechEd/IT Pro in June. In fact, even if you've watched the webcast from last November's TechEd/ITForum, be sure to come to the session as it consists of entirely new new cases.


Before I present the case, I want to share a clever user-produced video that serves as both a tutorial and demonstration of Zoomit, a screen magnifier and annotation tool I developed as an aid for my presentations. You can find the video here.


Enjoy Troy's post and the Zoomit video and please keep submitting your troubleshooting cases!




The Case of the FrontPage Error

by Windows Detective Troy Wolbrink

I recently transitioned my website from shared hosting to my own dedicated server. Parts of my website were using FrontPage Server Extensions (FPSE), such as the page which collected data and logged the results to a text file:


I installed FPSE using the Add/Remove Windows Components control panel applet, and then I did my best to configure them correctly with IIS. But for some reason I could not get FPSE configured correctly such that my data collection form would work. The error message from the browser was very vague:


I looked for more information in the Event Log on the server, but it had nothing relevant.

My plan was to eventually replace this site with one built on ASP.NET and SQL Server, so I wasn’t feeling motivated to become a FPSE expert just to solve this one problem. But since other priorities are preventing this move to ASP.NET from happening for another year, so I had no choice but to investigate. I had just seen Mark’s talk on “The Case of the Unexplained...”, and I was inspired to run Process Monitor on my server to see if any clues to the problem might appear. I excluded events from some obvious processes that had nothing to do with the problem. This removed a lot of the noise. Since my web page was “TntWebLog.htm” and since it was writing to “TntWebLog.csv” I configured it to highlight anything with a Path containing “TntWebLog”.

To reproduce the problem, I pulled up my web browser and tried to submit the form. Then back in Process Monitor I told it to stop capturing events. I then scrolled down through the list looking for highlighted entries. It was astonishing how quickly I found the problem. FPSE was trying to create the file with the same name as the existing file:


Obviously something was up with file permissions here. I checked the file permissions for TntWebLog.csv and it didn’t have a listing for the IUSR_WEBBOARD account which is what is configured in IIS for anonymous access:



So I clicked Advanced, checked the box for “Allow inheritable permissions from the parent to propagate…” and clicked “OK”:


Doing this caused the proper security permissions to be configured for the file. I ran another test and the problem was solved!

Looking back I believe that this problem occurred because I used Windows Explorer to “Move” and not “Copy” the csv file into place. I did some more tests to confirm this. When you “Move” a file within the same volume using Windows Explorer, the file permissions are moved with it. When you “Copy” a file using Windows Explorer, it creates a new file that inherits permissions from the target folder. If I had originally performed a “Copy” this problem would have never happened.

Now my first reaction to unexplained problems will be to run Process Monitor and see what’s going on under the hood!


-Troy Wolbrink