Microsoft KB Archive/298014

= FIX: A COM+ application that uses the global interface table (GIT) may deadlock =

Article ID: 298014

Article Last Modified on 12/5/2007

-

APPLIES TO

 Microsoft COM+ 1.0, when used with:  Microsoft Windows 2000 Service Pack 1

 Microsoft Windows 2000 Service Pack 1

 Microsoft Windows 2000 Advanced Server

 Microsoft Windows 2000 Service Pack 2</li></ul>

 Microsoft Windows 2000 Service Pack 2</li></ul>

 Microsoft Windows 2000 Advanced Server</li></ul>

 Microsoft Windows XP Home Edition</li></ul>

 Microsoft Windows XP Professional</li></ul> </li> Microsoft COM+ 1.5, when used with:  Microsoft Windows 2000 Service Pack 1</li></ul>

 Microsoft Windows 2000 Service Pack 1</li></ul>

 Microsoft Windows 2000 Advanced Server</li></ul>

 <li>Microsoft Windows 2000 Service Pack 2</li></ul>

<ul> <li>Microsoft Windows 2000 Service Pack 2</li></ul>

<ul> <li>Microsoft Windows 2000 Advanced Server</li></ul>

<ul> <li>Microsoft Windows XP Home Edition</li></ul>

<ul> <li>Microsoft Windows XP Professional</li></ul> </li></ul>

-

<div class="notice_section">

This article was previously published under Q298014

<div class="notice_section">

Important This article contains information about how to modify the registry. Make sure to back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For more information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows registry

<div class="symptoms_section">

SYMPTOMS
A COM+ process may appear to stop responding (hang). This specific issue is rare. You must debug the application to fully diagnose the issue. If you experience this issue, multiple threads in the process show call stacks that involve access to the global interface table (GIT).

You do not have to access the GIT explicitly in your code to experience this issue. Some other component that you use can access the GIT.

<div class="cause_section">

CAUSE
This issue may occur if one of the following conditions is true:
 * You use COM+ synchronized activities and the JScript components.
 * You use JScript explicitly. For example, you use Windows Script Components (WSC) in a COM+ application.
 * You use JScript indirectly. For example, the Microsoft XML (MSXML) parser uses JScript to perform an XSL transform.
 * You use COM+ components that are written by using managed code, such as Visual C# or Visual Basic .NET. Also, you do not explicitly call the Dispose method on these objects in versions of Microsoft Windows earlier than Microsoft Windows Server 2003.

<div class="resolution_section">

RESOLUTION
Note
 * COM+ applications that use Microsoft .NET System.EnterpriseServices.ServicedComponent objects are also known as managed COM+ applications.
 * COM+ applications that do not use Microsoft .NET System.EnterpriseServices.ServicedComponent objects are also known as unmanaged COM+ applications.

If you experience this issue in COM+ applications that use Microsoft .NET System.EnterpriseServices.ServicedComponent objects, make sure that the client code calls the Dispose method on every ServicedComponent instance. The correct approach is the systematic use of the Dispose method by the client of the ServicedComponent objects to enable deterministic cleanup. All client applications are required to call the Dispose method on all ServicedComponent instances, even unmanaged COM client applications.

If you experience this problem in COM+ applications that do not use Microsoft .NET System.EnterpriseServices.ServicedComponent objects, you can use a registry value that is named GipActivityBypass to resolve the problem. To use this registry value on Microsoft Windows 2000, you must first either install Windows 2000 Service Pack 3 or obtain Microsoft COM+ Hotfix Rollup 18.1.

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

313582 Availability of Windows 2000 Post-Service Pack 2 COM+ Hotfix Rollup Package 18.1

To resolve this problem, obtain the latest service pack for Windows 2000. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

260910 How to obtain the latest Windows 2000 service pack

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

To enable the fix on Windows 2000 or on Windows XP, you must create this additional registry value:

To do this, follow these steps: <ol> <li>Start Registry Editor.</li> <li>Locate and then click the following key in the registry:

</li> <li>On the Edit menu, point to New, and then click DWORD Value.</li> <li>Type GipActivityBypass, and then press ENTER.</li> <li>On the Edit menu, click Modify.</li> <li>Type 1, and then click OK.</li></ol>

If this registry value is not present, the assumed value is zero (False). Therefore, the GIT code must wait to enter the COM+ activity. This behavior could cause a deadlock condition. A non-zero value (True) as shown enables the new behavior, and then avoids the deadlock condition.

