Résoudre les problèmes de déploiement d'EC2/sur site

Note

Les causes de nombreux échecs de déploiement peuvent être identifiées en passant en revue les fichiers journaux créés pendant le processus de déploiement. Pour des raisons de simplicité, nous vous recommandons d'utiliser Amazon CloudWatch Logs pour surveiller les fichiers journaux de manière centralisée au lieu de les consulter instance par instance. Pour plus d'informations, voir Afficher CodeDeploy les CloudWatch journaux dans la console Logs.

Astuce

Pour un runbook qui automatise de nombreuses tâches de dépannage liées aux déploiements EC2/sur site, voir - dans AWSSupportle manuel de référence du runbook TroubleshootCodeDeploy Systems Manager AWS Automation.

CodeDeploy erreur d'identification CommandPoller manquante dans le plugin

Si vous recevez une erreur similaire à InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile, elle peut être provoquée par l'une des causes suivantes :

• Aucun profil d'instance IAM n'est associé à l'instance sur laquelle vous effectuez le déploiement.

• Les autorisations configurées pour votre profil d'instance IAM ne sont pas correctes.

Un profil d'instance IAM autorise l' CodeDeploy agent à communiquer avec CodeDeploy et à télécharger votre révision depuis Amazon S3. Pour les instances EC2, veuillez consulter Gestion des identités et des accès pour AWS CodeDeploy. Pour les instances sur site, consultez Working with On-Premises Instances.

Le déploiement échoue et un message s'affiche indiquant l'échec de la validation du message PKCS7 signé

Ce message d'erreur indique que l'instance exécute une version de l' CodeDeploy agent qui prend uniquement en charge l'algorithme de hachage SHA-1. Support de l'algorithme de hachage SHA-2 a été introduit dans la version 1.0.1.854 de l' CodeDeploy agent, publiée en novembre 2015. À compter du 17 octobre 2016, les déploiements échouent si une version de l' CodeDeploy agent antérieure à 1.0.1.854 est installée. Pour plus d'informations, voir pour passer AWS à l'algorithme de hachage SHA256 pour les certificats SSL, REMARQUE : retrait des agents CodeDeploy hôtes antérieurs à la version 1.0.1.85, et. Mettre à jour l' CodeDeploy agent

Le déploiement ou redéploiement des mêmes fichiers sur les mêmes emplacements d'instance échoue avec l'erreur « Le déploiement a échoué car un fichier spécifié existe déjà à l'emplacement »

Lorsque CodeDeploy vous essayez de déployer un fichier sur une instance mais qu'un fichier portant le même nom existe déjà à l'emplacement cible spécifié, le déploiement vers cette instance peut échouer. Vous pouvez recevoir le message d'erreur « Le déploiement a échoué car un fichier spécifié existe déjà à l'emplacement suivant : nom-emplacement. » Cela est dû au fait que, lors de chaque déploiement, il supprime d' CodeDeploy abord tous les fichiers du déploiement précédent, qui sont répertoriés dans un fichier journal de nettoyage. Si certains fichiers des dossiers d'installation cibles ne sont pas répertoriés dans ce fichier de nettoyage, l' CodeDeploy agent interprète par défaut cela comme une erreur et échoue au déploiement.

Note

Sur les instances Amazon Linux, RHEL et Ubuntu Server, le fichier de nettoyage se trouve dans. /opt/codedeploy-agent/deployment-root/deployment-instructions/ Sur les instances Windows Server, l'emplacement estC:\ProgramData\Amazon\CodeDeploy\deployment-instructions\.

Le moyen le plus simple d'éviter cette erreur est de spécifier une option autre que le comportement par défaut qui consiste à faire échouer le déploiement. Pour chaque déploiement, vous pouvez choisir de faire échouer le déploiement, de remplacer les fichiers non répertoriés dans le fichier de nettoyage ou de conserver les fichiers déjà présents sur l'instance.

L'option de remplacement est utile quand, par exemple, vous avez placé manuellement un fichier sur une instance après le dernier déploiement, mais que vous avez ensuite ajouté un fichier du même nom à la révision de l'application suivante.

