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.
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.
The problem can be solved in one of the two following ways, depending on the requirements of your application and server:
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_MACHINESOFTWAREMicrosoftCOM3AutoDump (if AutoDump does not exists — please create that branch), add the following keys and their corresponding values (type DWORD):
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_ROOTAppId{<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.