Re: Stack corruption? Lost message?

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Heiko Braeske (HeikoBraeske_at_NOTweb.de)
Date: 12/17/04 

Date: Fri, 17 Dec 2004 10:11:45 +0100

There is actually no external client started that would call a COM method of
our server - as far as I know. Is there a possibility to catch/spy/log a COM
call to detect which client is calling?

"Alexander Nickolov" <agnickolov@mvps.org> schrieb im Newsbeitrag
news:upD1jY54EHA.3828@TK2MSFTNGP09.phx.gbl...
> Ths stack dump looks like an external client tries to call into
> your object and the object is already gone. This typically happens
> if you call CoUninitialize while external clients still hold pointers
> to your objects. You are supposed to call CoDisconnectObject
> on all outstanding externally referenced objects bvefore you
> call CoUninitialize. Note, this is just a guess though...
>
> The thread(s) you are seeing have nothing to do with any COM
> objects - they belong to the RPC thread pool and are started
> as part of CoInitialize[Ex]. All incoming COM method calls
> into your server are first processed on these threads, before
> they are routed to the appropriate COM apartment.

>
> --
> =====================================
> Alexander Nickolov
> Microsoft MVP [VC], MCSD
> email: agnickolov@mvps.org
> MVP VC FAQ: http://www.mvps.org/vcfaq
> =====================================
>
> "Heiko" <HeikoBraeske@NOTweb.de> wrote in message
> news:eJVk5f44EHA.3120@TK2MSFTNGP12.phx.gbl...
>> Hi Alexander,
>>
>> thank you for answering.
>>
>> Comments inline.
>>
>> "Alexander Nickolov" <agnickolov@mvps.org> schrieb im Newsbeitrag
>> news:eoVhf8s4EHA.3380@TK2MSFTNGP09.phx.gbl...
>>> Inline.
>>>
>>> --
>>> =====================================
>>> Alexander Nickolov
>>> Microsoft MVP [VC], MCSD
>>> email: agnickolov@mvps.org
>>> MVP VC FAQ: http://www.mvps.org/vcfaq
>>> =====================================
>>>
>>> "Heiko" <HeikoBraeske@NOTweb.de> wrote in message
>>> news:%23nMsE9n4EHA.2572@tk2msftngp13.phx.gbl...
>>>> Hi,
>>>>
>>>> I need some help on an access violation in our application. It happens
>>>> in one of five threads in the ole32.dll.
>>>> - Is it possible that one thread corrupts the stack of another thread?
>>>
>>> Theoretically yes, it's all writable memory after all, but it needs
>>> to know the address range of the other thread's stack first. In
>>> practice - no.
>>>
>>
>> I'm still not sure, wether our application(s) has a bug or the ole32.dll.
>> But if it is unlikely that the stack is corrupted by another thread there
>> must be something wrong inside the ole32.dll.
>>
>>
>>>>
>>>> The thread of the ole32.dll ist started when I call
>>>> COleTemplateServer::RegisterAll().
>>>> - What COM-object is then initialized? How can I find that out?
>>>
>>> Not familiar with MFC that much, but at a guess - no COM objects
>>> are created. I suppose this is the call to register the class factories.
>>> I may be wrong here though.
>>
>> Well, I mixed there something up. Ole32!CoInitializeEx is called already
>> in AfxOleInit. From that I concluded an COM-Object is initialized.
>>
>>>
>>>>
>>>> The COM-object is initialized in a STA.
>>>> - If there is no stack corruption, could there be a message in the
>>>> queue, which is processed by the CRpcWorkerThread when the COM-object
>>>> is already deleted?
>>>
>>> If your reference counting is screwed - yes, your object may destroy
>>> prematurely. This can only happen due to bad internal reference
>>> counting,
>>> external clients always go through a proxy. At any rate, this will
>>> happen
>>> on the main server thread, not on a COM thread.
>>
>> Is there any Ole32-COM-object, which is initialized in AfxOleInit and
>> which is used in RegisterAll()? A OleTemplateServer-object e.g. So our
>> app acts on this server-object as a client... Just a guess.
>>
>> [snip]
>>>
>>> Some more details are needed. When does the exception occur - during
>>> normal work or during server shutdown? If the former, can you establish
>>> what method of what object is being called? If the latter, are you
>>> calling
>>> CoDisconnectObject on all outstanding external object references (if
>>> any)?
>>> Also, if you have symbols installed, can you post the call stack when
>>> the
>>> crash occurs?
>>
>> The exception occurs after some normal work and then waiting just about
>> one minute. When the Ole32-thread, which was started by RegisterAll(), is
>> about to finish the exception occurs. If we wait after starting up for
>> one minute without doing anything the thread ends without exception.
>> After that we can work without a crash.
>>
>> This is from WinDbg:
>> register
>> (894.a14): Access violation - code c0000005 (first chance)
>> First chance exceptions are reported before any exception handling.
>> This exception may be expected and handled.
>> eax=00000000 ebx=00000102 ecx=00000101 edx=ffffffff esi=00146328
>> edi=7c573ace
>> eip=00000000 esp=01fcff94 ebp=00007530 iopl=0 nv up ei pl zr na
>> po nc
>> cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010246
>>
>> stack
>>
>> 01fcff94 77ab50ee ole32!CRpcThread::WorkerLoop+0x22
>> 01fcff98 00000000
>> 01fcff9c 77a50000 ole32!_imp__RegDeleteKeyW <PERF> (ole32+0x0)
>> 01fcffa0 00146328
>> 01fcffa4 01fcffec
>> 01fcffa8 00146328
>> 01fcffac 77ab5046 ole32!CRpcThreadCache::RpcWorkerThreadEntry+0x1a
>> 01fcffb0 77a67d45 ole32!MIDL_user_allocate
>> 01fcffb4 77a67d30 ole32!MIDL_user_free
>> 01fcffb8 7c57438b KERNEL32!BaseThreadStart+0x52
>> 01fcffbc 00146328
>> 01fcffc0 77a67d45 ole32!MIDL_user_allocate
>> 01fcffc4 77a67d30 ole32!MIDL_user_free
>> 01fcffc8 00146328
>> 01fcffcc 7ffdc000
>> 01fcffd0 00000688
>> 01fcffd4 01fcffc0
>> 01fcffd8 00000688
>> 01fcffdc ffffffff
>> 01fcffe0 7c57e597 KERNEL32!_except_handler3
>> 01fcffe4 7c57a0a8 KERNEL32!`string'+0x2c
>> 01fcffe8 00000000
>> 01fcffec 00000000
>> 01fcfff0 00000000
>> 01fcfff4 77ab502c ole32!CRpcThreadCache::RpcWorkerThreadEntry
>> 01fcfff8 00146328
>> 01fcfffc 00000000
>> following 00000000
>>
>>
>>
>>
>
>

Relevant Pages

  • Re: Stack corruption? Lost message?
    ... our server - as far as I know. ... > Ths stack dump looks like an external client tries to call into ... >> But if it is unlikely that the stack is corrupted by another thread there ... >> about to finish the exception occurs. ...
    (microsoft.public.win32.programmer.ole)
  • Re: Stack corruption? Lost message?
    ... our server - as far as I know. ... > Ths stack dump looks like an external client tries to call into ... >> But if it is unlikely that the stack is corrupted by another thread there ... >> about to finish the exception occurs. ...
    (microsoft.public.vc.mfc)
  • IIS Out-of-Process Component services application crashes
    ... Server Application Name: WebApp ... Exception: C0000005 ... Call Stack: ... Is the process crashing when it tries to create a new thread? ...
    (microsoft.public.inetserver.iis)
  • Re: Weird 0x80010105 error
    ... This is memory corruption at its best. ... code is not in the call stack. ... I will try to run my server in the debugger to ... >> I think it's very weird that the exception doesn't occur when I'm ...
    (microsoft.public.vc.atl)
  • Re: IIS Out-of-Process Component services application crashes
    ... component hosted in the COM+ server application is corrupting things. ... > generated an exception. ... > Call Stack: ... > Is the process crashing when it tries to create a new thread? ...
    (microsoft.public.inetserver.iis)