CoCreateInstance()挂起 [英] CoCreateInstance() Hung

查看:241
本文介绍了CoCreateInstance()挂起的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有2个COM ourtproc服务器.从服务器A的UI线程调用CoCreateInstance()来激活服务器B. Server-A的

UI线程初始化为STA.服务器-B的主线程也被初始化为STA.

   Server-A中的COM对象是使用CComPtr创建的.

CoCreateInstance()经常被调用,并且对  CoCreateInstance()的连续调用使CoCreateInstance()在3或4小时后挂起.发布时,服务器B已在运行.据我了解,由于它已经在运行, 此问题与服务器B没有关系.  请在下面找到问题的调用堆栈

 00184970 76be06eb 001849e8 00000000 0000000f user32!NtUserPeekMessage + 0x15
00184998 76be0751 001849e8 00000000 0000000f user32!_PeekMessage + 0x88
001849c4 74c3805d 001849e8 00000000 0000000f user32!PeekMessageW + 0x108
警告:堆栈展开信息不可用.以下框架可能是错误的.
00184a04 74c383a6 00184a18 00184c8c 74b86e28 mfc90u + 0xc805d
00184a44 770d50d2 0218f058 00000000 00000000 mfc90u + 0xc83a6
00184a84 7706d09e e46cbbe0 00000102 00184c8c ole32!CCliModalLoop :: HandlePendingMessage + 0x36
00184ae0 7706d048 00184c8c 006f9760 00000000 ole32!CCliModalLoop :: HandleWakeForMsg + 0x4c
00184af8 77072d31 00184b18 ffffffff 00184b28 ole32!CCliModalLoop :: BlockFn + 0xc3
00184b20 7718d2f6 ffffffff 006f9760 00184c30 ole32!ModalLoop + 0x5b
00184b3c 7718d098 00000000 00184c44 00000000 ole32!ThreadSendReceive + 0x12d
00184b68 7718cef0 00184c30 00710da0 00184c8c ole32!CRpcChannelBuffer :: SwitchAptAndDispatchCall + 0x1a7
00184c48 77072cba 00710da0 00184d74 00184d5c ole32!CRpcChannelBuffer :: SendReceive2 + 0xef
00184c64 77089aa1 00184d74 00184d5c 00710da0 ole32!CCliModalLoop :: SendReceive + 0x1e
00184ce0 77089b24 00710da0 00184d74 00184d5c ole32!CAptRpcChnl :: SendReceive + 0x73
00184d34 7718ce06 00710da0 00184d74 00184d5c ole32!CCtxComChnl :: SendReceive + 0x1c5
00184d50 763a420b 00725d5c 00184da0 76420149 ole32!NdrExtpProxySendReceive + 0x49
00184d5c 76420149 e46ca0ae 001851a8 0700022b rpcrt4!NdrpProxySendReceive + 0xe
00185170 7718c8e2 7709fa10 770a48ce 001851a8 rpcrt4!NdrClientCall2 + 0x1a6
00185190 770898ad 00000014 00000004 00185210 ole32!ObjectStublessClient + 0xa2
001851a0 77085d2c 00725d5c 00000000 00185664 ole32!ObjectStubless + 0xf
00185210 7708637b 00185664 00185bcc 00000000 ole32!CRpcResolver :: CreateInstance + 0x195
0018546c 77093170 77196448 00000000 00185664 ole32!CClientContextActivator :: CreateInstance + 0x11f
001854ac 77093098 00185664 00000000 00185bcc ole32!ActivationPropertiesIn :: DelegateCreateInstance + 0x108
00185c80 77099e25 00185d58 00000000 00000017 ole32!ICoCreateInstanceEx + 0x404
00185ce0 77099d86 00185d58 00000000 00000017 ole32!CComActivator :: DoCreateInstance + 0xd9
00185d04 77099d3f 00185d58 00000000 00000017 ole32!CoCreateInstanceEx + 0x38
00185d34 1000865b 00185d58 00000000 00000017 ole32!CoCreateInstance + 0x37


谢谢Renjith V R

解决方案

您的帖子中确实没有足够的信息来推断正在发生的事情.但是,从经验来看,一个不错的选择是您的资源不足.我将仔细查看服务器A和服务器A上的专用字节"性能计数器. 服务器B,然后观察值是否随着分钟和小时的滴答作响而上升.那将表明一个严重的问题;通常是由于引用计数不正确.


