Wrong COM DLL Loaded Confusion

  • Thread starter Thread starter Scott Kellish
  • Start date Start date
S

Scott Kellish

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: (e-mail address removed)
Web: www.SoftSystemSolutions.com
-----------------------------------------------




A friend might well be reckoned the masterpiece of nature. - Ralph Waldo
Emerson
 
Scott Kellish said:
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.
Click to expand...

If you want to register a DLL not being located in the search path, use
Start > Run: REGSVR32 said:
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?
Click to expand...

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/d...oc/base/dynamic-link_library_search_order.asp
 
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
 
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: (e-mail address removed)
__________________________________________
 
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: (e-mail address removed)
__________________________________________

Jon said:
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 said:
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: (e-mail address removed)
Web: www.SoftSystemSolutions.com
-----------------------------------------------




A friend might well be reckoned the masterpiece of nature. - Ralph Waldo
Emerson
Click to expand...
Click to expand...
 
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 said:
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: (e-mail address removed)
__________________________________________

Jon said:
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 said:
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: (e-mail address removed)
Web: www.SoftSystemSolutions.com
-----------------------------------------------




A friend might well be reckoned the masterpiece of nature. - Ralph
Waldo
Emerson
Click to expand...
Click to expand...
Click to expand...
 
Scott Kellish said:
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?
Click to expand...

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.
 
Back
Top