HTTP 500.x -- Internal Server Error Codes

Applies To: Windows Server 2003, Windows Server 2003 with SP1

Table 11.10   HTTP 500 Substatus Codes lists the most common 500 substatus codes returned by IIS. The descriptions for most substatus codes are self-explanatory. When additional information about a substatus code is required, it is provided in one of the following sections.

Table 11.10 HTTP 500 Substatus Codes

500.11 and 500.12-Application State Issues

Users rarely encounter 500.11 and 500.12 errors in their browser. These errors indicate that the ASP application to which the requested ASP page belongs is in the process of shutting down, restarting, or both. Restarts and shutdowns can be triggered directly from code when the built-in APIs available to ASP developers are used. Occasionally, these errors occur when the Global.asa file for the application (if one exists) is updated or altered in such a way that a file change notification is issued. Because IIS monitors for file change notifications on ASP content, IIS receives this notification, and because the file is the Global.asa file, IIS restarts the application.

If users often encounter these errors in their browser and you are certain that the code in the Global.asa file is not being updated, virus scanning and backup software, which sometimes sweep the ASP content and trigger a notification, might be causing these errors. For more information, see Microsoft Knowledge Base article 248013, Err Msg: HTTP Error 500-12 Application Restarting.

500.13-Web Server Too Busy

ASP requests are executed by threads from a pool of threads whose size is limited to 25 threads per processor, by default. If more ASP requests arrive than there are threads available to execute them, ASP places the extra requests in a queue, where they wait until a thread becomes available. By default, this queue is limited to 3000 requests. If the queue becomes full, the next ASP request, instead of being queued, causes a 500.13-Web server too busy error. The number of requests that can wait in the queue is controlled by the AspRequestQueueMax metabase property. Change the AspRequestQueueMax property to produce the desired user experience — a smaller queue allows users to more quickly see the 500.13 error when ASP requests are backed up.

If users encounter this error, select the Active Server Pages/Requests Queued performance counter check box. If the queue fills up, but ultimately empties again, or if the queue remains partially filled but requests move through very quickly, there probably is not a problem, just a spike in traffic. However, if the queue remains partially or completely full for a sustained period and requests do not appear to be moving through quickly enough, there might be a problem.

Diagnosing a problem of this type can be a complex process. For information about diagnosing such problems, see Advanced IIS Troubleshooting with Tracing and Debugging.

500.16-UNC Authorization Credentials Are Incorrect

Problems with content stored on remote file servers can be more complex than problems with locally stored content. The 500.16 error indicates that there is a specific configuration problem with remotely stored content. When IIS is configured to use specific credentials to access the UNC path in the metabase, it uses those credentials to open the content on the remote file server. To do this, IIS uses a Windows logon API to obtain a security token that it can use to impersonate a security identity when accessing the remotely stored content. If the call to the Windows logon API fails, indicating that there is a problem with the user name or password, IIS returns an HTTP 500.16 error.

500.17 and 500.18-IIS URL Authorization Issues

IIS URL Authorization is a security feature that is new in IIS 6.0. Among other administrative tasks, IIS URL Authorization configures the Authorization Manager store by setting the AzStoreName metabase property. This store can be an XML file or an LDAP location. It is configured by setting the AzStoreName property to an appropriate string that represents the path to a store. For example: msxml://c:\MyStore.xml or msldap://CN=MyAzStore, CN=Program Data, DC=MyDomain, DC=com.

The 500.17 and 500.18 errors pertain to problems accessing the Authorization Manager store. A 500.17 error indicates that the store could not be found. To begin troubleshooting one of these errors, try to verify the path specified in the string by either opening the XML file or testing the LDAP path with a simple client, such as LDP.exe. For more information about LDP.exe, in Help and Support Center for Windows Server 2003, click Tools, and then click Windows Support Tools.

A 500.18 error typically indicates that the store was found, but could not be opened. The error description might contain information such as an HRESULT and description. However, this error generally occurs because there is an ACL–related problem. The security context that is used to open the store is that of the worker process identity. To troubleshoot, verify that the configured worker process identity is a member of the built-in IIS_WPG group and that this group has access to the store. File Monitor is a good utility to use in such a case.

For more information about IIS URL Authorization, see URL Authorization in IIS 6.0.