COM+ average call duration

Home

Experience

Process

Experience - Process

Written by Mikhail Pakhantsov

Thursday, 18 February 2010 13:12

Serving on support duty, we received an issue report from our customer: some of the processes in I-Plan are silently failing — even though everything worked fine before. The first question any developer would ask in such case: what did you change? Turns out, they have installed SP2 on their Windows Server 2003, and this was the exact reason for this issue to appear. Read on to find out what causes it and how it can be solved.

The ever-changing Microsoft

On some reading, we find that Microsoft have changed the game rules in Service Pack 2 for Windows Server 2003. The functionality that supports automatic collection of process' dump files for COM+ was changed, and, as it turned out, there was also a change in the logic that completes processes exceeding a certain period of run time, as described in Knowledge Base article 910904: A change in the functionality of COM+ in Windows Server 2003 to support automatic collection of a process dump file and process termination.

All would be good if it led to gathering data and raised a corresponding warning, yet, unfortunately, a process that runs for an "unusually high time" is terminated, while the event type is a mere "Warning":

Event Type: Warning
Event Source: COM+
Event Category: (117)
Event ID: 1001
Date: dd.mm.yyyy
Time: HH:MM:SS
User: N/A
Computer:
Description: The average call duration has exceeded 10 minutes. If this is not the expected behavior, please see article 910904 in the Microsoft Knowledge Base at http://support.microsoft.com for details on how to use the COM+ AutoDump feature to automatically generate dump files and/or terminate the process if the problem occurs again.
Server Application ID: {...........}
Server Application Instance ID: {...........}
Server Application Name: I-Plan

Of course, we know which processes in our application take longer than 10 minutes, and we know what causes it, so we didn't need such a "gift" from Microsoft.

Solution

The problem can be solved in one of the two following ways, depending on the requirements of your application and server:

1. Global change to COM+ behavior

Make the following changes in your system registry (please be careful when modifying the registry, it is not a joke that one can easily break Windows by mis-doing something here):

In the registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3\AutoDump (if AutoDump does not exists — please create that branch), add the following keys and their corresponding values (type DWORD):

AverageCallThreshold, set to 3000, — this is maximum allowed duration of process execution, in seconds. If it is exceeded, a warning is raised.
Terminate, set to 0, — this flag defines behavior on exceeding maximum execution time, 0 means that the process will continue, 1 means that the process will be terminated.
DumpType, set to 2, — this flag defines the dump creation behavior, 0 means that a full dump file will be generated, 1 that a minidump file will be generated, 2 defines that no dump file is to be generated.

2. Change behavior of a specific COM+ application

In order to change the behavior of a specific COM+ application, instead of making a global server-wide change, create the above keys and values in the following registry path: HKEY_CLASSES_ROOT\AppId\{<YourAppID>}\AutoDump\{<YourCLSID>}.

It is preferable not to set the AverageCallThreshold to be too high, and simply allow the process to continue. At least this way you will be able to collect enough statistics about potential problem spots, and when they appear — to, possibly, try to solve high execution times if they are not needed for your application's business logic.

PS If it is so easy for Microsoft to change the logic in their server OSes, wouldn't it be even easier to stop "supporting" the old bugs from Internet Explorer 6 in the more recent IE versions? Just asking.