500.19 Internal Server Error after Enabling Failed Request Tracing in IIS 7.5

  • Article

Recently had this issue with a customer where their IIS 7.5 server was serving content just fine, however they had a requirement to implement failed request tracing. After setting up the failed request tracing rule and enabling it at the site level they found that content in a sub vdir folder was returning a 500 error. When disabling the failed request tracing, then the issue no longer occurred. 

 

So what was happening? Well as a first step, we enabled detailed error messages and reproduced the issue. We found that the error was an HTTP 500.19 Internal server error as below.

 

 

 

From the config error highlighted, it looks pretty straight forward as we can see the error message is

“Cannot add duplicate collection entry of type ‘add’ with unique key attribute ‘path’ set to ‘*’”.

 

Clearly looks like this failed request trace is trying to add a collection element already defined at the parent, and basically, the config system isn't designed to handle this gracefully and returns a 500.19 error.

 

In the customer scenario they had their root site, and sub applications and virtual directories about 7 levels deep. However from the error message it shows the problem web.config path is at the wwwroot. To be safe, we checked each of the 7 levels for child or parent web.config files, however we only have the single web.config file at the wwwroot. Checking and confirmed there are no tracing rules defined in the applicationHost.config. 

 

So what is the problem? When checking the customer environment found their root site was pointing to C:\inetpub\wwwroot\. However they had an application under this site set to point to the exact same location c:\inetpub\wwwroot. Similar to the screenshot below:

 

 

In this sense even though it is the exact same, single web.config file.. because of the setup of the root site and sub application both pointing to the same folder path, the web.config failed request tracing rules are read in first at the site level and then read in again at the application level causing the duplicated collection entry error we saw in the 500.19 error above.

 

The workaround is to edit the single web.config file and add a <remove path=”*” /> entry right before the <add path=”*”> entry so when the “child” web.config file is read in, the previous rules are cleared allowing the subsequent trace rules without having a duplicated entry created.

 

        <tracing>

            <traceFailedRequests>

                <remove path="*" />

                <add path="*">

                    <traceAreas>

                        <add provider="ASP" verbosity="Verbose" />

                        <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />

                        <add provider="ISAPI Extension" verbosity="Verbose" />

<add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module,FastCGI,Rewrite" verbosity="Verbose" />

                    </traceAreas>

                    <failureDefinitions statusCodes="200-900" />

                </add>

            </traceFailedRequests>

        </tracing>

 

Thanks,

 

Matt from APGC DSI team