A customer reported that several of their applications
stopped working after they installed a third-party
program, let's call it Contoso Deluxe.
They found that the Contoso Deluxe program,
as part of its installation,
rewrote some CLSID registrations.
For example,
HKEY_
is normally
%SystemRoot%\,
but installing Contoso Deluxe changes it to
C:\Program Files\.
The customer wanted to understand the significance of this change.
The significance of this change is that the Contoso Deluxe program
hijacked a bunch of objects that normally belong to the
MSXML3.DLL that comes with the operating system,
redirecting requests for those object to the private copy of
MSXML3.DLL that comes with the Contoso Deluxe program.
I have two theories for why the Contoso Deluxe program does this.
The
more charitable theory
is that the developers wanted to redistribute
MSXML3.DLL and didn't know that there were
specific instructions on how to do it correctly.
Instead, they just packaged the DLL with their program and blasted
the registry keys as part of installation.
If that's the case, then they should have followed the
installation and redistribution instructions,
so that the MSXML3.DLL file gets installed properly.
Part of that proper installation is "If you see an
existing copy of MSXML3.DLL that is newer than the
one you are trying to install, then use the existing copy."
Another theory is that the developers found some sort of problem
with newer versions of MSXML3.DLL and decided to
solve the problem by locking
their program to a specific version of MSXML3.DLL
by packaging it with the program and directing all MSXML objects
to their private copy of MSXML3.DLL.
If that were indeed their intention, then they tried to apply
a global solution to a local problem.
Because what they did was redirect all MSXML objects
for all applications in the system to their private
copy of MSXML3.DLL,
even though they really wanted to redirect the object
only for their program.
The proper way to do this is to use an application manifest
and registration-free COM to redirect the classes just
for their program.
(Of course, the real proper way to solve the problem is
to figure out why their program doesn't work with
newer versions of MSXML3.DLL.)
Note also that a private copy of MSXML3.DLL will
not get serviced by Windows Update,
which means that machines with that private copy will not receive
security fixes to MSXML3.DLL.
(More accurately, they will receive security fixes to
C:\,
which is useless because the system is using
C:\Program Files\.)
We advised the customer to engage with Contoso
and work with them to fix the Contoso Deluxe program
so that it neither breaks every program that uses MSXML3.DLL,
nor prevents Windows Update from fixing security issues
in
MSXML3.DLL.