I stay with "Spy" !!

Best Regards !

COMCTL32.DLL is a system binary and is not supposed to be redistributed by developers. Microsoft should have no expectation to have to find copies of the DLL located anywhere other than %SystemRoot%\System32, and the version 6 copies (on XP and 2003) in the WinSXS folder. Version 6 uses manifests and the native assembly binding mechanism to locate the version that the application requests.

I'm actually a little surprised that Microsoft didn't make it one of the KnownDLLs.

Certain system DLLs have dependencies themselves - even inter-DLL dependencies (DLL A requires features from DLL B, which itself requires features from A). Using an older version of A may well not work properly because other components are expecting the matched version.

'DLL Hell' problems have generally arisen, in the past, by developers distributing components they should not have done and thereby getting a mismatched set. The Visual Basic 6 Package & Deployment Wizard was a particular catalyst in this - it would pick up components, from the Windows directory, that were not meant to be redistributed. On older OSs, you'd often find system DLLs from Windows 2000 or Windows XP that had overwritten the correct, matched versions. System File Protection/Windows File Protection mostly did away with this problem.

Setup is a minefield. It needs to be done very carefully.

If you package applications, use merge modules instead of the MS dll's and don't isolate dll's using the conflict management tools in your packaging tool. When using merge modules, a counter is set on a dll to track by how many times it's used by an application.

No need to isolate dll's, when a Microsoft dll is updated, a little later, a new merge module is presented by Wise, Installshield or others. When you the include that merge module in a recent package, it'll replace the existing merge module and thus the older dll.

Although I am sure this article is intended to be helpful, it is a little misleading...

First Wise and Installshield are both using Microsoft's Standard .LOCAL isolation. 

Second, I have had several inquiries about this as well and have told the clients involved to make sure that these security vulnerabilities are fully fleshed out by Microsoft.  For instance, when you isolate using .LOCAL, programs that use shared memory to communicate will fail.  So there is some type of memory isolation implied by .LOCAL - does this also mitigate many of the common methods of code being vulnerable in memory?  I'm not in a position to answer it, but it should be answers to fully qualify this risk.

The statement "Microsoft officially recommends self-registrations when creating packages." directly contradicts the Windows Installer SDK here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/selfreg_table.asp?frame=true

Advertising a package is also adversely affected by self-registration in certain circumstances.  Advertising is how GPO deploys software when it is targeted at Users - so advertising support is an issue for everyone.

Granted the Windows Installer architecture was never intended for repackaging - but the statement that self-registration is always recommended is too broad.

I am not sure if a product manager exists for .LOCAL at Microsoft anymore since it is basically complete.  I will be sending a link to this thread to product managers at Wise and Installshield so that perhaps we can get a full qualification of the risks this issue presents.

.Local isolation by it’s vary nature puts old dlls into individual application folders to assure each application will use the specific version of dlls the programmer developed it to use. While it can be debated as to the extent of the vulnerability that these old dlls pose as they are run in memory, the simple fact that old, unpatched versions of dlls exist on systems with isolated applications should be enough to raise a red flag.

.Local isolation was an ingenious way of providing full application compatibility and as Mr. Sanoy pointed out, Microsoft has a standing SDK supporting the use of .Local isolation. But was this written prior to the security concerns over the recent few years?

As I stated initially, in my meeting last November, several Microsoft technical representatives were consulted by conference call and when asked about the security issues that .local isolation poses, all agreed that security vulnerabilities exist and they recommended that self-registration should be used to build application packages. One of the Microsoft representatives also stated that it would be the responsibility of the individual corporations who are repackaging to assure that any old Microsoft dlls that are placed within packages be patched, much like a vendor would be responsible for security patches to their software.

Many feel that the risk posed by .Local isolation is minimal because of the safety of being behind corporate firewalls and other security measures in place. But let me remind everyone that to this day, Sasser is still alive and well and will infect unpatched systems on corporate networks, behind firewalls within a matter of a few seconds.

The hackers are very smart and we don’t know what future vulnerabilities will be exploited. Isn’t it up to us in the corporate IT departments to take all precautions possible to protect our environments? I wouldn’t want to be caught with some sort of exploit that takes advantage of these old dlls. With every system on a corporate network loaded with potentially several old unpatched dlls, the impact could be devastating.

The intent of my post was not to bash Microsoft, Wise, Installsheild, or anyone else. In the last few years system security has moved from the background into the forefront. My intent was simply to inform everyone of a vulnerability that they may not have known existed.