Event ID 1003 with ASP.NET Deadlock

When you experience a deadlock in ASP.NET, the following event may be logged in the Application event log:

A supported fix is now available from Microsoft, but it is only intended to correct the problem that is described in this article. Apply it only to computers that are experiencing this specific problem. This fix may receive additional testing. Therefore, if you are not severely affected by this problem, Microsoft recommends that you wait for the next .NET Framework service pack that contains this fix.

To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information about support costs, visit the following Microsoft Web site:NOTE: In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The typical support costs will apply to additional support questions and issues that do not qualify for the specific update in question.

NOTE: This hotfix does not resolve deadlocks; this hotfix only provides instrumentation to troubleshoot and to diagnose deadlocks. For more information about how to use this hotfix to troubleshoot and to diagnose deadlocks, see the "More Information" section of this article. The English version of this fix has the file attributes (or later) that are listed in the following table. The dates and times for these files are listed in coordinated universal time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time tool in Control Panel.

Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article.

After you install this hotfix, the native debugger can break in on the process when a deadlock occurs. This hotfix adds instrumentation to call the DebugBreak function when a deadlock occurs in the ASP.NET worker process (Aspnet_wp.exe). The following registry key instructs ASP.NET what to do when a deadlock occurs:

• DebugOnDeadlock = 0 (no break)
• DebugOnDeadlock = 1 (Break into Aspnet_wp.exe only)
• DebugOnDeadlock = 2 (Break into Aspnet_wp.exe and Inetinfo.exe)

The ASP.NET deadlock detection is automatically disabled when a native debugger is attached to the ASP.NET worker process (Aspnet_wp.exe). However, it is helpful to obtain a dump file before the process recycles. To have a debugger attached and to still have deadlock detection enabled, you must set the following registry key to the appropriate value:

• UnderDebugger = 0 (Debugger can be attached, and process can be recycled)
• UnderDebugger = 1 (Debugger can be attached and stops process from recycling)

NOTE: When you finish debugging, Microsoft recommends that you delete these registry entries.

Generate Dump Files for Diagnosis

To troubleshoot and to diagnose a deadlock, you must generate a dump file of the Aspnet_wp.exe process, the Inetinfo.exe process, or both processes immediately before the Aspnet_wp.exe process is recycled. With the instrumentation that is added to ASP.NET, you can determine when this occurs. After dump files are generated, you can analyze these dump files to determine the cause of the deadlock.

To generate dump files, follow these steps:

1. Install this hotfix, or make sure that you have a later version on the computer that experiences the deadlock behavior.
2. If the native debuggers are not already installed on the computer, install the debugging tools. To download the debugging tools, visit the following Microsoft Web site:
   http://www.microsoft.com/whdc/devtools/ddk/default.mspx (http://www.microsoft.com/whdc/devtools/ddk/default.mspx)
3. Follow the steps in the "Modify the Registry" section to add a new DWORD registry entry that is named UnderDebugger under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET registry subkey, and then set the value of UnderDebugger to 0.
4. Follow the steps in the "Modify the Registry" section to add a new DWORD registry entry that is named DebugOnDeadlock under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET registry subkey, and then set the value of DebugOnDeadlock to 0.
5. In the directory in which the native debuggers were installed (the default location is C:\Program Files\Debugging Tools For Windows), locate the ADPlus.vbs file.
   
   Depending on the version of ADPlus that you have, you may have to put this constant in the ADPlus.vbs file. At a command prompt, locate the directory where you installed the debuggers. Run the following command at the command prompt:
   ADPlus.vbs -HELP
   If the -CTCFG switch does not exist, add the following constant:

   Const Full_Dump_on_CONTRL_C = TRUE

   If the -CTCFG switch does exist, use that switch at the command prompt.
6. At a command prompt, change directories to the debugging tools directory, and then run one of the following commands:
   
   NOTE: Make sure that you change the path to the path that you want the files to be created in.
   • To attach to the ASP.NET worker process (Aspnet_wp.exe) only, run the following command:
     adplus.vbs -crash -pn aspnet_wp.exe -o c:\Path_to_Put_Files_in
   • To attach to the Inetinfo.exe and the Aspnet_wp.exe processes, run the following command:
     adplus.vbs -crash -pn inetinfo.exe -pn aspnet_wp.exe -o c:\Path_to_Put_Files_in
   NOTE: Make sure that the Aspnet_wp.exe process is started before you run either of these commands.
   
   NOTE: If you are running ADPlus.vbs through Terminal Server, click the article number below to view the article in the Microsoft Knowledge Base:
   323478  (http://support.microsoft.com/kb/323478/EN-US/ ) PRB: You Cannot Debug Through a Terminal Server Session
7. Set the DebugOnDeadlock registry entry to one of the following values:
   • DebugOnDeadlock = 1 (Break into Aspnet_wp.exe only)
   • DebugOnDeadlock = 2 (Break into Aspnet_wp.exe and Inetinfo.exe)
   
   
   
8. When a deadlock occurs, notice that dump files are created automatically, and that the processes that were attached are restarted.
9. After the deadlock occurs, delete the UnderDebugger and the DebugOnDeadlock registry entries. If you do not delete these registry entries, you may receive an error message the next time that a deadlock occurs.

Modify the Registry

WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

To add the UnderDebugger DWORD value, follow these steps:

1. Start Registry Editor.
2. Locate and then click the ASP.NET value under the following subkey in the registry:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
3. On the Edit menu, click DWORD, type UnderDebugger, and then click OK.
4. Double-click UnderDebugger, and then change the data value to 0 or 1.
5. Quit Registry Editor.

To add the DebugOnDeadlock DWORD value, follow these steps:

1. Start Registry Editor.
2. Locate and then click the ASP.NET value under the following subkey in the registry:
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
3. On the Edit menu, click DWORD, type DebugOnDeadlock, and then click OK.
4. Double-click DebugOnDeadlock, and then change the data value to 0, 1, or 2.
5. Quit Registry Editor.