I have a dialog based app that calls IAutoComplete using the protocol
described at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla
tform/shell/reference/ifaces/iautocomplete/iautocomplete.asp .

I have my own IEnumString object. The dialog owns a CComPtr<> for
IAutoComplete2 and for IEnumString::IUnknown.

I CoCreateInstance() on the IAC2 and IES objects, and QI() the IES for IUnk.
I pass the IUnk and a nice edit control to IAutoComplete::Init(). I get nice
calls into my IES API. All is well until I shut down.

The problem seems to be that when the app shuts down, sometimes it does so
with a refcount left on the IUnk for the IEnumString object. This generates
a UAE somewhere in the shell code. It happens intermittently about 50% of
the time. I assume I am getting some sort of race condition which is
affecting object destruction while either (1) the shell holds a pointer to
the object which has already been destroyed, or (2) the object holds a
handle to an edit control that has already been destroyed.

What is going on? How do I get around it?

RDeW

By the way, the IEnumString object is implemented in the same EXE that
houses the code for the dialog and the rest of the app. It occurs to me this
may be part of the problem but I cannot put my finger on why exactly.

I agree - happens here too. That's - IIRC - because the interface does 
possibly not get WM_DESTROY of the edit control, and thus keeps thinking it 
is needed. Or something like that.

See my code of the destructor (called by me when I know the autorelease 
should be gone):

    if (_nRef != 0)
        OutputDebugString("WRN: clsEnumString object count is %d (should be 
0)!\n"
        "(This is a bug of the OS, but don't care: memory will be released 
anyway)",
        _nRef);


My workaround: IEnumString is not a COM object, but managed by me. Then I 
don't care about the refcount apart from the debug message :)

Christian

"Riley DeWiley"  wrote in message 
news:uLednTh5g_gwox3fRVn-gw@seanet.com...
>I have a dialog based app that calls IAutoComplete using the protocol
> described at
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla
> tform/shell/reference/ifaces/iautocomplete/iautocomplete.asp .
>
> I have my own IEnumString object. The dialog owns a CComPtr<> for
> IAutoComplete2 and for IEnumString::IUnknown.
>
> I CoCreateInstance() on the IAC2 and IES objects, and QI() the IES for 
> IUnk.
> I pass the IUnk and a nice edit control to IAutoComplete::Init(). I get 
> nice
> calls into my IES API. All is well until I shut down.
>
> The problem seems to be that when the app shuts down, sometimes it does so
> with a refcount left on the IUnk for the IEnumString object. This 
> generates
> a UAE somewhere in the shell code. It happens intermittently about 50% of
> the time. I assume I am getting some sort of race condition which is
> affecting object destruction while either (1) the shell holds a pointer to
> the object which has already been destroyed, or (2) the object holds a
> handle to an edit control that has already been destroyed.
>
> What is going on? How do I get around it?
>
> RDeW
>
>

Thanks.

Is your code posted somewhere?

"Christian Kaiser"  wrote in message
news:e4qcjuUVFHA.3944@tk2msftngp13.phx.gbl...
> I agree - happens here too. That's - IIRC - because the interface does
> possibly not get WM_DESTROY of the edit control, and thus keeps thinking
it
> is needed. Or something like that.
>
> See my code of the destructor (called by me when I know the autorelease
> should be gone):
>
>     if (_nRef != 0)
>         OutputDebugString("WRN: clsEnumString object count is %d (should
be
> 0)!\n"
>         "(This is a bug of the OS, but don't care: memory will be released
> anyway)",
>         _nRef);
>
>
> My workaround: IEnumString is not a COM object, but managed by me. Then I
> don't care about the refcount apart from the debug message :)
>
> Christian
>
> "Riley DeWiley"  wrote in message
> news:uLednTh5g_gwox3fRVn-gw@seanet.com...
> >I have a dialog based app that calls IAutoComplete using the protocol
> > described at
> >
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla
> > tform/shell/reference/ifaces/iautocomplete/iautocomplete.asp .
> >
> > I have my own IEnumString object. The dialog owns a CComPtr<> for
> > IAutoComplete2 and for IEnumString::IUnknown.
> >
> > I CoCreateInstance() on the IAC2 and IES objects, and QI() the IES for
> > IUnk.
> > I pass the IUnk and a nice edit control to IAutoComplete::Init(). I get
> > nice
> > calls into my IES API. All is well until I shut down.
> >
> > The problem seems to be that when the app shuts down, sometimes it does
so
> > with a refcount left on the IUnk for the IEnumString object. This
> > generates
> > a UAE somewhere in the shell code. It happens intermittently about 50%
of
> > the time. I assume I am getting some sort of race condition which is
> > affecting object destruction while either (1) the shell holds a pointer
to
> > the object which has already been destroyed, or (2) the object holds a
> > handle to an edit control that has already been destroyed.
> >
> > What is going on? How do I get around it?
> >
> > RDeW
> >
> >
>
>