Note This registry value will enable calls to the GetInterfaceFromGlobal method to pass through the activity lock. If an unmanaged COM+ application experiences deadlocks when it calls the RevokeInterfaceFromGlobal method or the RegisterInterfaceInGlobal method, contact Microsoft Support.

<div class="workaround_section">

WORKAROUND
If you experience this problem in managed COM+ applications, you can apply the hotfix that is described in the following Microsoft Knowledge Base article as a temporary workaround:

875503 FIX: Slow performance, deadlocks, and memory leaks may occur when applications do not call the Dispose method on all instances of the ServicedComponent class in the .NET Framework

Alternatively, as a temporary workaround, you can use a registry value that is named DisableAsyncFinalization.

Note You should only use the DisableAsyncFinalization registry value as a temporary workaround while you are implementing the solution that is mentioned in the &quot;Resolution&quot; section. If you rely on the DisableAsyncFinalization registry value and you do not use the Dispose method, you will experience increased memory usage, decreased performance, and possible failure of the application.

To create the  registry value on Windows XP or on Windows 2000, follow these steps: <ol> <li>Start Registry Editor.</li> <li>Locate and then click the following key in the registry:

Note If you do not find the  key under COM3, create the registry key. To do this, follow these steps: <ol style="list-style-type: lower-alpha;"> <li>On the Edit menu, point to New, and then click Key.</li> <li>Type System.EnterpriseServices, and then press ENTER.</li></ol> </li> <li>On the Edit menu, point to New, and then click DWORD Value.</li> <li>Type DisableAsyncFinalization, and then press ENTER.</li> <li>On the Edit menu, click Modify.</li> <li>Type 1 in the Value data box, and then click OK.</li></ol>

<div class="status_section">

STATUS
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the &quot;Applies to&quot; section. This problem was first corrected in Windows 2000 Service Pack 3.

<div class="moreinformation_section">

