Re: Any tool that tells COM dependencies of a DLL?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

um - that's not what i see every day in the shell.. i see the shell load my
com dll breifly.. use it.. and release it.. i then see my DLL_PROCESS_DETACH
called and i'm gawn... maybe i'm misunderstanding something but i'm telling
you what i see.. i don't see the DLL get loaded and held onto... maybe
things are different in vista..


"Alexander Nickolov" <agnickolov@xxxxxxxx> wrote in message
news:eR4aJo9NGHA.2668@xxxxxxxxxxxxxxxxxxxxxxx
Actually that's what Igor was trying to tell you - the DLL never
gets unloaded even if the client never needs it anymore. It _can_
be unloaded in theory, but it never is in practice.

BTW, did you find COMSpy not helpful? I haven't used it
myself I admit...

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

"mysteron" <acornatom66@xxxxxxxxx> wrote in message
news:u5shdP2NGHA.1028@xxxxxxxxxxxxxxxxxxxxxxx
ok lets not nit pick here :) the scenario i was talking about is where
the client does a single cocreate, uses the interface and releases... all
in a short period of time.. the DLL gets unloaded shortly afterwards.. so
my point was that this loading/unloading is very dynamic .. and not
something that is easily followed just by keeping your eyes glued to
process explorer... also it might well happen in less time than the
refresh rate of that program, in which case you'd certainly see nothing
...
I see this behavior all the time when programming the windows vista
shell... dll's certainly *do* unload before the shell terminates... well
before...


"Igor Tandetnik" <itandetnik@xxxxxxxx> wrote in message
news:uMOeWL2NGHA.2696@xxxxxxxxxxxxxxxxxxxxxxx
"mysteron" <acornatom66@xxxxxxxxx> wrote in message
news:%23lQATo1NGHA.3064@xxxxxxxxxxxxxxxxxxxx
Also, even if the COM
object lives in a DLL.. that DLL will only be loaded into the process
space for the lifetime of the IUnkown pointer pased back from
cocreateinstance..

That's not true. Once loaded, COM DLLs are usually not unloaded until
the process is terminated, even when there are no outstanding
references. In principle, one can unload them explicitly by calling
CoFreeUnusedLibraries, but many people claim this function is actually a
no-op on modern OS versions (Win2K and above if I recall correctly).
--
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







.

Relevant Pages

  • Re: Any tool that tells COM dependencies of a DLL?
    ... client does a single cocreate, ... the DLL gets unloaded shortly afterwards.. ... dll's certainly *do* unload before the shell terminates... ...
    (microsoft.public.win32.programmer.ole)
  • Re: Any tool that tells COM dependencies of a DLL?
    ... Actually that's what Igor was trying to tell you - the DLL never ... client does a single cocreate, ... one can unload them explicitly by calling ...
    (microsoft.public.win32.programmer.ole)
  • Re: The Hoard Scalable Memory Allocator
    ... aware about implementation details like per-thread heap when he simply ... Now because the DLL is internally using per- ... Without the per-thread heap it's possible to unload the ... Since you are promoting a general purpose memory manager you ...
    (comp.programming.threads)
  • Re: dllimport to unload dll
    ... I was thinking that when the method (it is a static method) completed then the dll would be unloaded. ... It would be quite annoying to load a DLL, call a function that starts a background thread, and then have the runtime helpfully unload that DLL behind your back, which would either crash the thread or force the DLL to terminate it. ... About the only thing explicit unloading would be good for is to allow the DLL to be replaced while the main application is still running, which is a dubious versioning mechanism to say the least. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Dynamically Created AX Control not released.
    ... every dll loaded in a process must be explicitly ... For COM dll's (like OCX) the dll is loaded in a compatible apartment (STA ... yourself, by calling "CoLoadLibrary", and unload it when done by calling ... > protected override void Dispose(bool disposing) ...
    (microsoft.public.dotnet.framework.interop)