You can configure ADPlus from the command line. However, entering a complicated configuration from the command line is often inconvenient and sometimes not possible. Configuration files can save the day. You can enter in complicated configurations and save them for future reuse. Configuring ADPlus properly may be a challenge for administrators, testers, or support engineers. Developers can now configure ADPlus in a configuration file that is provided to non-technical staff. Finally, the configuration file extends the behavior of the command line. Conditional statements are just one example of an option available in the configuration file that is not available from the command line.

Here is a sample ADPlus configuration file:

<adplus>
  <settings>
      <runmode>crash</runmode>
      <option>quiet</option>
      <outputdir>c:dumps</outputdir>
  </settings>
  <precommands>
      <cmd>.loadby sos mscorwks</cmd>
      <cmd>!eeversion</cmd>
  </precommands>
  <exceptions>
      <option>nodumponfirstchance</option>
      <config>
          <code>dz</code>
          <actions1>log;stack;eventlog</actions1>
          <customactions1>dd ebp</customactions1>
       </config>
       <config>
           <code>clr</code>
           <actions1>log;stack;eventlog</actions1>
           <customactions1>!stoponexception system.accessviolationexception 1;
               .if(@$t1==1){.dump /ma c:\dumps\mydump.dmp }
           </customactions1>
      </config>
  </exceptions>
</adplus>

Let us examine the above configuration file:

The perfect application does not exist. Historically, applications have been short run. You start an application, perform a discrete task, and then shut down the program. The application is restarted for the next task. In this scenario, the program does not execute long enough for problems to accumulate. For example, memory leaks do not have time to accumulate and potentially crash the program. However, the paradigm has changed with Web applications. Web applications run for an extended period of time—several days and even months. Small problems that were inconsequential before can accumulate and become a considerable issue. For this reason, the ASP.NET worker process may be recycled. Proactive recycling recycles an otherwise healthy application. This will periodically give you a fresh worker process to handle future requests. This is helpful in preventing denial of service attacks on a Web server. For example, the worker process can recycle after a specified number of requests. Reactive recycling recycles the worker process when a problem occurs. For example, the worker process can be recycled when memory exceeds a set threshold.

When the worker process recycles, current requests are completed by the active worker process. A new worker process is started that handles future requests. The old worker process exits after handling the final request. The recycling of the worker process is then reported in the event log. You can always check the event log to determine if the worker process has been recycled and the reason for it.

For IIS 6.0, worker process recycling is controlled by the processModel tag in the web.config file. The processModel tag is allowed solely in the root web.config file. In addition, the allowDefinition attribute of the tag must be set to Everywhere. 9-3 lists some of the relevant attributes.

For IIS 7, you configure worker process recycling through the application pool. First, start IIS 7.0. Open the context menu for a specific application pool. Select Recycling. The Edit Application Pool Recycling Settings window will open. Select the appropriate recycling options, and enter parameters in the related text box. See 9-8.

Figure 9-8. Edit Application Pool Recycling Settings window for configuring recycling of the worker process.

When a worker process recycles, that is usually, but not always, an indication of a problem. Getting a dump at the moment would be useful for post-mortem analysis. You can use ADPlus to create a dump when the worker process is recycled. The following ADPlus configuration file accomplishes this task. The ExitProcess function is called just before the worker process is recycled. You can set a breakpoint on that function and create a dump at that very moment.

<ADPlus>
    <Settings>

        <RunMode>crash</RunMode>
    </Settings>
    <Breakpoints>
        <NewBP>
            <Address>kernel32!ExitProcess</Address>
            <Type>bp</Type>
            <Actions>FullDump</Actions>
            <ReturnAction>G</ReturnAction>
        </NewBP>
    </Breakpoints>
</ADPlus>

Here are the specifics pertaining to the configuration file.