Wrong COM DLL Loaded Confusion

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

Part of an application I developed consists of a in-process COM DLL. I ran
my installation on an XP Pro machine which copied and registered the COM DLL
and everything was good. Later I had to debug a problem with the DLL. I
added some diagnostic code to the COM DLL but instead of copying it to the
normal location on the machine, I made a temporary directory and copied the
DLL there instead. I opened a DOS prompt, went the temporary directory and
ran regsvr32 to register the new DLL version which appeared to be
successful. However when I ran my test application which instantiaties the
COM DLL, XP loaded the original DLL into memory instead of the new version I
had just registered. I looked at the registry and verified that the COM
servers GUID was pointing to the new version. I tried copying the new
version on top of the version that was installed by the installation program
and then it worked ok.

Does anyone know why XP would continue to load the original version despite
my having manually registered the new DLL?

--
Thank you,
Scott

Warning: Dates in calendar are closer than they appear.

-----------------------------------------------
Scott Kellish
SoftSystem Solutions, LLC
18 Ridge Road
Clark, NJ 07066

Voice/Fax: 732.382.1873
Cell: 732.261.5856
ICQ: 161-756-325
E-Mail: skellish@softsystemsolutions.com
Web: www.SoftSystemSolutions.com
-----------------------------------------------




A friend might well be reckoned the masterpiece of nature. - Ralph Waldo
Emerson

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

Scott Kellish <skellish@softsystemsolutions.com> wrote:

> Part of an application I developed consists of a in-process COM DLL. I
> ran my installation on an XP Pro machine which copied and registered
> the COM DLL and everything was good. Later I had to debug a problem
> with the DLL. I added some diagnostic code to the COM DLL but instead
> of copying it to the normal location on the machine, I made a temporary
> directory and copied the DLL there instead. I opened a DOS prompt, went
> the temporary directory and ran regsvr32 to register the new DLL
> version which appeared to be successful.

If you want to register a DLL not being located in the search path, use
Start > Run: REGSVR32 <path\>DLLname.DLL

> However when I ran my test application which instantiaties the COM DLL,
> XP loaded the original DLL into memory instead of the new version I had
> just registered. I looked at the registry and verified that the COM
> servers GUID was pointing to the new version. I tried copying the new
> version on top of the version that was installed by the installation
> program and then it worked ok.
>
> Does anyone know why XP would continue to load the original version
> despite my having manually registered the new DLL?

Unless an application loads this DLL on-demand (delay-load dependant
module) from the path mentioned in a registry entry, the default DLL
search order applies to registered DLLs as well:

"Dynamic-Link Library Search Order"
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic-link_library_search_order.asp

--
d-d

 

[Jon]

Archived from groups: microsoft.public.windowsxp.general (More info?)

To properly install the new dll, you need to uninstall the old one first
[using regsvr32 /u ]
(despite the fact that you receive messages indicating the installation to
be successful, without doing the uninstall)

Jon


"Scott Kellish" <skellish@softsystemsolutions.com> wrote in message
news:OZNkOMOuFHA.3740@TK2MSFTNGP14.phx.gbl...
> Part of an application I developed consists of a in-process COM DLL. I ran
> my installation on an XP Pro machine which copied and registered the COM
> DLL and everything was good. Later I had to debug a problem with the DLL.
> I added some diagnostic code to the COM DLL but instead of copying it to
> the normal location on the machine, I made a temporary directory and
> copied the DLL there instead. I opened a DOS prompt, went the temporary
> directory and ran regsvr32 to register the new DLL version which appeared
> to be successful. However when I ran my test application which
> instantiaties the COM DLL, XP loaded the original DLL into memory instead
> of the new version I had just registered. I looked at the registry and
> verified that the COM servers GUID was pointing to the new version. I
> tried copying the new version on top of the version that was installed by
> the installation program and then it worked ok.
>
> Does anyone know why XP would continue to load the original version
> despite my having manually registered the new DLL?
>
> --
> Thank you,
> Scott
>
> Warning: Dates in calendar are closer than they appear.
>
> -----------------------------------------------
> Scott Kellish
> SoftSystem Solutions, LLC
> 18 Ridge Road
> Clark, NJ 07066
>
> Voice/Fax: 732.382.1873
> Cell: 732.261.5856
> ICQ: 161-756-325
> E-Mail: skellish@softsystemsolutions.com
> Web: www.SoftSystemSolutions.com
> -----------------------------------------------
>
>
>
>
> A friend might well be reckoned the masterpiece of nature. - Ralph Waldo
> Emerson
>
>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

Thanks,

I wasn't asking how to register the server. When I ran regsvr32 from a DOS
prompt, I was already in the directory containing the DLL therefore I didn't
have to provide a path.

I mentioned that this is a COM server. Do the DLL search path rules really
apply since the purpose of InProcServer is to provide the path to the
in-process COM server DLL?

--
Thanks,
Scott