Vous pouvez choisir l'option de conservation pour les fichiers que vous placez sur l'instance et dont vous souhaitez qu'ils fassent partie du prochain déploiement sans avoir à les ajouter au package de révision de l'application. L'option de conservation est également utile si les fichiers de votre application se trouvent déjà dans votre environnement de production et que vous souhaitez les déployer CodeDeploy pour la première fois. Pour plus d’informations, consultez Création d'un déploiement de plate-forme de calcul EC2/sur site (console) et Comportement d'annulation avec du contenu existant.

Résolution des erreurs de déploiement The deployment failed because a specified file already exists at this location

Si vous choisissez de ne pas spécifier d'option permettant de remplacer ou de conserver le contenu CodeDeploy détecté dans vos emplacements de déploiement cibles (ou si vous ne spécifiez aucune option de déploiement pour gérer le contenu existant dans une commande de programmation), vous pouvez choisir de résoudre l'erreur.

Les informations suivantes s'appliquent uniquement si vous choisissez de ne pas conserver ou de remplacer le contenu.

Si vous essayez de redéployer des fichiers portant les mêmes noms et emplacements, le redéploiement a plus de chances de réussir si vous spécifiez le nom de l'application et le groupe de déploiement avec le même ID de groupe de déploiement sous-jacent que celui que vous avez utilisé auparavant. CodeDeploy utilise l'ID du groupe de déploiement sous-jacent pour identifier les fichiers à supprimer avant un redéploiement.

Le déploiement de nouveaux fichiers ou le redéploiement des mêmes fichiers aux mêmes emplacements sur les instances peut échouer pour les raisons suivantes :

• Vous avez spécifié un nom d'application différent pour un redéploiement de la même révision sur les mêmes instances. Le redéploiement échoue parce que, même si le nom du groupe de déploiement est le même, l'utilisation d'un nom d'application différent signifie qu'un autre ID de groupe de déploiement sous-jacent est utilisé.

• Vous avez supprimé et recréé un groupe de déploiement pour une application, puis essayé de redéployer la même révision dans le groupe de déploiement. Le redéploiement échoue car même si le nom du groupe de déploiement est identique, il CodeDeploy fait référence à un identifiant de groupe de déploiement sous-jacent différent.

• Vous avez supprimé une application et un groupe de déploiement dans CodeDeploy, puis vous avez créé un nouveau groupe d'applications et de déploiement portant les mêmes noms que ceux que vous avez supprimés. Après cela, vous avez essayé de redéployer une révision qui avait été déployée dans le groupe de déploiement précédent vers le nouveau groupe portant le même nom. Le redéploiement échoue car même si les noms de l'application et du groupe de déploiement sont identiques, ils font CodeDeploy toujours référence à l'ID du groupe de déploiement que vous avez supprimé.

• Vous avez déployé une révision dans un groupe de déploiement, puis déployé la même révision dans un autre groupe de déploiement sur les mêmes instances. Le second déploiement échoue car il fait CodeDeploy référence à un ID de groupe de déploiement sous-jacent différent.

• Vous avez déployé une révision dans un seul groupe de déploiement, puis déployé une autre révision dans un autre groupe de déploiement sur les mêmes instances. Il existe au moins un fichier portant le même nom et situé au même emplacement que le second groupe de déploiement tente de déployer. Le deuxième déploiement échoue car CodeDeploy le fichier existant n'est pas supprimé avant le début du deuxième déploiement. Les deux déploiements référencent des ID de groupe de déploiement différents.

• Vous avez déployé une révision dans CodeDeploy, mais il existe au moins un fichier portant le même nom et au même emplacement. Le déploiement échoue car, par défaut, CodeDeploy le fichier existant n'est pas supprimé avant le début du déploiement.

Pour traiter de telles situations, effectuez l'une des actions suivantes :

• Supprimez les fichiers des emplacements et des instances vers lesquels ils ont été précédemment déployés, puis réessayez d'effectuer le déploiement.

• Dans AppSpec le fichier de votre révision, que ce soit dans les événements du cycle de vie ApplicationStop ou de BeforeInstall déploiement, spécifiez un script personnalisé pour supprimer les fichiers dans tous les emplacements correspondant aux fichiers que votre révision est sur le point d'installer.

• Déployez ou redéployez les fichiers à des emplacements ou sur des instances qui ne faisaient pas partie des déploiements précédents.

