Re: Crash in Virtual destructor
"Mahesh" <Mahesh@discussions.microsoft.com> wrote in message
news:C81ACEE5-9360-4953-A4E3-EE7AA00C8D92@microsoft.com
Thanks for your reply.
Here is the code
The same code was working before Outlook 2007 SP2 was applied
STDMETHODIMP CCustomAdviseSink::QueryInterface(REFIID riid, LPVOID *
ppvObj) {
HRESULT hr = S_OK;
*ppvObj = NULL;
hr = m_lpOrigSink->QueryInterface(riid, ppvObj);
if(*ppvObj == m_lpOrigSink)
*ppvObj = (LPVOID)this;
Here's what happens. Most likely, the wrapped sink object now implements
another interface derived from IMAPIAdviseSink (possibly internal and
not publicly documented). In other words, in its vtable it has some
slots beyond those specified by IMAPIAdviseSink.
Your QueryInterface implementation then lies to the caller by claiming
that your object implements this new interface. The caller takes you at
your word and calls the new method - but in CCustomAdviseSink's vtable
that extra slot just happens to point to the virtual destructor.
This is just the cause of your immediate problem. In general, your
design violates every COM rule imaginable. If it worked so far, it was
only by accident.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925