I have a 2 COM ourtproc servers. CoCreateInstance() is invoked from UI thread of Server-A to activate  Server-B. 

UI thread of Server-A is initialized as STA. Also main thread of Server-B is initialized as STA.

The COM object in  Server-A is created with CComPtr.

CoCreateInstance() is invoked frequently and this continuous call to  CoCreateInstance() makes CoCreateInstance() hung after 3 or 4 hours. At the time of issue, Server-B is already running. As per my understanding, since it is already running, this issue has no relation with Server-B.  Please find the callstack of the issue below

00184970 76be06eb 001849e8 00000000 0000000f user32!NtUserPeekMessage+0x15
00184998 76be0751 001849e8 00000000 0000000f user32!_PeekMessage+0x88
001849c4 74c3805d 001849e8 00000000 0000000f user32!PeekMessageW+0x108
WARNING: Stack unwind information not available. Following frames may be wrong.
00184a04 74c383a6 00184a18 00184c8c 74b86e28 mfc90u+0xc805d
00184a44 770d50d2 0218f058 00000000 00000000 mfc90u+0xc83a6
00184a84 7706d09e e46cbbe0 00000102 00184c8c ole32!CCliModalLoop::HandlePendingMessage+0x36 
00184ae0 7706d048 00184c8c 006f9760 00000000 ole32!CCliModalLoop::HandleWakeForMsg+0x4c 
00184af8 77072d31 00184b18 ffffffff 00184b28 ole32!CCliModalLoop::BlockFn+0xc3 
00184b20 7718d2f6 ffffffff 006f9760 00184c30 ole32!ModalLoop+0x5b 
00184b3c 7718d098 00000000 00184c44 00000000 ole32!ThreadSendReceive+0x12d 
00184b68 7718cef0 00184c30 00710da0 00184c8c ole32!CRpcChannelBuffer::SwitchAptAndDispatchCall+0x1a7 
00184c48 77072cba 00710da0 00184d74 00184d5c ole32!CRpcChannelBuffer::SendReceive2+0xef 
00184c64 77089aa1 00184d74 00184d5c 00710da0 ole32!CCliModalLoop::SendReceive+0x1e 
00184ce0 77089b24 00710da0 00184d74 00184d5c ole32!CAptRpcChnl::SendReceive+0x73 
00184d34 7718ce06 00710da0 00184d74 00184d5c ole32!CCtxComChnl::SendReceive+0x1c5 
00184d50 763a420b 00725d5c 00184da0 76420149 ole32!NdrExtpProxySendReceive+0x49 
00184d5c 76420149 e46ca0ae 001851a8 0700022b rpcrt4!NdrpProxySendReceive+0xe
00185170 7718c8e2 7709fa10 770a48ce 001851a8 rpcrt4!NdrClientCall2+0x1a6
00185190 770898ad 00000014 00000004 00185210 ole32!ObjectStublessClient+0xa2 
001851a0 77085d2c 00725d5c 00000000 00185664 ole32!ObjectStubless+0xf 
00185210 7708637b 00185664 00185bcc 00000000 ole32!CRpcResolver::CreateInstance+0x195 
0018546c 77093170 77196448 00000000 00185664 ole32!CClientContextActivator::CreateInstance+0x11f 
001854ac 77093098 00185664 00000000 00185bcc ole32!ActivationPropertiesIn::DelegateCreateInstance+0x108 
00185c80 77099e25 00185d58 00000000 00000017 ole32!ICoCreateInstanceEx+0x404 
00185ce0 77099d86 00185d58 00000000 00000017 ole32!CComActivator::DoCreateInstance+0xd9 
00185d04 77099d3f 00185d58 00000000 00000017 ole32!CoCreateInstanceEx+0x38 
00185d34 1000865b 00185d58 00000000 00000017 ole32!CoCreateInstance+0x37 


Thanks, Renjith V R

解决方案

There really isn't sufficient information in your post to deduce what is going on. However, from experience, a good bet is that you are running out of resources. I'd be taking a close look at the Private Bytes performance counters on both Server A and Server B and see if the values are rising as the minutes and hours tick by. That would indicate a serious problem; typically this is due to incorrect reference counting.


这篇关于CoCreateInstance()挂起的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