Children are all foreigners. - Ralph Waldo Emerson
__________________________________________
SoftSystem Solutions, LLC
18 Ridge Road
Clark, New Jersey 07066 USA
Scott Kellish, Owner
Tel. +01 732 382 1873
Fax: +01 732 382 1873
Mobile: +01 732 261-5856
e-mail: skellish@softsystemsolutions.com
__________________________________________

"Detlev Dreyer" <detdreyer@flashmail.com> wrote in message
news:3bb4659a2be622de4116bd2fb8c8e238@d-d.mvps.org...
> Scott Kellish <skellish@softsystemsolutions.com> wrote:
>
> > Part of an application I developed consists of a in-process COM DLL. I
> > ran my installation on an XP Pro machine which copied and registered
> > the COM DLL and everything was good. Later I had to debug a problem
> > with the DLL. I added some diagnostic code to the COM DLL but instead
> > of copying it to the normal location on the machine, I made a temporary
> > directory and copied the DLL there instead. I opened a DOS prompt, went
> > the temporary directory and ran regsvr32 to register the new DLL
> > version which appeared to be successful.
>
> If you want to register a DLL not being located in the search path, use
> Start > Run: REGSVR32 <path\>DLLname.DLL
>
> > However when I ran my test application which instantiaties the COM DLL,
> > XP loaded the original DLL into memory instead of the new version I had
> > just registered. I looked at the registry and verified that the COM
> > servers GUID was pointing to the new version. I tried copying the new
> > version on top of the version that was installed by the installation
> > program and then it worked ok.
> >
> > Does anyone know why XP would continue to load the original version
> > despite my having manually registered the new DLL?
>
> Unless an application loads this DLL on-demand (delay-load dependant
> module) from the path mentioned in a registry entry, the default DLL
> search order applies to registered DLLs as well:
>
> "Dynamic-Link Library Search Order"
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic-link_library_search_order.asp
>
> --
> d-d

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

Can you explain this? I have an in-process COM server. InProcServer32 is the
registry entry associated with the COM servers ClassID that points to the
location of the DLL. It's my understanding that when I instantiate the
server via its ClassID, Windows will get the InprocServer32 entry and load
the DLL. I know that on 95-2000, I don't have to explicity deregister the
server before registering a new copy, and even on XP when I register the
same ClassID but pointing to a different DLL location, InProcServer32 is
updated to point to the new location, not the old one. There must be
something else going on here related to XP? and part of either the larger
installation process or perhaps the Windows File Protection system. That is
what I'm trying to understand.

--
Thanks,
Scott

Children are all foreigners. - Ralph Waldo Emerson
__________________________________________
SoftSystem Solutions, LLC
18 Ridge Road
Clark, New Jersey 07066 USA
Scott Kellish, Owner
Tel. +01 732 382 1873
Fax: +01 732 382 1873
Mobile: +01 732 261-5856
e-mail: skellish@softsystemsolutions.com
__________________________________________

"Jon" <Email_Address@SomewhereOrOther.com> wrote in message
news:%23wqwSsPuFHA.1560@TK2MSFTNGP09.phx.gbl...
> To properly install the new dll, you need to uninstall the old one first
> [using regsvr32 /u ]
> (despite the fact that you receive messages indicating the installation to
> be successful, without doing the uninstall)
>
> Jon
>
>
> "Scott Kellish" <skellish@softsystemsolutions.com> wrote in message
> news:OZNkOMOuFHA.3740@TK2MSFTNGP14.phx.gbl...
> > Part of an application I developed consists of a in-process COM DLL. I
ran
> > my installation on an XP Pro machine which copied and registered the COM
> > DLL and everything was good. Later I had to debug a problem with the
DLL.
> > I added some diagnostic code to the COM DLL but instead of copying it to
> > the normal location on the machine, I made a temporary directory and
> > copied the DLL there instead. I opened a DOS prompt, went the temporary
> > directory and ran regsvr32 to register the new DLL version which
appeared
> > to be successful. However when I ran my test application which
> > instantiaties the COM DLL, XP loaded the original DLL into memory
instead
> > of the new version I had just registered. I looked at the registry and
> > verified that the COM servers GUID was pointing to the new version. I
> > tried copying the new version on top of the version that was installed
by
> > the installation program and then it worked ok.
> >
> > Does anyone know why XP would continue to load the original version
> > despite my having manually registered the new DLL?
> >
> > --
> > Thank you,
> > Scott
> >
> > Warning: Dates in calendar are closer than they appear.
> >
> > -----------------------------------------------
> > Scott Kellish
> > SoftSystem Solutions, LLC
> > 18 Ridge Road
> > Clark, NJ 07066
> >
> > Voice/Fax: 732.382.1873
> > Cell: 732.261.5856
> > ICQ: 161-756-325
> > E-Mail: skellish@softsystemsolutions.com
> > Web: www.SoftSystemSolutions.com
> > -----------------------------------------------
> >
> >
> >
> >
> > A friend might well be reckoned the masterpiece of nature. - Ralph Waldo
> > Emerson
> >
> >
>
>

 

