IShell Folders not cleaned up on exit
Big Rich
window, removing the window kills the DLL but doesn't free the
IShellFolder items prior to exit.
How can I force the shell to Release() all the IShellFolder items
before exiting the DLL?
CanUnloadDll() does not seem to be checked when the explorer window is
killed in this way. Causes hideous memory leaks.
TIA, Rich
Sent via Deja.com http://www.deja.com/
Before you buy.
Serge B.
Not solved yet.
I found that it is not always the case.
In fact, it seems that a IShellFolder pointer is kept held by the Explorer
(i.e the first instance of the Exporer) the first time it parses the
namespace. All other pointers are correctly released after that, even if
taken bu other Explorer's threads. I'm not 100% sure of that.
May be it's by design ?
Big Rich <bbm...@my-deja.com> a écrit dans le message :
819s75$q5q$1...@nnrp1.deja.com...
Jürgen Schmied
memory leak of one shellfolder...
bye
juergen
------
Home: ds9.net/schmied
Big Rich
shell keeps the ShellFolders alive, ie. doesn't Release() the objects.
How would the shell use such pointers? It would have to restart the DLL
to use them. Does this sound possible? Can it use a new instance of a
DLL to execute class methods on an object that was created by a
different DLL instance? Would not the ShellFolder object be destroyed
by memory deallocation when it's app (ie. the DLL) was killed? If so
then the pointers could only lead to memory access violations.
Food for thought?
Raymond Chen
navigate away, the shell keeps the IShellFolder in case the user
navigates back. And then there are some applications that relied
on this aggressive cacheing -- if the shell calls
IShellFolder::Release too soon, they crash. So it's now a
"feature" that the shell hangs onto these IShellFolders longer
than you would expect.
At process termination, all the memory allocated by the process
gets freed automatically, so the cleanup is implicit.
--
(My return address is intentionally invalid to foil spammers. Delete the
".---" to get my real address. I do this on my own time with my own money;
my responses are not to be considered official technical support or advice.
Personal requests for assistance will be ignored.)
Serge B.
english...
But the shell can share COM objects pointers between its threads, provided
that he knows how to marshall them, and sure he knows, since he is the
*author* of theses interfaces.
He does not have to "restart" the DLL to do this. And if he is COM copliant,
he shouldn't do so since your DllcanUnloadNow() proc answers "NO" beause of
the held pointer.
Of course, he can unload by force the DLL, but this will cause a memory leak
(your object's datas & pointers, cince allocated on the heap).
No. Maybe it's a bug -surprising, yet- because undocumented and because
namespaces have been tried many times par developers since the release date
of Win95.
Or maybe it's by design (undocumented design, as usual...), or simply
something we missed.
Big Rich <bbm...@my-deja.com> a écrit dans le message :
81fcja$q43$1...@nnrp1.deja.com...
Big Rich
> The shell aggressively caches IShellFolders, so even after you
> navigate away, the shell keeps the IShellFolder in case the user
> navigates back. And then there are some applications that relied
> on this aggressive cacheing -- if the shell calls
> IShellFolder::Release too soon, they crash. So it's now a
> "feature" that the shell hangs onto these IShellFolders longer
> than you would expect.
>
> At process termination, all the memory allocated by the process
> gets freed automatically, so the cleanup is implicit.
I humbly disagree...
The ShellFolder objects hold PIDLs which are created with IMalloc and
thus are not part of DLL's memory space. If the ShellFolders are
destroyed without a chance to clean up all references to these objects
are lost and hence they become memory leaks.
Chris Becke
> > At process termination, all the memory allocated by the process
> > gets freed automatically, so the cleanup is implicit.
>
> I humbly disagree...
>
> The ShellFolder objects hold PIDLs which are created with IMalloc and
> thus are not part of DLL's memory space. If the ShellFolders are
> destroyed without a chance to clean up all references to these objects
> are lost and hence they become memory leaks.
"At process termination" <- When a proces is terminated all the memory
allocated by all the Dll's is freed up.
If you have any cleanup needs over and above that, you will get a
D__PROCESS_DETECH message sent to your DllEntryPoint function, which you can
use to do any cleanup that shutting down a process does not do.
Chris
--
Sean Legassick
<raym...@microsoft.com.---> writes
>The shell aggressively caches IShellFolders, so even after you
>navigate away, the shell keeps the IShellFolder in case the user
>navigates back. And then there are some applications that relied
>on this aggressive cacheing -- if the shell calls
>IShellFolder::Release too soon, they crash. So it's now a
>"feature" that the shell hangs onto these IShellFolders longer
>than you would expect.
As in well beyond the lifetime of the process? If I write a well-behaved
COM object that exposes services to a client I expect that client to
treat my object with respect. Just because some idiot wrote some broken
code once, why does that mean I get my code shot down before it has had
a chance to tidy up behind itself?
In addition, I've observed that on Win95+IE4+shell update the process
gets terminated whilst the final Release of my final IShellFolder was
still running. This is simply appalling behaviour on the part of the
shell as a COM client.
>At process termination, all the memory allocated by the process
>gets freed automatically, so the cleanup is implicit.
Sigh. And what about file integrity? Cleanup isn't necessarily just
deallocating memory. I'm developing a shell extension that accesses a
shared database. I want to be terminated cleanly so that I can close the
database cleanly and guard against corruption. Of course I could code
this into DllMain reason DLL_PROCESS_DETACH. But I *really* shouldn't
have to.
Sean
--
/-Sean Legassick---------------------find the band at------------\
@ work: se...@demon.net http://fly.to/parallax *
@ home: seanle...@cyberjunkie.com *
\--------------"So beautiful to be...state of emergency" - Bjork-/
Raymond Chen
<seanle...@cyberjunkie.com> wrote:
>As in well beyond the lifetime of the process?
IShellFolders, by vurtue of being in-proc servers, by definition
do not outlive their process.
>Just because some idiot wrote some broken
>code once, why does that mean I get my code shot down before it has had
>a chance to tidy up behind itself?
Because that idiot who wrote broken code shipped first. Certain
idiots who write broken code are #1 on the software charts in
their area.
Backwards compatibility with idiots is one of the highest
priorities for any operating system. You can say "It's a bug in
the application" as many times as you like to the customer; the
customer won't believe you. And the company that produces the
application issues a press release saying that "Microsoft
intentionally added code to make our application crash."
(Nevermind that the application was accessing memory after
freeing it.)
Raymond Chen
wrote:
>The ShellFolder objects hold PIDLs which are created with IMalloc and
>thus are not part of DLL's memory space.
But they *are* a part of the process's memory space, which is
automatically cleaned up when the process terminates.
Sean Legassick
<raym...@microsoft.com.---> writes
>On Fri, 26 Nov 1999 17:10:11 +0000, Sean Legassick
><seanle...@cyberjunkie.com> wrote:
>>As in well beyond the lifetime of the process?
>
>IShellFolders, by vurtue of being in-proc servers, by definition
>do not outlive their process.
Yep, sorry - I missed a smiley off that one. The *reference* does as it
never gets released.
>>Just because some idiot wrote some broken
>>code once, why does that mean I get my code shot down before it has had
>>a chance to tidy up behind itself?
>
>Because that idiot who wrote broken code shipped first. Certain
>idiots who write broken code are #1 on the software charts in
>their area.
Okay that's a fair point. There are certain developers whose code you,
for commercial reasons, must ensure doesn't get broken.
What I really object to is that my code, which obeys all the rules, did
get broken because of this "feature" of the shell. And it isn't
documented anywhere that this would happen.
Raymond Chen
<seanle...@cyberjunkie.com> wrote:
>What I really object to is that my code, which obeys all the rules, did
>get broken because of this "feature" of the shell. And it isn't
>documented anywhere that this would happen.
Well, it's always possible for the process to be terminated
before doing all its cleanup. "End Task" for example doesn't
give you a chance to clean up.
Sean Legassick
<raym...@microsoft.com.---> writes
>On Wed, 1 Dec 1999 14:30:01 +0000, Sean Legassick
><seanle...@cyberjunkie.com> wrote:
>>What I really object to is that my code, which obeys all the rules, did
>>get broken because of this "feature" of the shell. And it isn't
>>documented anywhere that this would happen.
>
>Well, it's always possible for the process to be terminated
>before doing all its cleanup. "End Task" for example doesn't
>give you a chance to clean up.
Sigh. And of course we inform our users that if they "End Task" our
products then they deserve what they get in terms of file corruption.
Anyway, we could go round and round this forever. I've had my whinge;
the shells that do this are out there in the field; so I'm just going to
have to deal with it.
Raymond Chen
shell extension crashes the shell. (And then there are some
extremely evil applications that call TerminateProcess on
Explorer and then relaunch it because they don't know about
SystemParametersInfo or WM_SETTINGCHANGE.)
You have to be ready to handle the case where your host
application dies without going through full cleanup.