It occurs to me that the WinSxs solution of leaving every version a DLL on the machine for compatibility reasons, is a security hole. If version XXX has a security problem, and it's still in WinSxs after a security update, then couldn't a malicious program somehow use .dll.local or some technique to force it to be used? Am I missing something that mitigates the security issue of leaving known exploitable dlls on the system?

If some app explicitly wants to use an old version, there's nothing we can do to prevent it. After all, even if there were no old version under WinSxS directory, what could prevent the program from bringing that old version with itself? (I mean, to install the old version of the DLL to the program installation folder). Obvjously, a well-behaving program should never seek any DLL (old or new) under WinSxS. Instead, it should look for the current version of the DLL where it belongs to (e.g. System32 or whatever).

If some app explicitly wants to use an old version, there's nothing we can do to prevent it. After all, even if there were no old version under WinSxS directory, what could prevent the program from bringing that old version with itself? (I mean, to install the old version of the DLL to the program installation folder). Obvjously, a well-behaving program should never seek any DLL (old or new) under WinSxS. Instead, it should look for the current version of the DLL where it belongs to (e.g. System32 or whatever).

Fair enough I guess. I would feel unsafe having known exploitable code on my machine. I think it should be the case via some 3rd party tool that the known-unsafe code could be purged from winsxs when updates happen, and if stuff breaks stuff breaks as it should, rather than potentially allow exploitable code to be executable on a patched system.