• Avant de supprimer une application ou un groupe de déploiement, déployez une révision contenant un AppSpec fichier ne spécifiant aucun fichier à copier sur les instances. Pour le déploiement, spécifiez le nom de l'application et le nom du groupe de déploiement qui utilisent les mêmes ID de groupe de déploiement et d'application sous-jacents que ceux que vous êtes sur le point de supprimer. (Vous pouvez utiliser la get-deployment-groupcommande pour récupérer l'ID du groupe de déploiement.) CodeDeployutilise l'ID et le AppSpec fichier du groupe de déploiement sous-jacents pour supprimer tous les fichiers installés lors du précédent déploiement réussi.

Les longs chemins de fichier provoquent des erreurs « Aucun fichier ou répertoire de ce type »

Pour les déploiements sur des instances Windows, si le chemin du fichier appspec.yml contient un chemin de fichier supérieur à 260 caractères dans la section fichiers de votre fichier appspec.yml, les déploiements peuvent échouer avec une erreur similaire à la suivante :

No such file or directory @ dir_s_mkdir - C:\your-long-file-path

Cette erreur se produit parce que Windows n'autorise pas par défaut les chemins de fichiers supérieurs à 260 caractères, comme indiqué dans la documentation de Microsoft.

Pour les versions 1.4.0 ou ultérieures de l' CodeDeploy agent, vous pouvez activer les longs chemins de fichiers de deux manières, en fonction du processus d'installation de l'agent :

Si l' CodeDeploy agent n'est pas encore installé :

1. Sur la machine sur laquelle vous comptez installer l' CodeDeploy agent, activez la clé de registre LongPathsEnabled Windows à l'aide de cette commande :

   New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem"
             -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force

2. Installez l' CodeDeploy agent. Pour plus d’informations, consultez Installation de l' CodeDeploy agent.

Si l' CodeDeploy agent a déjà été installé :

1. Sur la machine CodeDeploy agent, activez la clé de registre LongPathsEnabled Windows à l'aide de cette commande :

   New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem" 
   -Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
   

2. Redémarrez l' CodeDeploy agent pour que la modification de la clé de registre soit prise en compte. Pour redémarrer l'agent, utilisez cette commande :

   powershell.exe -Command Restart-Service -Name codedeployagent

Des processus de longue durée peuvent entraîner l'échec des déploiements

Pour les déploiements sur les instances Amazon Linux, Ubuntu Server et RHEL, si vous disposez d'un script de déploiement qui lance un processus de longue durée, vous CodeDeploy risquez de devoir attendre longtemps avant de voir le cycle de vie du déploiement échouer. En effet, si le processus s'exécute plus longtemps que ce que les processus de premier plan et d'arrière-plan sont censés prendre, le déploiement CodeDeploy s'arrête et échoue, même s'il fonctionne toujours comme prévu.

Par exemple, une révision d'application contient deux fichiers à la racine, after-install.sh et sleep.sh. Son AppSpec fichier contient les instructions suivantes :

version: 0.0
os: linux
files:
  - source: ./sleep.sh
    destination: /tmp
hooks:
  AfterInstall:
    - location: after-install.sh
      timeout: 60

Le after-install.sh fichier s'exécute pendant l'événement du cycle de vie de l' AfterInstall application. Voici son contenu :

#!/bin/bash
/tmp/sleep.sh

Le fichier sleep.sh contient le code suivant, qui interrompt l'exécution du programme pendant trois minutes (180 secondes) et simule ainsi un processus de longue durée :

#!/bin/bash
sleep 180

Lorsque l'after-install.shappel sleep.sh sleep.sh démarre et s'exécute pendant trois minutes (180 secondes), soit deux minutes (120 secondes) au-delà de l'heure prévue CodeDeploy sleep.sh (et, par relation,after-install.sh) d'arrêt de l'exécution. Après un délai d'une minute (60 secondes), le déploiement CodeDeploy s'arrête et échoue lors de l'événement du cycle de vie de l' AfterInstall application, même si sleep.sh son exécution se poursuit comme prévu. L'erreur suivante s'affiche :

Script at specified location: after-install.sh failed to complete in 60 seconds.

Vous ne pouvez pas ajouter simplement une esperluette (&) dans after-install.sh pour exécuter sleep.sh en arrière-plan.

#!/bin/bash
# Do not do this.
/tmp/sleep.sh &

Cela peut laisser le déploiement en attente pendant la période d'expiration par défaut d'une heure du cycle de vie du déploiement, après quoi le déploiement CodeDeploy s'arrête et échoue lors de l'événement du cycle de vie de l' AfterInstall application, comme auparavant.

Dansafter-install.sh, appelez sleep.sh comme suit, ce qui permet CodeDeploy de continuer après le début du processus :

#!/bin/bash
/tmp/sleep.sh > /dev/null 2> /dev/null < /dev/null &

Dans l'appel précédent, sleep.sh est le nom du processus que vous voulez commencer à exécuter en arrière-plan, en redirigeant stdout, stderr et stdin vers /dev/null.

Résolution des problèmes liés à un échec AllowTraffic du cycle de vie sans qu'aucune erreur ne soit signalée dans les journaux de déploiement

Dans certains cas, un déploiement bleu/vert échoue pendant l'événement du AllowTraffic cycle de vie, mais les journaux de déploiement n'indiquent pas la cause de l'échec.

Cet échec est généralement dû à des contrôles de santé mal configurés dans Elastic Load Balancing pour le Classic Load Balancer, l'Application Load Balancer ou le Network Load Balancer utilisés pour gérer le trafic du groupe de déploiement.

Pour résoudre le problème, passez en revue et corrigez les erreurs de configuration de la vérification de l'état pour l'équilibreur de charge.

Pour les équilibreurs de charge classiques, consultez la section Configure Health Checks dans le guide de l'utilisateur pour les équilibreurs de charge classiques et ConfigureHealthCheckdans la version 2012-06-01 de référence de l'API Elastic Load Balancing.

Pour les équilibreurs de charge d'application, consultez la section Contrôles de santé de vos groupes cibles dans le guide d'utilisation des équilibreurs de charge d'application.

Pour les Network Load Balancers, consultez la section Health Checks for Your Target Groups dans le guide de l'utilisateur du Network Load Balancer.

Résolution des problèmes liés à un échec ApplicationStop ou à un événement lié AfterBlockTraffic au cycle de vie du déploiement BeforeBlockTraffic

Au cours d'un déploiement, l' CodeDeploy agent exécute les scripts spécifiés pour ApplicationStop et AfterBlockTraffic dans le AppSpec fichier du précédent déploiement réussi. BeforeBlockTraffic (Tous les autres scripts sont exécutés à partir du AppSpec fichier dans le déploiement en cours.) Si l'un de ces scripts contient une erreur et ne s'exécute pas correctement, le déploiement peut échouer.

Les raisons possibles de ces échecs sont les suivantes :

• L' CodeDeploy agent trouve le deployment-group-id_last_successful_install fichier au bon emplacement, mais l'emplacement indiqué dans le deployment-group-id_last_successful_install fichier n'existe pas.

  Sur les instances Amazon Linux, Ubuntu Server et RHEL, ce fichier doit exister dans/opt/codedeploy-agent/deployment-root/deployment-instructions.

  Sur les instances Windows Server, ce fichier doit être stocké dans le C:\ProgramData\Amazon\CodeDeploy\deployment-instructions dossier.

• À l'emplacement indiqué dans le deployment-group-id_last_successful_install fichier, le AppSpec fichier n'est pas valide ou les scripts ne s'exécutent pas correctement.

• Le script contient une erreur qui ne peut pas être corrigée. Il ne réussit donc jamais à s'exécuter.

Utilisez la CodeDeploy console pour déterminer pourquoi un déploiement a pu échouer lors de l'un de ces événements. Sur la page des détails du déploiement, choisissez View Events. Sur la page de détails de l'instance, dans la AfterBlockTrafficligne ApplicationStopBeforeBlockTraffic, ou, choisissez Afficher les journaux. Ou utilisez le AWS CLI pour appeler la get-deployment-instancecommande.

Si l'échec est dû à un script du dernier déploiement réussi qui ne s'exécute jamais correctement, créez un déploiement et spécifiez que les ApplicationStop AfterBlockTraffic échecs doivent être ignorés. BeforeBlockTraffic Il existe deux façons de procéder :

• Utilisez la CodeDeploy console pour créer un déploiement. Sur la page Créer un déploiement, sous Défaillance d'un événement ApplicationStop du cycle de vie, sélectionnez Ne pas échouer le déploiement sur une instance si cet événement du cycle de vie de l'instance échoue.

• Utilisez le AWS CLI pour appeler la create-deployment commande et inclure l'--ignore-application-stop-failuresoption.

Lorsque vous déployez la révision de l'application à nouveau, le déploiement se poursuit même si l'un de ces trois événements du cycle de vie échoue. Si la nouvelle révision inclut des scripts fixes pour ces événements du cycle de vie, les déploiements futurs peuvent réussir sans appliquer ce correctif.

Résolution des problèmes liés à un échec du cycle de vie d'un DownloadBundle déploiement avec UnknownError : non ouvert pour lecture

Si vous essayez de déployer une révision d'application depuis Amazon S3 et que le déploiement échoue pendant l'événement du cycle de vie du DownloadBundle déploiement avec l'UnknownError: not opened for readingerreur suivante :

• Une erreur interne du service Amazon S3 s'est produite. Déployez de nouveau la révision d'application.

• Le profil d'instance IAM de votre instance EC2 n'est pas autorisé à accéder à la révision de l'application dans Amazon S3. Pour plus d'informations sur les politiques relatives aux compartiments Amazon S3, consultez Transférer une révision CodeDeploy pour Amazon S3 (déploiements EC2/sur site uniquement) etConditions préalables au déploiement.

• Les instances vers lesquelles vous déployez sont associées à une AWS région (par exemple, USA Ouest (Oregon)), mais le compartiment Amazon S3 qui contient la révision de l'application est associé à une autre AWS région (par exemple, USA Est (Virginie du Nord)). Assurez-vous que la révision de l'application se trouve dans un compartiment Amazon S3 associé à la même AWS région que les instances.

Sur la page de présentation des événements pour le déploiement, à la ligne Download bundle, choisissez View logs. Ou utilisez le AWS CLI pour appeler la get-deployment-instancecommande. Si cette erreur s'est produite, il devrait y avoir une erreur dans la sortie avec le code d'erreur UnknownError et le message d'erreur not opened for reading.

Pour déterminer la cause de cette erreur :

1. Activez la journalisation avec connexion sur au moins une des instances, puis déployez de nouveau la révision d'application.

2. Examinez le fichier de consignation avec connexion pour trouver l'erreur. Les messages d'erreur courants pour ce problème incluent l'expression « access denied ».

3. Une fois que vous avez examiné les fichiers journaux, nous vous recommandons de désactiver la journalisation avec connexion pour réduire la taille des fichiers journaux et la quantité d'informations sensibles qui peuvent apparaître dans la sortie en texte clair, sur l'instance, à l'avenir.

Pour plus d'informations sur la façon de trouver le fichier d'enregistrement des câbles et d'activer et de désactiver l'enregistrement des câbles, reportez-vous :log_aws_wire: à la section Référence de configuration de CodeDeploy l'agent.

Résolution des erreurs d’événements de cycle de vie ignorés

Si tous les événements du cycle de vie d'un déploiement EC2 ou sur site sont ignorés, vous risquez de recevoir une erreur similaire à. The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems. (Error code: HEALTH_CONSTRAINTS) Voici certaines des causes et solutions possibles :

• L' CodeDeploy agent n'est peut-être pas installé ou ne s'exécute pas sur l'instance. Pour déterminer si l' CodeDeploy agent est en cours d'exécution :

  • Pour Amazon Linux, RHEL ou Ubuntu Server, exécutez la commande suivante :

    systemctl status codedeploy-agent

  • Pour Windows, exécutez la commande suivante :

    powershell.exe -Command Get-Service -Name CodeDeployagent

  Si l' CodeDeploy agent n'est pas installé ou n'est pas en cours d'exécution, consultezVérifiez que l' CodeDeploy agent est en cours d'exécution.

  Il est possible que votre instance ne parvienne pas à atteindre le point de terminaison public CodeDeploy ou Amazon S3 via le port 443. Essayez l’une des actions suivantes :

  • Attribuez une adresse IP publique à l'instance et utilisez sa table de routage pour autoriser l'accès Internet. Assurez-vous que le groupe de sécurité associé à l'instance autorise l'accès sortant sur le port 443 (HTTPS). Pour plus d’informations, consultez Protocole de communication et port pour l' CodeDeploy agent.

  • Si une instance est provisionnée dans un sous-réseau privé, utilisez une passerelle NAT au lieu d'une passerelle Internet dans la table de routage. Pour plus d'informations, consultez Passerelles NAT.

• Le rôle de service pour n'a CodeDeploy peut-être pas les autorisations requises. Pour configurer un rôle de service CodeDeploy, consultez Étape 2 : créer un rôle de service pour CodeDeploy.

• Si vous utilisez un proxy HTTP, assurez-vous qu'il est spécifié dans le :proxy_uri: paramètre du fichier de configuration de l' CodeDeploy agent. Pour plus d’informations, consultez CodeDeploy référence de configuration de l'agent.

• La date et l’heure de signature de votre instance de déploiement pourraient ne pas correspondre à la date et l'heure de signature de votre demande de déploiement. Recherchez une erreur similaire à celle qui se trouve Cannot reach InstanceService: Aws::CodeDeployCommand::Errors::InvalidSignatureException - Signature expired dans le fichier journal de votre CodeDeploy agent. Si vous voyez cette erreur, suivez les étapes décrites dans Résolution des erreurs de déploiement « InvalidSignatureException  — Signature expirée : [heure] est maintenant antérieure à [heure] ». Pour plus d’informations, consultez Afficher les données du journal pour les déploiements CodeDeploy EC2/sur site.

• L' CodeDeploy agent peut s'arrêter parce qu'une instance manque de mémoire ou d'espace sur le disque dur. Essayez de réduire le nombre de déploiements archivés sur votre instance en mettant à jour le max_revisions paramètre dans la configuration de l' CodeDeploy agent. Si vous effectuez cette opération pour une instance EC2 et que le problème persiste, envisagez d'utiliser une instance plus grande. Par exemple, si votre type d'instance est t2.small, essayez d'utiliser une instance t2.medium. Pour plus d'informations, reportez-vous aux Fichiers installés par l' CodeDeploy agent sectionsCodeDeploy référence de configuration de l'agent, et Types d'instances.

• Il est possible qu'aucun profil d'instance IAM ne soit attaché à l'instance sur laquelle vous effectuez le déploiement ou qu'un profil d'instance IAM ne dispose pas des autorisations requises.

  • Si aucun profil d'instance IAM n'est attaché à votre instance, créez-en un avec les autorisations requises, puis attachez-le.

  • Si un profil d'instance IAM est déjà attaché à votre instance, assurez-vous qu'il dispose des autorisations requises.

  Une fois que votre profil d'instance attaché est configuré avec les autorisations requises, redémarrez votre instance. Pour plus d'informations, consultez Étape 4 : Création d'un profil d'instance IAM pour vos instances Amazon EC2 la section Rôles IAM pour Amazon EC2 dans le guide de l'utilisateur Amazon EC2.

PowerShell Les scripts Windows ne parviennent pas à utiliser la version 64 bits de Windows PowerShell par défaut

Si un PowerShell script Windows exécuté dans le cadre d'un déploiement repose sur des fonctionnalités 64 bits (par exemple, parce qu'il consomme plus de mémoire que ce qu'autorise une application 32 bits ou qu'il appelle des bibliothèques proposées uniquement dans une version 64 bits), le script risque de se bloquer ou de ne pas s'exécuter comme prévu. Cela est dû au fait que, par défaut, la version 32 bits de Windows est CodeDeploy utilisée PowerShell pour exécuter des PowerShell scripts Windows qui font partie d'une révision d'application.

Ajoutez le code suivant au début de tout script devant être exécuté avec la version 64 bits de Windows PowerShell :

# Are you running in 32-bit mode?
#   (\SysWOW64\ = 32-bit mode)

if ($PSHOME -like "*SysWOW64*")
{
  Write-Warning "Restarting this script under 64-bit Windows PowerShell."

  # Restart this script under 64-bit Windows PowerShell.
  #   (\SysNative\ redirects to \System32\ for 64-bit mode)

  & (Join-Path ($PSHOME -replace "SysWOW64", "SysNative") powershell.exe) -File `
    (Join-Path $PSScriptRoot $MyInvocation.MyCommand) @args

  # Exit 32-bit script.

  Exit $LastExitCode
}

# Was restart successful?
Write-Warning "Hello from $PSHOME"
Write-Warning "  (\SysWOW64\ = 32-bit mode, \System32\ = 64-bit mode)"
Write-Warning "Original arguments (if any): $args"

# Your 64-bit script code follows here...
# ...

Bien que les informations de chemin de fichier contenues dans ce code puissent sembler peu intuitives, Windows 32 bits PowerShell utilise un chemin tel que :

c:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

Windows 64 bits PowerShell utilise un chemin tel que :

c:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe