Jaa

L’activation du mode 32 Bits sous IIS 7.0/7.5 x64 retourne une erreur 500.19 [Enable32BitAppOnWin64]

  • Artikkeli

Bonjour,

J'ai récemment eu l'occasion de traiter un incident sous IIS 7.0 x64 où l'activation de la compatibilité 32 Bits (Fig. 1), sur un application pool spécifique, générait une erreur de type "500.19 - Les données de configuration ne sont pas valides" (Fig. 2).
Le même site web en mode 64bits fonctionnait sans aucun problème.

Fig. 1                                        

Fig. 2

On peut tout de suite voir que le module posant problème est celui de la compression (Dynamique ou Statique en fonction de votre configuration) si vous exécutez la page en local sur votre serveur.
Si vous désactivez la compression, vous obtenez toujours la même erreur. Cela peut simplement s'expliquer par le fait que toute requête s'exécutant sur IIS va passer au travers de tous les modules qui sont installés, même si ceux-ci sont désactivés.

Nous avons donc réalisé un log FREB ("Règles de suivi des demandes ayant échoué" ou "Failed Request Tracing Rules") afin de récupérer quelques informations supplémentaires sur cette erreur :

On peut clairement voir deux messages identiques pour le StaticCompressionModule et le DynamicCompressionModule :

ModuleName : StaticCompressionModule
Notification : 16
HttpStatus : 500
HttpReason : Internal Server Error
HttpSubStatus : 19
ErrorCode : 2147942526
ConfigExceptionInfo :
Notification : MAP_REQUEST_HANDLER
ErrorCode : Le module spécifié est introuvable. (0x8007007e)

Ils indiquent qu'un module n'a pas été trouvé.
Nous avons alors analysé le fichier ApplicationHost.config, qui est le fichier de configuration de IIS situé par défaut dans "C:\Windows\System32\Inetsrv\Config", afin de trouver un fichier qui pourrait poser problème.
La configuration suivante était paramétrée :

<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files">
<scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
<scheme name="xpress" doStaticCompression="false" doDynamicCompression="true" dll="C:\Windows\system32\inetsrv\suscomp.dll" staticCompressionLevel="10" dynamicCompressionLevel="0" />
<dynamicTypes>
<add mimeType="text/*" enabled="true" />
<add mimeType="message/*" enabled="true" />
<add mimeType="application/x-javascript" enabled="true" />
<add mimeType="*/*" enabled="false" />
</dynamicTypes>

Il est tout de suite visible qu'une DLL est renseignée. Cette DLL est une version 64 Bits, alors que le processus est exécuté en 32 Bits.
En supprimant la ligne suivante, l'exécution en 32 Bits ne pose maintenant plus aucun problème :

<scheme name="xpress" doStaticCompression="false" doDynamicCompression="true" dll="C:\Windows\system32\inetsrv\suscomp.dll" staticCompressionLevel="10" dynamicCompressionLevel="0" />

Il semble qu'il existe une autre solution mais je ne l'ai pas testée. Je vous l'indique donc sans aucune garantie.
Il serait possible de récupérer la version 32 Bits de la DLL suscomp.dll via une installation 32 Bits de WSUS. Il suffirait ensuite de renseigner l'emplacement de la DLL 32 Bits pour que cela fonctionne.
Le forum suivant parle de cette solution : https://forums.iis.net/t/1149768.aspx

@ Bientôt
Sylvain Lecerf et L'équipe de support IIS Microsoft France