winsxs

• Pourquoi tous ces répertoires ?
  
• Pourquoi tous ces fichiers ?
  
• Peut-on réduire la taille de WinSxS ?
  
• Peut-on détruire le répertoire WinSxS ?
  
• Peut-on déplacer le répertoire WinSxS vers une autre partition / un autre support ?
  

Pour des raisons de simplification de son écriture et de sa maintenance, Windows utilise un assemblage de composants, chacun ayant une fonction bien définie et une maintenance plus facile (un composant pouvant être constitué de plusieurs fichiers).

Initialement, les Dlls étaient simplement stockées dans un répertoire commun à toutes les applications, mais certaines applications se permettaient de modifier / mettre à jour une Dll en écrasant la version précédente, lors d'une installation ou une mise à jour, mettant en péril toutes les autres applications utilisant cette Dll, ainsi que le système Windows lui-même.

Microsoft a introduit le concept d'assemblage " Side-by-Side " (SxS) dès Windows XP (la notion de DLL étant formalisée à partir de Windows 95 et la notion de liens dynamiques ( édition des liens ) remontant, elle, au tout début de Windows, dès la version 1.0 en 1985 - la première version publique étant la 1.01 du 20 novembre 1985).

La taille de Windows a simplement basculé, en grande partie, vers un magasin de composants : WinSxS. C'est juste une histoire de vases communiquants. Windows est plus petit et WinSxS est apparu. La taille totale reste constante (à ceci prêt que les versions successives de Windows sont de plus en plus grosses).

La taille de WinSxS devrait faire environ la moitié de la taille totale de Windows. Ceci est vérifié deux fois, ci-après :

Répartition du poids des répertoires constituant Windows selon WinVistaClub
WinSxS est le magasin de tous les composants Windows
ce qui représente la moitié de la taille totale de Windows

Sur une machine en 2012	Sur la même machine, en 2013	Sur la même machine, en 2015
Répartition du poids des répertoires constituant Windows 7 Ultimate sur une machine d'Assiste Utilisation du logiciel WinDirStat WinSxS est le magasin de tous les composants Windows, ce qui représente la moitié de la taille totale de Windows

Répartition du poids des répertoires constituant Windows 7 Ultimate sur une machine d'Assiste
WinSxS mis en évidence

Chaque composant a un nom unique qui inclu
la version, la langue et l'architecture processeur
pour lesquels il a été développé.

WinSxS est l'unique endroit où sont réellement stockés les composants du système. Toutes les autres instances de composants, vues à travers les autres répertoires, sont des projections, par des liens symboliques (autrefois appelés " liens en dur " (hard links) mais étendu au multi-volumes et multi-systèmes de fichiers). C'est aussi l'une des raisons pour lesquelles il ne vous est plus demandé d'insérer un média lors de l'utilisation de la commande SFC (System File Checker).