[Jon]

Archived from groups: microsoft.public.windowsxp.general (More info?)

The bug I was thinking of, which both includes xp and preceding operating
systems, is that sometimes when you use regsvr32 to register a COM object,
in contrast to say using a particular IDE, the registry isn't updated at
all. The solution to that particular bug being to deregister the COM object
first and then to reregister it.

In your particular case, however, you have indicated that the InProcServer32
entry was correctly updated, so that doesn't apply. Someone else may have an
explanation for that.

A passing thought is perhaps there was already an instance of the old dll in
memory, running in the background, when you were running the new version.

Jon


"Scott Kellish" <skellish@comcast.net> wrote in message
news:%23e9I7fTuFHA.1264@TK2MSFTNGP12.phx.gbl...
> Can you explain this? I have an in-process COM server. InProcServer32 is
> the
> registry entry associated with the COM servers ClassID that points to the
> location of the DLL. It's my understanding that when I instantiate the
> server via its ClassID, Windows will get the InprocServer32 entry and load
> the DLL. I know that on 95-2000, I don't have to explicity deregister the
> server before registering a new copy, and even on XP when I register the
> same ClassID but pointing to a different DLL location, InProcServer32 is
> updated to point to the new location, not the old one. There must be
> something else going on here related to XP? and part of either the larger
> installation process or perhaps the Windows File Protection system. That
> is
> what I'm trying to understand.
>
> --
> Thanks,
> Scott
>
> Children are all foreigners. - Ralph Waldo Emerson
> __________________________________________
> SoftSystem Solutions, LLC
> 18 Ridge Road
> Clark, New Jersey 07066 USA
> Scott Kellish, Owner
> Tel. +01 732 382 1873
> Fax: +01 732 382 1873
> Mobile: +01 732 261-5856
> e-mail: skellish@softsystemsolutions.com
> __________________________________________
>
> "Jon" <Email_Address@SomewhereOrOther.com> wrote in message
> news:%23wqwSsPuFHA.1560@TK2MSFTNGP09.phx.gbl...
>> To properly install the new dll, you need to uninstall the old one first
>> [using regsvr32 /u ]
>> (despite the fact that you receive messages indicating the installation
>> to
>> be successful, without doing the uninstall)
>>
>> Jon
>>
>>
>> "Scott Kellish" <skellish@softsystemsolutions.com> wrote in message
>> news:OZNkOMOuFHA.3740@TK2MSFTNGP14.phx.gbl...
>> > Part of an application I developed consists of a in-process COM DLL. I
> ran
>> > my installation on an XP Pro machine which copied and registered the
>> > COM
>> > DLL and everything was good. Later I had to debug a problem with the
> DLL.
>> > I added some diagnostic code to the COM DLL but instead of copying it
>> > to
>> > the normal location on the machine, I made a temporary directory and
>> > copied the DLL there instead. I opened a DOS prompt, went the temporary
>> > directory and ran regsvr32 to register the new DLL version which
> appeared
>> > to be successful. However when I ran my test application which
>> > instantiaties the COM DLL, XP loaded the original DLL into memory
> instead
>> > of the new version I had just registered. I looked at the registry and
>> > verified that the COM servers GUID was pointing to the new version. I
>> > tried copying the new version on top of the version that was installed
> by
>> > the installation program and then it worked ok.
>> >
>> > Does anyone know why XP would continue to load the original version
>> > despite my having manually registered the new DLL?
>> >
>> > --
>> > Thank you,
>> > Scott
>> >
>> > Warning: Dates in calendar are closer than they appear.
>> >
>> > -----------------------------------------------
>> > Scott Kellish
>> > SoftSystem Solutions, LLC
>> > 18 Ridge Road
>> > Clark, NJ 07066
>> >
>> > Voice/Fax: 732.382.1873
>> > Cell: 732.261.5856
>> > ICQ: 161-756-325
>> > E-Mail: skellish@softsystemsolutions.com
>> > Web: www.SoftSystemSolutions.com
>> > -----------------------------------------------
>> >
>> >
>> >
>> >
>> > A friend might well be reckoned the masterpiece of nature. - Ralph
>> > Waldo
>> > Emerson
>> >
>> >
>>
>>
>
>

 

[Guest]

Archived from groups: microsoft.public.windowsxp.general (More info?)

Scott Kellish <skellish@comcast.net> wrote:

> I mentioned that this is a COM server. Do the DLL search path rules
> really apply since the purpose of InProcServer is to provide the path
> to the in-process COM server DLL?

Again, that depends. If the container application is searching the
registry for an InprocServer (using the API function CoCreateInstance()
for instance), Windows loads this library from the path as specified in
the registry. Note that this is a *general* WinXP group. You may want to
submit your relevant code to a programming group.

--
d-d