MORE INFORMATION
In the following example, the call stack shows a JScript garbage collector that tries to retrieve an interface from the global interface table. Note the frame that contains ole32!CGIPTable::GetInterfaceFromGlobal. <pre class="fixed_text">02c3c2d0 77e8366e 00000002 02c3c2f8 00000001 ntdll!_ZwWaitForMultipleObjects@20+0xb 02c3c320 77e260f8 02c3c2f8 00000001 00000000 KERNEL32!WaitForMultipleObjectsEx+0xea 02c3c37c 68fd46f5 02c3c348 06180fd0 ffffffff USER32!MsgWaitForMultipleObjectsEx+0x153 02c3c3a4 68fd5b64 06180fd0 00000001 02c3c404 ole32!CCliModalLoop::BlockFn+0xf8 02c3c408 695378bc 00079048 ffffffff 00000001 ole32!CoWaitForMultipleHandles+0xe1 02c3c464 69537544 06180fa0 00000001 02c3c758 COMSVCS!?EnterActivity@CActivity@@UAGJHPAUICall@@@Z+0x1be 02c3c474 68fd21f7 06180f90 02c3c758 02c3c7b8 COMSVCS!?Enter@CActivity@@UAGJPAUICall@@@Z+0x14 02c3c4ac 68fd1f78 00000020 00000002 00000001 ole32!CPolicySet::DeliverEvents+0x1f6 02c3c538 68fc8d8e 02c3c758 00000002 02c3c7b8 ole32!CPolicySet::Notify+0x455 02c3c788 68fc8b18 02c3c878 1267104c 68fd9d69 ole32!EnterForCallback+0xe7 02c3c8a8 68fc89f3 1267104c 68fd9d69 0000f024 ole32!SwitchForCallback+0xfb 02c3c8d8 68fcf3fc 1267104c 68fd9d69 0000f024 ole32!PerformCallback+0x70 02c3c934 68fd9eab 00a31e68 68fd9d69 0000f024 ole32!CObjectContext::InternalContextCallback+0x10c 02c3c97c 6b745897 6909a990 0000f024 6b76f888 ole32!CGIPTable::GetInterfaceFromGlobal+0xc1 02c3c9a0 6b7456a0 00000000 00000002 0a5abfb0 jscript!GcContext::CallInContext+0x20 02c3c9c4 6b704f1a 00000002 00000194 0a5ff530 jscript!GcContext::Reclaim+0xba 02c3c9dc 6b729eb8 0a608d88 0a62c008 6b729cae jscript!GcContext::Collect+0xbe 02c3c9e8 6b729cae 77e8357b 0a5ff648 6b72a08e jscript!GcContext::ExhaustiveCollect+0x1a 02c3ca08 6b7329bf 0a5ff530 00000001 0a608d88 jscript!CSession::Close+0x12c 02c3ca18 682fb8f4 0a5ff530 00000000 0a608d88 jscript!COleScript::SetScriptState+0x105 02c3ca28 682fb6b8 0a5cfed8 682fea19 02c3ccac scrobj!ScriptEngine::Close+0x14 02c3ca30 682fea19 02c3ccac 0a5cfed4 00000000 scrobj!ScriptEngine::~ScriptEngine+0x8 02c3ca44 682fe778 127b0fa0 02c3d4ac 00400000 scrobj!ComScriptlet::Inner::~Inner+0x79 02c3ca54 6830562d 0a5cfed0 7c0183c2 0a5e38b0 scrobj!ComScriptlet::Release+0x28 02c3ca5c 7c0183c2 0a5e38b0 68fc8db8 042dfe7c scrobj!ComDexHandler::Inner::Release+0xd 02c3ca64 68fc8db8 042dfe7c 00a30ef4 10b5140c msjava!RemoteReleaseCallback+0xd 02c3ccac 68fc8bb9 02c3cd9c 10b5140c 7c0183b5 ole32!EnterForCallback+0x111 02c3cdcc 68fec807 00079048 7c0183b5 042dfe7c ole32!SwitchForCallback+0x19c 02c3ce00 77d445e0 02c70ff8 00000000 02020202 ole32!CRemoteUnknown::DoCallback+0x72 The following call stack shows a Microsoft Enterprise Services component that runs on Microsoft Windows XP. Note the frame that contains ole32!CGIPTable::RevokeInterfaceFromGlobal. <pre class="fixed_text">036ded74 77f7f49f 77e74bd8 00000001 036dedc0 SharedUserData!SystemCallStub+0x4 036ded78 77e74bd8 00000001 036dedc0 00000001 ntdll!NtWaitForMultipleObjects+0xc 036dee14 77237ce4 00000001 042dd7dc 00000000 kernel32!WaitForMultipleObjectsEx+0x12c 036dee84 7575eb1d 00000000 ffffffff 00000001 ole32!CoWaitForMultipleHandles+0xe0 036deee0 7575e963 042dd790 00000001 036defb8 comsvcs!CActivity::EnterActivity+0x194 036deef0 77237287 042dd780 036defb8 036df070 comsvcs!CActivity::Enter+0x13 036def20 771d9c46 00000020 00000002 036df070 ole32!CPolicySet::DeliverEvents+0x1b4 036def98 77253c5a 036defb8 00000002 036df070 ole32!CPolicySet::Notify+0x31d 036defec 772543c7 00000000 042bede8 771cb6cd ole32!EnterForCallback+0xb3 036df144 77236722 036df024 771cb6cd 036df19c ole32!SwitchForCallback+0x19a 036df170 7722a047 042bede8 771cb6cd 036df19c ole32!PerformCallback+0x52 036df1a4 77201a4b 04284894 00000000 00090ec0 ole32!ReleaseMarshalObjRef+0x76 036df210 77237f23 036df228 000fefa0 00001b0c ole32!CoReleaseMarshalData+0x7b 036df24c 0377e50d 772b4618 00001b0c 032d2100 ole32!CGIPTable::RevokeInterfaceFromGlobal+0x1a1 036df294 03100971 0106281c 03103cea 032d2100 0x377e50d 036df2d4 79a87bfd 799b0983 036df300 000fefa0 0x3100971 036df2ec 7930a2a8 799b0908 0106281c 00000000 mscorlib_79960000+0x127bfd 036df318 792ad177 799b0908 0106281c 00000000 mscorwks!CTPMethodTable::CallTarget+0x4b 036df338 791b21e7 031f341c 00000000 00000000 mscorwks!CRemotingServices::CreateProxyOrObject+0x57 036df3a4 791b22a1 031f341c 03103c3f 00000002 mscorwks!JIT_NewCrossContextHelper+0x3b For information about how to obtain symbolic information while you use debugging tools, visit the following Microsoft Web site:

http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx

For more information about how to install Windows 2000 and Windows 2000 hotfixes at the same time, click the following article number to view the article in the Microsoft Knowledge Base:

249149 Installing Microsoft Windows 2000 and Windows 2000 hotfixes

For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:

824684 Description of the standard terminology that is used to describe Microsoft software updates

Additional query words: deadlock hang kbWin2000preSP3COMRollup14Fix

Keywords: kbbug kbfix kbwin2000presp3fix kbqfe kbwin2000sp3fix KB298014

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.