Le dossier WinSxS est donc un « réservoir » (un « magasin ») où Windows stocke tous les composants, dont ceux appelés « DLLs », en plusieurs exemplaires apparents (en réalité, il s'agit de « liens symboliques », un par application utilisant le composant), afin de permettre aux diverses applications utilisant la même « DLL », enfin..., une DLL portant le même nom, de s’exécuter sans problème. WinSxS coordonne les différentes versions des DLLs (les DLLs portant le même nom).

S'il manque une DLL, vous risquez de ne plus pouvoir utiliser l'une de vos applications, voire de ne plus pouvoir du tout exécuter Windows.

Pourquoi ? Et, tout d'abord, que sont les DLLs ?

Que sont les ressources communes trouvées dans WinSxS, en particulier les « DLLs » (les « DLLs » ne sont pas les seules ressources communes (partagées) présentes dans WinSxS) ?

Les « DLLs » (Dynamic Link Library) (bibliothèque de liaisons dynamiques) sont des fonctionnalités standards se traduisant par des composants (bouts de programmes standards), exécutant une fonction spécifique courante que l'on va retrouver dans de nombreuses applications. La notion de composants logiciels (une brique logiciel) liés à une architecture logiciel de plus haut niveau (une application) existe depuis toujours, sous divers noms. C'est le concept du DRY (Don’t Repeat Yourself - Ne vous répétez pas).

Les DLLs sont fournies par les éditeurs de logiciels, Microsoft bien entendu, et les grands éditeurs produisant de nombreuses applications (Adobe etc. ...).

1. Premier avantage des DLLs :
   Lorsqu'un développeur écrit une application, il a intérêt à utiliser des briques de code (exemple : les « DLLs ») toutes faites pour accélérer son développement.
   
   
2. Second avantage des DLL :
   Le programmeur est censé s'appuyer sur du code normalement déjà bien stable (débugué).
   
   
3. Troisième avantage des DLLs :
   Le « poids » d'une l'application développée en utilisant des DLLs est plus petit. De nombreuses fonctions ne sont représentées que par un appel à une fonctionnalité standard, externe au programme, qui sera mise à disposition du programme (« montée en mémoire ») par un mécanisme du système d'exploitation (techniquement, c'est une phase de post compilation (traduction du code écrit par le programmeur en un code exécutable par un ordinateur), appelée « Edition des liens » (Link Edit), qui introduit, dans le code de l'application, les appels aux bibliothèques externes).
   
   
4. Quatrième avantage des DLLs :
   Le mécanisme du système d'exploitation vérifie si la ressource (la DLL) est déjà montée en mémoire, appelée par une autre application et, si ce n'est pas le cas, il la fait monter en mémoire et donne l'adresse RAM du point d'entrée de la ressource à l'application qui l'appelle. Ainsi, on comprend qu'une ressource disponible sous forme de DLL ne monte qu'une fois en RAM et est mise à disposition de plusieurs applications.
   
   
5. Cinquième avantage des DLLs :
   Elles favorisent une technique de développement architectural des applications dites « modulaires », ce qui est, intellectuellement et pratiquement, très satisfaisant.
   

Donc, les DLLs, c'est génial... Cela ne présente que des avantages (lire : DRY (« Don’t Repeat Yourself » - « Ne vous répétez pas »)) !

On peut voir quelles sont les DLLs utilisées par une application (et autres composants externes), et, éventuellement, rechercher quelles sont les DLLs et autres dépendances manquantes, avec Dependency Walker.

Les notions de « composants liés à l'architecture d'un programme principal », au moment de sa « post compilation » (phase dite d' « édition des liens »), existe depuis la nuit des temps informatiques.

J'utilisais des éditeurs de liens sur IBM 360 au tout début des années 1970. La dixième édition de ce document d'IBM sur l'édition des liens sous l'OS des IBM 360 remonte à 1972 !

Dans Windows, la notion de composants remonte au tout début de Windows, dès sa version 1.0, en 1985. L'enfer des DLLs conduira Microsoft à réagir avec un magasin de composants contenant toutes les formes de composants utilisées, dont les DLLs. Ce magasin prend le nom de WinSxS, à partir de Windows Vista.

Ce magasin sera protégé, ne pouvant être manipulé que par des applications elligibles au compte utilisateur spécial « TrustedInstaller » et à travers une procédure particulière.

L'utilisateur descend dans l'enfer des DLL, le fameux « DLL Hell », dès qu'une DLL est manquante ou ne répond plus à ce que l'on attend d'elle :

• Effacée par un désinstalleur d'une application, sans tenir compte du fait que la DLL pouvait servir à d'autres applications. C'est la faute à d'innombrables désinstalleurs d'applications et à d'innombrables utilitaires inutiles et dangereux, prétendant nettoyer le Registre Windows pour accélérer votre ordinateur - Ne touchez jamais au Registre Windows.
  
  
• Modifiée, en partant certainement d'une bonne intention, par un éditeur de logiciel qui a « amélioré » une DLL, faisant, par la même occasion, chutter toutes les autres applications qui utilisent cette DLL et qui ont absolument besoin de l'ancienne version.
  

DLL Hell est un nom désignant un ensemble de problèmes rencontrés avec le concept de DLL sous Windows dont les problèmes de conflits de versions, de DLL manquante, de DLLs dupliquées, de DLL pas, plus ou mal enregistrée dans le Registre Windows, etc. ... Pourquoi ?

1. Parce qu'une application a été mise au point à un moment donné, avec une version précise de chaque DLL qu'elle utilise, mais que, depuis, les petits malins, fournisseurs de DLL, comme Microsoft, Adobe et compagnie, on ré-écrit leurs DLLs pour qu'elles fassent le job mieux et plus vite. Un jour, à l'occasion d'une installation ou d'une mise à jour d'un logiciel quelconque, l'ancienne DLL et remplacée par sa mise à jour et... plusieurs des applications qui utilisent cette DLL ne fonctionnent plus. Prenons un exemple : L'application 1 et l'application 2 se partageaient la même DLL. Un jour, l'application 1 est mise à jour et cette mise à jour comporte également la mise à jour de la DLL partagée avec l'application 2. Depuis ce jour, l'application 2, qui necessite l'ancienne version de la DLL, ne fonctionne plus ! C'est l'enfer (l'éditeur de l'application 2 n'existe plus ou se fiche complètement de cette vieille application qu'il n'a pas l'intention de mettre à jour, ou parle une langue que vous êtes incapable d'utiliser pour lui expliquer le problème, etc. ...) !
   
   
2. Parce qu'un désinstalleur d'une application, ou une de ces innombrables applications imbéciles de nettoyage et accélération du Registre Windows (je promets, depuis des années, de mettre TOUTES ces applications, toutes menteuses, d'accélération de Windows par le nettoyage et la réorganisation du Registre Windows, dans la Crapthèque), a purement et simplement désinscrit la DLL, voire a carément détruit le fichier !
   Ne touchez jamais au Registre Windows !
   Ne touchez jamais au registre Windows.
   
   Le problème des « DLLs partagées » (Shared DLLs et compteur de partages)
   Lorsqu'une DLL est inscrite dans le Registre Windows avec une première application qui l'utilise, son inscription est affublée d'un compteur de partage mis à 1 (dans une valeur de type Dword dans le Registre Windows). Lorsqu'une nouvelle application est installée, utilisant la même DLL, celle-ci n'est pas ré-inscrite mais son compteur de partage augmente de +1. Lorsqu'une application est désinstallée, les compteurs des DLLs qu'elle partage avec d'autres applications sont diminués (-1). Lorsque ce compteur arrive à zéro, on estime que la DLL n'est plus utilisée par aucune application. En théorie, mais en théorie seulement, non seulement la DLL n'est plus partagée mais elle est devenue inutile. La DLL peut être désinscripte, et même détruite pour gagner de la place. Un de ces utilitaires inutiles (qui devraient être interdits), de nettoyage et prétendue accélération de Windows par la réorganisation du Registre Windows, va s'en apercevoir et va effectivement désinscrire la DLL et détruire son fichier, risquant d'anéantir le fonctionnement d'autres applications qui ne s'inscrivent pas dans le Registre Windows pour fonctionner ou n'inscrivent pas leurs utilisations de DLLs. En plus, pour une raison ou pour une autre (coupure de courant, plantage du système etc. ...), les compteurs de partage peuvent se retrouver à zéro de manière totalement erronée. Ne touchez pas aux DLLs et ne les détruisez jamais ! Ecoutez nos mises en garde et ne donnez pas raison au virus PEBCAK.
   Ne touchez jamais à votre Registre Windows !
   Ne touchez jamais à votre Registre Windows.
   
   
3. Parce qu'une DLL peut exister sous plusieurs versions simultanées (et il n'y a pas que la notion de version 16 bits, 32 bits et 64 bits).
   
   
4. Parce que l'éditeur du logiciel qui ne fonctionne plus a disparu et que le logiciel ne fonctionnera plus jamais. Si personne ne dispose des codes sources pour relancer une compilation et une édition des liens (« link edit »), avec les DLLs mises à jour, le logiciel est définitivement mort sauf à trouver les DLLs d'origine et à les copier dans le répertoire même où est installée l'application.
   

Un peu après WinSxS (à partir de Windows Server 2008) est apparu WRP (Windows Resource Protection) qui empêche tout remplacement des fichiers, répertoires et clés du Registre Windows essentiels au fonctionnement de Windows.

Les permissions totales d'accès pour modifier les ressources protégées par WRP (Windows Resource Protection)
sont restreintes au compte utilisateur spécial appelé TrustedInstaller, qui a un contrôle total sur ces ressources

Les permissions totales d'accès pour modifier les ressources protégées par WRP (Windows Resource Protection) sont restreintes au compte utilisateur spécial appelé TrustedInstaller, qui a un contrôle total sur ces ressources, et ces ressources ne peuvent être modifiées qu'en utilisant un mécanisme appelé « Supported Resource Replacement Mechanisms » applicable aux installations des :

• Service packs Windows et Service Release installés sous le compte TrustedInstaller
  
• HotFixex installés sous le compte TrustedInstaller
  
• Upgrades installés sous le compte TrustedInstaller
  
• Updates installés sous le compte TrustedInstaller
  

On remarquera que, aussi loin que l'on puisse chercher sur le site de Microsoft ou sur technet.com, il n'est jamais question de vider ou alléger WinSxS, ni d'effacer des DLLs ou des assemblages. C'est la contrepartie de toute la sécurité imposée autour des DLLs auxquelles, justement, il n'est pas question de toucher.

WinSxS est, depuis Windows 95, la réponse de Microsoft aux cauchemardesques problèmes de plantage (« Écrans bleus de la mort » ou petite fenêtre avec ce laconique message "DLL pas trouvée") pour cause d'incompatibilités entre DLLs.

Une application, lors de son installation, fige désormais dans le répertoire WinSxS les versions de DLLs avec lesquelles elle a été testée et avec lesquelles elle est livrée et fonctionnelle. Si des mises à jour d'une DLL interviennent par la suite, ces mises à jour n'affecteront pas l'application déjà installée.

Une dépendance est créée et est inscrite dans la base de registre : l'application est désormais dépendante de l'existance de cette version précise de la DLL, dans le répertoire WinSxS.

Ceci sert également, mais beaucoup plus discrètement, à régler une incompétence architecturale des processeurs Intel et de Windows. Ce couple « WinTel » infernal est incapable de n'avoir qu'un seul segment de code commun, monté une seule fois en mémoire, au service de toutes les tâches l'utilisant. Il y a autant de copies de la « DLL » montées en mémoire (“Side-by-Side” – « Côte à côte ») que de tâches l'exploitant. Cette technologie existe pourtant, depuis bien avant les PC, sous le nom de « réentrance ». Il n'y a que les DLL ne manipulant pas de données applicatives qui peuvent n'être présente qu'une fois en mémoire, mais ceci s'oppose au point suivant.

Ceci sert enfin à tenter de régler un problème récurent d'irrespect des frontières des zones mémoire RAM d'une tâche par une autre tâche (Stack overflow). Le confinement (isolement) de chaque tâche à son espace mémoire (mode protégé), sans violation de ses frontières, semble très difficile à obtenir sous WinTel.

Il y a également autant de copies de cette même DLL dans le répertoire WinSxS qu'il y a eu de programmes l'ayant utilisée un jour, chaque copie étant classée dans un sous-répertoire de WinSxS. Mais, dans la réalité, il n'y a qu'un seul exemplaire d'une version particulière d'une DLL, les autres ne sont que des apparences, des projections à l'aide de lien symboliques.

30 copies de la DLL IESHIMS.DLL sont présentes dans ce répertoire WinSxS, alors que seules 3 versions de cette DLL existent.

Si vous installez de nombreux programmes, pour les tester par exemple, le répertoire WinSxS va être explosif et il faut utiliser un désinstalleur professionnel comme Revo Uninstaller ou Total Uninstall.

Dirigez-vous vers le répertoire C:\Windows\winsxs et regardez le contenu de ses sous-répertoires. Vous allez y trouver des fichiers, « n » fois, sous le même nom, et avec exactement le même contenu. Vous pouvez le vérifier en utilisant un outil comme « SummerProperties » ou « HashTab » pour calculer les « sommes de contrôle » (« condensat » ou « hashcode ») et vous assurer que ce sont strictement les mêmes, au bit près).

Vider ou ne pas vider le répertoire WinSxS ? Là est la question.

Compte tenu de ce qui vient d'être dit ci-dessus, tout le monde à compris que le répertoire WinSxS est l'aveu des éditeurs de DLL, dont Microsoft, que le principe est beau sur le papier mais ne fonctionne absolument pas dans la réalité. Chaque application utilise ses propres versions de DLL standards, ce qui est la négation même de la notion de standard !

Sauf cas exceptionnel où toutes les applications sur un ordinateur proviendraient du même éditeur et d'aucun autre, et que toutes soient mises sur le marché au même moment, donc avec les mêmes versions de DLL pour toutes les applications, cas de figure qui n'existe pas, IL NE FAUT PAS TOUCHER à WinSxS !

En cas de disparition d'une entrée dans le répertoire WinSxS, la dépendance d'une application aux ressources qui doivent, normalement, se trouver dans le répertoire WinSxS, risque de rendre l'application inutilisable. Windows va tenter de trouver des ressources portant le même nom, ailleurs, mais le risque de version incompatible de la ressource existe et le résultat sera le même : application inutilisable.

Dès 2001, dans un article, Microsoft écrivait "...les composants côte à côte (Side-by-Side dans WinSxS) sont le futur du développement de Windows". Et WinSxS arriva avec Windows XP !...

Dans un article d'octobre 2012, Microsoft écrivait que l'isolement des applications et les assemblages côte à côte (Side-by-Side dans WinSxS) sont une solution Microsoft Windows pour réduire les problèmes de conflits de versions. Microsoft écrit bien "réduire" et non pas "supprimer".

La nouvelle solution de Microsoft, uniquement pour les applications développées avec le langage de programmation Visual C++, est les "assemblys" de Microsoft .NET Framework. Les ressources "standards" sont assemblées dans l'application elle-même, réglant ainsi définitivement le problème dit "DLL HELL" (ne concerne que les applications développées avec le langage de programmation Microsoft Visual C++ et faisant appel à l'usine à gaz Microsoft .NET Framework).

NE TOUCHEZ PAS à WinSxS ou retombez dans le DLL HELL ! Le seul moyen de toucher à ce répertoire et de désinstaller une application complètement avec Revo Uninstaller ou Total Uninstall.

Il est possible d'alléger tout de même WinSxS, de manière sûre, en nettoyant les fichiers de sauvegarde inutiles après installation d'un Service Pack.

Longtemps après avoir installé un Service Pack, s'il s'avère que tout est stable, il est possible de virer les fichiers d'installation de ce Service Pack.

Il ne s'agit pas d'utiliser "Ajout/Suppression de programme" (ou "Programmes et fonctionnalités" dans les versions plus récentes de Windows).

1. Faire de la place dans WinSxS de Windows 7 SP 1 ou Windows Server 2008 R2 SP 1 installé - méthode 1
   Il faut utiliser une commande sous un compte administratif (ou avec demande d'élévation de privilèges - "Exécuter en tant qu'administrateur"). Cette commande va, entre autres choses, alléger WinSxS de certaines copies de composants ( DLLs...) sauvegardées sous l'inscription du Service Pack.
   Ouvrir une « Invite de commande » en tant qu'administrateur
   

2. Vérifier, sous Windows Vista, Windows 7, Windows 8, Windows 10, que la fenêtre de l' « invite de commande » soit bien en mode « Administrateur » en regardant l'indication du mode d'exécution dans sa barre de titre.

   
   Sous Windows Vista et suivants, ouverture d'une « invite de commande » avec privilèges d'administration
   

3. Saisir l'une des commandes suivantes :
   (Comprendre : spsuperseded = Service Pack remplacé)

   • Si l'installation s'est faite en ligne (online), utiliser la commande :
     dism /online /cleanup-image /spsuperseded
     
     
   • Si l'installation s'est faite hors ligne (avec un Service Pack redistribuable), utiliser la commande :
     DISM.exe /Image:C:\test\offline /Cleanup-Image /spsuperseded /hidesp
     
   
   Alléger WinSxS en nettoyant les fichiers de sauvegarde inutiles après installation d'un Service Pack
   

   Attendre la fin du travail. Une fois terminé, les fichiers superflus auront été supprimés et, selon ce dont il s'agissait, vous aurez récupéré un espace disque pouvant se mesurer à quelques gigas octets !

4. Faire de la place dans WinSxS de Windows 7 SP 1 ou Windows Server 2008 R2 SP 1 installé - Méthode 2
   

   Utilisez la fonction de Windows : Nettoyage de disque (assistant cleanmgr.exe de Windows)

5. Faire de la place dans WinSxS de Windows Vista SP 2 ou Windows Server 2008 SP 2 installé
   Le Service Pack SP2 de Windows Vista contenait un outil spécifique à ce Service Pack et à Windows Vista, appelé Vista SP2 Service Pack Clean-up tool (Compcln.exe). Cet outil efface définitivement les fichiers des mises à jour versions RTM et SP1 de Windows Vista. Il ne sera donc plus possible de revenir en arrière (il ne sera plus possible de désinstaller le Service Pack SP2 de Vista pour revenir à une situation SP1) puisque les fichiers de l'état antérieur de Windows auront été détruits.
   
   L'outil doit s'exécuter dans une invite de commande (Démarrer > Tous les programmes > Accessoires > Invite de commande)
   La commande à exécuter s'appelle compcln.exe
   Elle se trouve à c:\Windows\System32\compcln.exe
   
   
6. Faire de la place dans WinSxS de Windows Vista SP 1
   Le Service Pack SP1 de Windows Vista contenait vsp1cln.exe (même usage que compcln.exe de Vista SP 2), à utiliser après installation du SP1 de Vista.
   
   
7. Faire de la place dans WinSxS de Windows 8.1 et Windows Server 2012 R2
   https://msdn.microsoft.com/fr-fr/library/dn251565.aspx
   https://windows.microsoft.com/fr-fr/windows-8/free-up-disk-space
   
   
8. Faire de la place dans WinSxS de Windows 10
   https://www.msnloop.com/reduire-la-taille-du-dossier-winsxs-sur-windows-10/
   

C'est tout ! Ne tentez rien d'autre. Ne supprimez rien manuellement dans WinSxS.

Il n'est pas possible de déplacer le répertoire WinSxS sur un autre volume que le volume système en raison des liens réels NTFS..