Re: Stack corruption? Lost message?

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

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

Date: Thu, 16 Dec 2004 16:57:39 +0100

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

  • [PATCH] x86: style fascism for xen assemblies
    ... * a view to being able to inline as much as possible. ... push %eax ... * This is run where a normal iret would be run, with the same stack setup: ... In order to deliver the nested exception properly, ...
    (Linux-Kernel)
  • Re: Stack corruption? Lost message?
    ... Comments inline. ... But if it is unlikely that the stack is corrupted by another thread there ... I suppose this is the call to register the class factories. ... The exception occurs after some normal work and then waiting just about one ...
    (microsoft.public.win32.programmer.ole)
  • Re: Stack corruption? Lost message?
    ... Comments inline. ... But if it is unlikely that the stack is corrupted by another thread there ... I suppose this is the call to register the class factories. ... The exception occurs after some normal work and then waiting just about one ...
    (microsoft.public.vc.debugger)
  • Re: Stack corruption? Lost message?
    ... Ths stack dump looks like an external client tries to call into ... if you call CoUninitialize while external clients still hold pointers ... I suppose this is the call to register the class factories. ... When does the exception occur - during ...
    (microsoft.public.vc.mfc)
  • Re: Stack corruption? Lost message?
    ... Ths stack dump looks like an external client tries to call into ... if you call CoUninitialize while external clients still hold pointers ... I suppose this is the call to register the class factories. ... When does the exception occur - during ...
    (microsoft.public.vc.debugger)