And could you (or someone) expand upon "IEnumString is not a COM object, but
managed by me"?

I have an IEnumString interface wrapped in a CEnumString class that I new()
to get a pointer. I QI() the pointer for the IUnk which I pass to
IAutoComplete. I did notice the dtor is being called with a refcount too
large, yes ...

Thanks

RDeW

You know, in looking at this, I come to the following (tentative)
conclusion: The problem is that I am *not* managing my string enumerator as
a COM object, but am using new/delete. Sometimes I delete it before the
shell is finished with it.

Historically the reason for this is that I wanted the code for the
IEnumString object to live in the same EXE, not a separate DLL housing. I
created the code in the EXE's project, but was stumped by the params for
CoCreateInstance(), which are:
STDAPI CoCreateInstance(
  REFCLSID rclsid,
  LPUNKNOWN pUnkOuter,
  DWORD dwClsContext,
  REFIID riid,
  LPVOID * ppv
);The problem is in the rclsid. I never figured out how to do this, and went
to the new/delete method as a workaround. Given that my problem is "how to
create an object from an EXE, housed in the same EXE", what is the
solution?XPosted to an ATL newsgroup. RDeW"Christian Kaiser" 
wrote in message news:e4qcjuUVFHA.3944@tk2msftngp13.phx.gbl...
> I agree - happens here too. That's - IIRC - because the interface does
> possibly not get WM_DESTROY of the edit control, and thus keeps thinking
it
> is needed. Or something like that.
>
> See my code of the destructor (called by me when I know the autorelease
> should be gone):
>
>     if (_nRef != 0)
>         OutputDebugString("WRN: clsEnumString object count is %d (should
be
> 0)!\n"
>         "(This is a bug of the OS, but don't care: memory will be released
> anyway)",
>         _nRef);
>
>
> My workaround: IEnumString is not a COM object, but managed by me. Then I
> don't care about the refcount apart from the debug message :)
>
> Christian
>
> "Riley DeWiley"  wrote in message
> news:uLednTh5g_gwox3fRVn-gw@seanet.com...
> >I have a dialog based app that calls IAutoComplete using the protocol
> > described at
> >
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla
> > tform/shell/reference/ifaces/iautocomplete/iautocomplete.asp .
> >
> > I have my own IEnumString object. The dialog owns a CComPtr<> for
> > IAutoComplete2 and for IEnumString::IUnknown.
> >
> > I CoCreateInstance() on the IAC2 and IES objects, and QI() the IES for
> > IUnk.
> > I pass the IUnk and a nice edit control to IAutoComplete::Init(). I get
> > nice
> > calls into my IES API. All is well until I shut down.
> >
> > The problem seems to be that when the app shuts down, sometimes it does
so
> > with a refcount left on the IUnk for the IEnumString object. This
> > generates
> > a UAE somewhere in the shell code. It happens intermittently about 50%
of
> > the time. I assume I am getting some sort of race condition which is
> > affecting object destruction while either (1) the shell holds a pointer
to
> > the object which has already been destroyed, or (2) the object holds a
> > handle to an edit control that has already been destroyed.
> >
> > What is going on? How do I get around it?
> >
> > RDeW
> >
> >
>
>

No, I really see the problem of the ref count being one too large on exit of 
the application, and it's not from "destroying too early". The EnumString 
object is never freed.

So I free it myself when I am sure it's not used any more, and I don't rely 
on the ref count (which is a dummy AddRef()/Delete() then). solves the 
problem without having to look for the reason for hours.

Christian

"Riley DeWiley"  wrote in message 
news:ZOqdnR_jmfeiYR3fRVn-rw@seanet.com...
> You know, in looking at this, I come to the following (tentative)
> conclusion: The problem is that I am *not* managing my string enumerator 
> as
> a COM object, but am using new/delete. Sometimes I delete it before the
> shell is finished with it.
>
> Historically the reason for this is that I wanted the code for the
> IEnumString object to live in the same EXE, not a separate DLL housing. I
> created the code in the EXE's project, but was stumped by the params for
> CoCreateInstance(), which are:
> STDAPI CoCreateInstance(
>  REFCLSID rclsid,
>  LPUNKNOWN pUnkOuter,
>  DWORD dwClsContext,
>  REFIID riid,
>  LPVOID * ppv
> );The problem is in the rclsid. I never figured out how to do this, and 
> went
> to the new/delete method as a workaround. Given that my problem is "how to
> create an object from an EXE, housed in the same EXE", what is the
> solution?XPosted to an ATL newsgroup. RDeW"Christian Kaiser" 
> wrote in message news:e4qcjuUVFHA.3944@tk2msftngp13.phx.gbl...
>> I agree - happens here too. That's - IIRC - because the interface does
>> possibly not get WM_DESTROY of the edit control, and thus keeps thinking
> it
>> is needed. Or something like that.
>>
>> See my code of the destructor (called by me when I know the autorelease
>> should be gone):
>>
>>     if (_nRef != 0)
>>         OutputDebugString("WRN: clsEnumString object count is %d (should
> be
>> 0)!\n"
>>         "(This is a bug of the OS, but don't care: memory will be 
>> released
>> anyway)",
>>         _nRef);
>>
>>
>> My workaround: IEnumString is not a COM object, but managed by me. Then I
>> don't care about the refcount apart from the debug message :)
>>
>> Christian
>>
>> "Riley DeWiley"  wrote in message
>> news:uLednTh5g_gwox3fRVn-gw@seanet.com...
>> >I have a dialog based app that calls IAutoComplete using the protocol
>> > described at
>> >
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla
>> > tform/shell/reference/ifaces/iautocomplete/iautocomplete.asp .
>> >
>> > I have my own IEnumString object. The dialog owns a CComPtr<> for
>> > IAutoComplete2 and for IEnumString::IUnknown.
>> >
>> > I CoCreateInstance() on the IAC2 and IES objects, and QI() the IES for
>> > IUnk.
>> > I pass the IUnk and a nice edit control to IAutoComplete::Init(). I get
>> > nice
>> > calls into my IES API. All is well until I shut down.
>> >
>> > The problem seems to be that when the app shuts down, sometimes it does
> so
>> > with a refcount left on the IUnk for the IEnumString object. This
>> > generates
>> > a UAE somewhere in the shell code. It happens intermittently about 50%
> of
>> > the time. I assume I am getting some sort of race condition which is
>> > affecting object destruction while either (1) the shell holds a pointer
> to
>> > the object which has already been destroyed, or (2) the object holds a
>> > handle to an edit control that has already been destroyed.
>> >
>> > What is going on? How do I get around it?
>> >
>> > RDeW
>> >
>> >
>>
>>
>
>

I guess your question is how to create private objects. The
answer is: using CComObject<> and friends. See
CComObject<>::CreateInstance, and note the returned
object has reference count of zero.

-- 
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@mvps.org
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

"Riley DeWiley"  wrote in message 
news:ZOqdnR_jmfeiYR3fRVn-rw@seanet.com...
> You know, in looking at this, I come to the following (tentative)
> conclusion: The problem is that I am *not* managing my string enumerator 
> as
> a COM object, but am using new/delete. Sometimes I delete it before the
> shell is finished with it.
>
> Historically the reason for this is that I wanted the code for the
> IEnumString object to live in the same EXE, not a separate DLL housing. I
> created the code in the EXE's project, but was stumped by the params for
> CoCreateInstance(), which are:
> STDAPI CoCreateInstance(
>  REFCLSID rclsid,
>  LPUNKNOWN pUnkOuter,
>  DWORD dwClsContext,
>  REFIID riid,
>  LPVOID * ppv
> );The problem is in the rclsid. I never figured out how to do this, and 
> went
> to the new/delete method as a workaround. Given that my problem is "how to
> create an object from an EXE, housed in the same EXE", what is the
> solution?XPosted to an ATL newsgroup. RDeW"Christian Kaiser" 
> wrote in message news:e4qcjuUVFHA.3944@tk2msftngp13.phx.gbl...
>> I agree - happens here too. That's - IIRC - because the interface does
>> possibly not get WM_DESTROY of the edit control, and thus keeps thinking
> it
>> is needed. Or something like that.
>>
>> See my code of the destructor (called by me when I know the autorelease
>> should be gone):
>>
>>     if (_nRef != 0)
>>         OutputDebugString("WRN: clsEnumString object count is %d (should
> be
>> 0)!\n"
>>         "(This is a bug of the OS, but don't care: memory will be 
>> released
>> anyway)",
>>         _nRef);
>>
>>
>> My workaround: IEnumString is not a COM object, but managed by me. Then I
>> don't care about the refcount apart from the debug message :)
>>
>> Christian
>>
>> "Riley DeWiley"  wrote in message
>> news:uLednTh5g_gwox3fRVn-gw@seanet.com...
>> >I have a dialog based app that calls IAutoComplete using the protocol
>> > described at
>> >
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla
>> > tform/shell/reference/ifaces/iautocomplete/iautocomplete.asp .
>> >
>> > I have my own IEnumString object. The dialog owns a CComPtr<> for
>> > IAutoComplete2 and for IEnumString::IUnknown.
>> >
>> > I CoCreateInstance() on the IAC2 and IES objects, and QI() the IES for
>> > IUnk.
>> > I pass the IUnk and a nice edit control to IAutoComplete::Init(). I get
>> > nice
>> > calls into my IES API. All is well until I shut down.
>> >
>> > The problem seems to be that when the app shuts down, sometimes it does
> so
>> > with a refcount left on the IUnk for the IEnumString object. This
>> > generates
>> > a UAE somewhere in the shell code. It happens intermittently about 50%
> of
>> > the time. I assume I am getting some sort of race condition which is
>> > affecting object destruction while either (1) the shell holds a pointer
> to
>> > the object which has already been destroyed, or (2) the object holds a
>> > handle to an edit control that has already been destroyed.
>> >
>> > What is going on? How do I get around it?
>> >
>> > RDeW
>> >
>> >
>>
>>
>
>

I'm not sure if the question itself is the one at the bottom of this 
message, so I apologize if I misunderstood the case.

IEnumString implementation is a quite trivial task. IAutoComplete interface 
receives WM_DESTROY, don't worry about it. It subclasses your edit's 
callback, it knows everything before your anyone else knows. IAutoComplete2 
has no bug about this, there is no race condition. What's ref count of your 
IEnumString implementation at its constructor? You should manage IEnumString 
as a COM object. It is a COM object, IAutoComplete treats it as a COM object 
(i.e. by means of its IUnknown characteristics). But since IEnumString has 
no coclass, you cannot CoCreateInstance it - you need to new/delete it, 
that's correct. I think you make a mistake on your ref counter 
(specifically, during its initialization). Place a breakpoint in your 
Release method, see how many times it is hit, and how many times AddRef'd. 
This is my two cents.

Jason

"Riley DeWiley"  wrote in message 
news:ZOqdnR_jmfeiYR3fRVn-rw@seanet.com...
> You know, in looking at this, I come to the following (tentative)
> conclusion: The problem is that I am *not* managing my string enumerator 
> as
> a COM object, but am using new/delete. Sometimes I delete it before the
> shell is finished with it.
>
> Historically the reason for this is that I wanted the code for the
> IEnumString object to live in the same EXE, not a separate DLL housing. I
> created the code in the EXE's project, but was stumped by the params for
> CoCreateInstance(), which are:
> STDAPI CoCreateInstance(
>  REFCLSID rclsid,
>  LPUNKNOWN pUnkOuter,
>  DWORD dwClsContext,
>  REFIID riid,
>  LPVOID * ppv
> );The problem is in the rclsid. I never figured out how to do this, and 
> went
> to the new/delete method as a workaround. Given that my problem is "how to
> create an object from an EXE, housed in the same EXE", what is the
> solution?XPosted to an ATL newsgroup. RDeW"Christian Kaiser" 
> wrote in message news:e4qcjuUVFHA.3944@tk2msftngp13.phx.gbl...
>> I agree - happens here too. That's - IIRC - because the interface does
>> possibly not get WM_DESTROY of the edit control, and thus keeps thinking
> it
>> is needed. Or something like that.
>>
>> See my code of the destructor (called by me when I know the autorelease
>> should be gone):
>>
>>     if (_nRef != 0)
>>         OutputDebugString("WRN: clsEnumString object count is %d (should
> be
>> 0)!\n"
>>         "(This is a bug of the OS, but don't care: memory will be 
>> released
>> anyway)",
>>         _nRef);
>>
>>
>> My workaround: IEnumString is not a COM object, but managed by me. Then I
>> don't care about the refcount apart from the debug message :)
>>
>> Christian
>>
>> "Riley DeWiley"  wrote in message
>> news:uLednTh5g_gwox3fRVn-gw@seanet.com...
>> >I have a dialog based app that calls IAutoComplete using the protocol
>> > described at
>> >
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pla
>> > tform/shell/reference/ifaces/iautocomplete/iautocomplete.asp .
>> >
>> > I have my own IEnumString object. The dialog owns a CComPtr<> for
>> > IAutoComplete2 and for IEnumString::IUnknown.
>> >
>> > I CoCreateInstance() on the IAC2 and IES objects, and QI() the IES for
>> > IUnk.
>> > I pass the IUnk and a nice edit control to IAutoComplete::Init(). I get
>> > nice
>> > calls into my IES API. All is well until I shut down.
>> >
>> > The problem seems to be that when the app shuts down, sometimes it does
> so
>> > with a refcount left on the IUnk for the IEnumString object. This
>> > generates
>> > a UAE somewhere in the shell code. It happens intermittently about 50%
> of
>> > the time. I assume I am getting some sort of race condition which is
>> > affecting object destruction while either (1) the shell holds a pointer
> to
>> > the object which has already been destroyed, or (2) the object holds a
>> > handle to an edit control that has already been destroyed.
>> >
>> > What is going on? How do I get around it?
>> >
>> > RDeW
>> >
>> >
>>
>>
>
>