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

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

Comments

• Anonymous
  May 31, 2013
  THANK YOU.  My IIS got similarly discombobulated when, after setup of client certs failed, I needed to turn on FRT.  I would add there is a similar problem with root / branch collision on the cert set up.  If you try to set up certs anywhere but the root (which it lets you do), you end up with ultra-headaches.  As a side note.  If MSFT wants to survive, these issues should be addressed rather than letting them ride on indefinitely.
• Anonymous
  April 11, 2014
  Thanks! This solved my issue.
• Anonymous
  January 27, 2015
  Nice fix.  We have this distributed setup with a personal directory elsewhere and I could see that on the error page a "?" was in the directory where it was trying to find the config file.  Adding that Remove worked perfectly.
• Anonymous
  May 03, 2016
  Thanks..this helped me solve my issue