Bug Story: IIS 7.0

Kevin Beto

Microsoft Corporation

April 2008

Summary: A story about troubleshooting a bug that didn't manifest itself until tested on IIS 7.0. (1 printed page)

Overview

The ship date for Microsoft Windows Server 2008—formerly codenamed "Longhorn"—was to set down near the ship date of our own application. Any time that a monster release such as that one touches down near you (plus or minus a few months), you pretty much are bound to support it in some form.

Our application—a set of Web services on a database—deployed just fine. (Well, that's not exactly true. It took about two months of figuring out which settings had to be set for it to work properly; but that is a different and much longer bug story.) The problem that I was running into was that the sample data for our application didn't deploy successfully. I was really confused, because I was able to do an end-to-end scenario just fine by hand, so that it wasn't a problem with the product itself; however, this would be a problem for marketing folks who wanted to use our samples, so that it had to be investigated.

The error that I was getting was a strange one: "An unexpected error closed down the database connection." This was occurring rather consistently in the same spot. However, the code wasn't doing anything weird that I would expect to have caused this. Plus, the error was coming from the server, so that I didn't expect that the client code was doing anything out of the ordinary here.

After finding the developer, and convincing him that debugging the problem would be a good idea (not easy to do, because he didn't think that we were going to support Windows Server 2008), he showed me the exact place in which the problem was happening. We were doing a bunch of things to a bunch of objects—whether or not they existed—and catching a particular exception if the object didn't exist, and ignoring it.

It appeared that the expected exception wasn't being thrown, because we were getting this other one. To address my problem, the developer told me to fix the error that I was getting in SQL.

At this point, I had a theory: I know that Windows Server 2008 has a lot of security fixes; so, perhaps it was obscuring the same error message on purpose. A colleague of mine sent an e-mail to some friends that he had in the Microsoft Internet Information Services (IIS) group, and my theory was confirmed.

The solution was to execute the following command to revert back to the same behavior that we were seeing with IIS 6.0:

appcmd set config –section:httpErrors –existingResponse:PassThrough

Of course, the proper solution is probably not to do things that cause exceptions in the first place; but we'll save that for our first service pack.

About the author

Kevin Beto is currently a test lead on Microsoft Office Performance Point™ Server 2007.