Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

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


View products that this article applies to.

This article was previously published under Q298014
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  (http://support.microsoft.com/kb/256986/ ) Description of the Microsoft Windows registry

↑ Back to the top


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.

↑ Back to the top


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.

↑ Back to the top


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:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3\GipActivityBypass
To do this, follow these steps:
  1. Start Registry Editor.
  2. Locate and then click the following key in the registry:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3
  3. On the Edit menu, point to New, and then click DWORD Value.
  4. Type GipActivityBypass, and then press ENTER.
  5. On the Edit menu, click Modify.
  6. Type 1, and then click OK.
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.

↑ Back to the top


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 "Resolution" 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 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3\System.EnterpriseServices\DisableAsyncFinalization registry value on Windows XP or on Windows 2000, follow these steps:
  1. Start Registry Editor.
  2. Locate and then click the following key in the registry:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3\System.EnterpriseServices
    Note If you do not find the System.EnterpriseServices key under COM3, create the registry key. To do this, follow these steps:
    1. On the Edit menu, point to New, and then click Key.
    2. Type System.EnterpriseServices, and then press ENTER.
  3. On the Edit menu, point to New, and then click DWORD Value.
  4. Type DisableAsyncFinalization, and then press ENTER.
  5. On the Edit menu, click Modify.
  6. Type 1 in the Value data box, and then click OK.

↑ Back to the top


Status

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

↑ Back to the top


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.
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.
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: 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

↑ Back to the top


Keywords: kbwin2000sp3fix, kbqfe, kbfix, kbbug, KB298014, kbwin2000presp3fix

↑ Back to the top

Article Info
Article ID : 298014
Revision : 10
Created on : 12/5/2007
Published on : 12/5/2007
Exists online : False
Views : 685