Prise en main avec l’infrastructure de prise en charge des packages

L' infrastructure de prise en charge des packages est un kit Open source qui vous permet d’appliquer des correctifs à votre application de bureau existante (sans modifier le code) pour qu’elle puisse s’exécuter dans un conteneur MSIX. Le Framework de prise en charge de package aide votre application à respecter les bonnes pratiques de l’environnement d’exécution moderne.

Cet article fournit une présentation détaillée de chaque composant de l’infrastructure de prise en charge des packages, ainsi que du Guide pas à pas de son utilisation.

Comprendre ce qui se trouve dans un Framework de prise en charge de package

Le Framework de prise en charge de package contient un exécutable, une DLL de gestionnaire de runtime et un ensemble de correctifs de runtime.

Framework de prise en charge de package

Voici le processus :

  1. Créez un fichier de configuration qui spécifie les correctifs que vous souhaitez appliquer à votre application.
  2. Modifiez votre package pour qu’il pointe vers le fichier exécutable du lanceur de l’infrastructure de support des packages.

Lorsque les utilisateurs démarrent votre application, le lanceur de l’infrastructure de prise en charge des packages est le premier exécutable qui exécute. Il lit votre fichier de configuration et injecte les correctifs de runtime et la DLL de gestionnaire de runtime dans le processus d’application. Le gestionnaire de runtime applique le correctif quand l’application en a besoin pour s’exécuter à l’intérieur d’un conteneur MSIX.

Injection de DLL par le Framework de prise en charge de package

Étape 1 : identifier les problèmes de compatibilité des applications empaquetées

Tout d’abord, créez un package pour votre application. Ensuite, installez-le, exécutez-le et observez son comportement. Vous recevrez peut-être des messages d’erreur qui vous aideront à identifier un problème de compatibilité. Vous pouvez également utiliser Process Monitor pour identifier les problèmes. Les problèmes courants sont liés aux hypothèses de l’application concernant les autorisations du répertoire de travail et du chemin d’accès au programme.

Utilisation de process Monitor pour identifier un problème

Process Monitor est un utilitaire puissant pour observer les opérations de fichier et de registre d’une application, ainsi que leurs résultats. Cela peut vous aider à comprendre les problèmes de compatibilité des applications. Après l’ouverture du moniteur de processus, ajoutez un filtre (filtre > filtre...) pour inclure uniquement les événements de l’exécutable de l’application.

Filtre d’application ProcMon

Une liste d’événements s’affiche. Pour la plupart de ces événements, le mot « Success » s’affiche dans la colonne de résultats .

Événements ProcMon

Si vous le souhaitez, vous pouvez filtrer les événements pour n’afficher que les échecs.

ProcMon exclure le succès

Si vous soupçonnez un échec d’accès au système de fichiers, recherchez les événements ayant échoué qui se trouvent sous le chemin d’accès system32/SysWOW64 ou le fichier de package. Les filtres peuvent également être utiles ici. Démarrez en bas de cette liste et faites défiler vers le haut. Les erreurs qui s’affichent en bas de cette liste ont été les plus récentes. Payez la plus grande attention aux erreurs qui contiennent des chaînes telles que « accès refusé » et « chemin/nom introuvable », et ignorez les choses qui ne semblent pas suspectes. PSFSample présente deux problèmes. Vous pouvez voir ces problèmes dans la liste qui s’affiche dans l’image suivante.

ProcMon Config.txt

dans le premier problème qui s’affiche dans cette image, l’application ne parvient pas à lire à partir du fichier « Config.txt » qui se trouve dans le chemin d’accès « C:\ Windows \SysWOW64 ». Il est peu probable que l’application essaie de faire référence à ce chemin d’accès directement. Il est très probable qu’il essaie de lire à partir de ce fichier à l’aide d’un chemin d’accès relatif et, par défaut, « system32/SysWOW64 » est le répertoire de travail de l’application. Cela suggère que l’application attend que son répertoire de travail actuel soit défini sur un emplacement du package. À l’intérieur de l’AppX, nous pouvons voir que le fichier existe dans le même répertoire que l’exécutable.

Config.txt d’application

Le deuxième problème apparaît dans l’image suivante.

Fichier journal ProcMon

Dans ce problème, l’application ne parvient pas à écrire un fichier. log dans son chemin d’accès au package. Cela peut suggérer l’aide d’une correction de la redirection de fichiers.

Étape 2 : Rechercher un correctif du Runtime

Les fibres discontinues de polyester contiennent des correctifs de Runtime que vous pouvez utiliser pour le moment, par exemple la correction de la redirection de fichiers.

Correction de la redirection de fichiers

Vous pouvez utiliser la Correction de redirection de fichiers pour rediriger les tentatives d’écriture ou de lecture de données dans un répertoire qui n’est pas accessible à partir d’une application qui s’exécute dans un conteneur MSIX.

Par exemple, si votre application écrit dans un fichier journal qui se trouve dans le même répertoire que l’exécutable de votre application, vous pouvez utiliser la Correction de redirection de fichiers pour créer ce fichier journal dans un autre emplacement, tel que le magasin de données d’applications local.

Correctifs du runtime de la communauté

veillez à passer en revue les contributions de la communauté sur notre page de GitHub . Il est possible que d’autres développeurs résolvent un problème semblable au vôtre et aient partagé un correctif du Runtime.

Étape 3 : appliquer un correctif du Runtime

vous pouvez appliquer un correctif de runtime existant avec quelques outils simples à partir de la SDK Windows et en procédant comme suit.

  • Créer un dossier de disposition de package
  • Récupérer les fichiers de l’infrastructure de prise en charge du package
  • Ajoutez-les à votre package
  • Modifier le manifeste du package
  • Créer un fichier de configuration

Passons en revue chaque tâche.

Créer le dossier de disposition de package

Si vous disposez déjà d’un fichier. msix (ou. AppX), vous pouvez décompresser son contenu dans un dossier de disposition qui servira de zone de transit pour votre package. vous pouvez effectuer cette opération à partir d’une invite de commandes à l’aide de l’outil MakeAppx, en fonction du chemin d’installation du kit de développement logiciel (SDK), où se trouve l’outil makeappx.exe sur votre Windows 10 PC : x86 : c:\program files (x86) \ Windows Kits\10\bin\x86\makeappx.exe x64 : C:\Program files (x86) \ Windows Kits\10\bin\x64\makeappx.exe

makeappx unpack /p PSFSamplePackage_1.0.60.0_AnyCPU_Debug.msix /d PackageContents

Vous obtiendrez un résultat ressemblant à ce qui suit.

Disposition du package

Si vous n’avez pas de fichier. msix (ou. AppX) à partir duquel commencer, vous pouvez créer le dossier et les fichiers du package à partir de zéro.

Récupérer les fichiers de l’infrastructure de prise en charge du package

Vous pouvez récupérer le package NuGet NuGet à l’aide de l’outil en ligne de commande NuGet autonome ou via Visual Studio.

Récupération du package à l’aide de l’outil en ligne de commande

Installez l’outil en ligne de commande NuGet à partir de cet emplacement : https://www.nuget.org/downloads . Ensuite, à partir de la ligne de commande NuGet, exécutez la commande suivante :

nuget install Microsoft.PackageSupportFramework

Vous pouvez également renommer l’extension de package pour .zip et la décompresser. Tous les fichiers dont vous avez besoin se trouvent sous le dossier/bin.

Récupérez le package à l’aide de Visual Studio

dans Visual Studio, cliquez avec le bouton droit sur votre nœud de solution ou de projet, puis sélectionnez l’une des commandes gérer les Packages Nuget. Recherchez Microsoft. PackageSupportFramework ou des fibres discontinues pour trouver le package sur NuGet.org. Ensuite, installez-le.

Ajouter les fichiers de l’infrastructure de prise en charge du package à votre package

Ajoutez les dll et les fichiers exécutables des fibres discontinues de 32 bits et 64 nécessaires au répertoire du package. Inspirez-vous du tableau suivant. Vous devez également inclure les correctifs de Runtime dont vous avez besoin. Dans notre exemple, nous avons besoin du correctif du runtime de redirection de fichiers.

L’exécutable de l’application est x64 L’exécutable de l’application est x86
PSFLauncher64.exe PSFLauncher32.exe
PSFRuntime64.dll PSFRuntime32.dll
PSFRunDll64.exe PSFRunDll32.exe

Le contenu de votre package doit maintenant ressembler à ce qui suit.

Fichiers binaires du package

Modifier le manifeste du package

ouvrez le manifeste de votre package dans un éditeur de texte, puis définissez l' Executable attribut de l' Application élément sur le nom du fichier exécutable Lanceur de fibres distantes. Si vous connaissez l’architecture de votre application cible, sélectionnez la version appropriée, PSFLauncher32.exe ou PSFLauncher64.exe. Si ce n’est pas le cas, PSFLauncher32.exe fonctionnera dans tous les cas. Voici un exemple.

<Package ...>
  ...
  <Applications>
    <Application Id="PSFSample"
                 Executable="PSFLauncher32.exe"
                 EntryPoint="Windows.FullTrustApplication">
      ...
    </Application>
  </Applications>
</Package>

Créer un fichier de configuration

Créez un nom de fichier config.json , puis enregistrez ce fichier dans le dossier racine de votre package. Modifiez l’ID d’application déclaré du config.jssur le fichier pour qu’il pointe vers l’exécutable que vous venez de remplacer. À l’aide des connaissances acquises à l’aide de process Monitor, vous pouvez également définir le répertoire de travail et utiliser la correction de redirection de fichiers pour rediriger les lectures/écritures vers des fichiers. log sous le répertoire « PSFSampleApp » relatif au package.

{
    "applications": [
        {
            "id": "PSFSample",
            "executable": "PSFSampleApp/PSFSample.exe",
            "workingDirectory": "PSFSampleApp/"
        }
    ],
    "processes": [
        {
            "executable": "PSFSample",
            "fixups": [
                {
                    "dll": "FileRedirectionFixup.dll",
                    "config": {
                        "redirectedPaths": {
                            "packageRelative": [
                                {
                                    "base": "PSFSampleApp/",
                                    "patterns": [
                                        ".*\\.log"
                                    ]
                                }
                            ]
                        }
                    }
                }
            ]
        }
    ]
}

Vous trouverez ci-dessous un guide pour la config.jsdu schéma :

Array key Valeur
applications id Utilisez la valeur de l' Id attribut de l' Application élément dans le manifeste du package.
applications executable Chemin d’accès relatif au package à l’exécutable que vous souhaitez démarrer. Dans la plupart des cas, vous pouvez récupérer cette valeur à partir de votre fichier manifeste de package avant de le modifier. Il s’agit de la valeur de l' Executable attribut de l' Application élément.
applications workingDirectory Facultatif Chemin d’accès relatif au package à utiliser comme répertoire de travail de l’application qui démarre. Si vous ne définissez pas cette valeur, le système d’exploitation utilise le System32 répertoire comme répertoire de travail de l’application.
processus executable Dans la plupart des cas, il s’agit du nom du executable configuré ci-dessus avec le chemin d’accès et l’extension de fichier supprimés.
définitions dll Chemin d’accès relatif au package à la correction,. msix/. AppX à charger.
définitions config Facultatif Contrôle le comportement de la dll de correction. Le format exact de cette valeur varie en fonction de la correction, car chaque correction peut interpréter cet objet « BLOB » comme il le souhaite.

Les applications processes clés, et fixups sont des tableaux. Cela signifie que vous pouvez utiliser le config.jssur un fichier pour spécifier plusieurs DLL d’application, de processus et de correction.

Empaqueter et tester l’application

Ensuite, créez un package.

makeappx pack /d PackageContents /p PSFSamplePackageFixup.msix

Ensuite, signez-le.

signtool sign /a /v /fd sha256 /f ExportedSigningCertificate.pfx PSFSamplePackageFixup.msix

Pour plus d’informations, consultez comment créer un certificat de signature de package et Comment signer un package à l’aide de SignTool

À l’aide de PowerShell, installez le package.

Notes

N’oubliez pas de désinstaller le package en premier.

powershell Add-AppPackage .\PSFSamplePackageFixup.msix

Exécutez l’application et observez le comportement avec le correctif de Runtime appliqué. Répétez les étapes de diagnostic et d’empaquetage si nécessaire.

Vérifier si l’infrastructure de prise en charge du package est en cours d’exécution

Vous pouvez vérifier si votre correctif du runtime est en cours d’exécution. Pour ce faire, vous pouvez ouvrir le Gestionnaire des tâches et cliquer sur plus de détails. Recherchez l’application à laquelle l’infrastructure de prise en charge du package a été appliquée et développez le détail de l’application pour natifs plus de détails. Vous devez être en mesure de voir que l’infrastructure de prise en charge du package est en cours d’exécution.

Utiliser la correction de suivi

Une autre technique pour diagnostiquer les problèmes de compatibilité des applications empaquetées consiste à utiliser la correction de suivi. Cette DLL est incluse avec les fibres discontinues et fournit une vue de diagnostic détaillée du comportement de l’application, similaire à process Monitor. Il est spécialement conçu pour révéler des problèmes de compatibilité des applications. Pour utiliser la correction de suivi, ajoutez la DLL au package, ajoutez le fragment suivant à votre config.jssur, puis empaquetez et installez votre application.

{
    "dll": "TraceFixup.dll",
    "config": {
        "traceLevels": {
            "filesystem": "allFailures"
        }
    }
}

Par défaut, la correction de la trace filtre les échecs qui peuvent être considérés comme « attendus ». Par exemple, les applications peuvent essayer de supprimer de manière inconditionnelle un fichier sans vérifier s’il existe déjà, ce qui a pour effet d’ignorer le résultat. Cela a pour conséquence que certains échecs inattendus peuvent être éliminés par filtrage. par conséquent, dans l’exemple ci-dessus, nous choisissons de recevoir tous les échecs des fonctions FileSystem. Cela est dû au fait que nous savons avant que la tentative de lecture à partir du fichier Config.txt échoue avec le message « fichier introuvable ». Il s’agit d’une défaillance qui est fréquemment observée et qui n’est généralement pas supposée être inattendue. En pratique, il est généralement préférable de commencer le filtrage uniquement en cas de défaillances inattendues, puis de revenir à tous les échecs en cas de problème qui ne peut toujours pas être identifié.

Par défaut, la sortie de la correction de suivi est envoyée au débogueur attaché. Pour cet exemple, nous n’allons pas attacher de débogueur et utiliser à la place le programme DebugView de Sysinternals pour afficher sa sortie. Après l’exécution de l’application, nous pouvons voir les mêmes défaillances qu’auparavant, ce qui nous permettrait de faire face aux mêmes corrections du Runtime.

Fichier TraceShim introuvable

Accès TraceShim refusé

Déboguer, étendre ou créer un correctif du Runtime

vous pouvez utiliser Visual Studio pour déboguer un correctif du runtime, étendre un correctif du runtime ou en créer un à partir de zéro. Vous devez effectuer ces opérations pour réussir.

  • Ajouter un projet d’empaquetage
  • Ajouter un projet pour le correctif du Runtime
  • ajouter un projet qui démarre le fichier exécutable Lanceur de fibres discontinues de polyester
  • Configurer le projet de Packaging

Une fois que vous avez terminé, votre solution ressemblera à ce qui suit.

Solution terminée

Examinons chaque projet dans cet exemple.

Projet Objectif
DesktopApplicationPackage ce projet est basé sur le Windows projet de Packaging des applications et génère le package MSIX.
Runtimefix Il s’agit d’un projet de bibliothèque C++ Dynamic-Linked qui contient une ou plusieurs fonctions de remplacement qui servent de correctif du Runtime.
PSFLauncher Il s’agit d’Project vide C++. Ce projet est un emplacement où collecter les fichiers distribuable du runtime de l’infrastructure de prise en charge du package. Il génère un fichier exécutable. Cet exécutable est la première chose qui s’exécute lorsque vous démarrez la solution.
WinFormsDesktopApplication Ce projet contient le code source d’une application de bureau.

Pour consulter un exemple complet qui contient tous ces types de projets, consultez PSFSample.

Passons en revue les étapes de création et de configuration de chacun de ces projets dans votre solution.

Créer une solution de package

Si vous n’avez pas encore de solution pour votre application de bureau, créez une nouvelle solution vide dans Visual Studio.

Solution vide

Vous pouvez également ajouter les projets d’application de votre choix.

Ajouter un projet d’empaquetage

si vous n’avez pas encore Windows Project d’empaquetage d’Application, créez-en un et ajoutez-le à votre solution.

Modèle de projet de package

pour plus d’informations sur Windows projet de Packaging des applications, consultez empaqueter votre application à l’aide de Visual Studio.

Dans Explorateur de solutions, cliquez avec le bouton droit sur le projet Packaging, sélectionnez modifier, puis ajoutez-le au bas du fichier projet :

<Target Name="PSFRemoveSourceProject" AfterTargets="ExpandProjectReferences" BeforeTargets="_ConvertItems">
<ItemGroup>
  <FilteredNonWapProjProjectOutput Include="@(_FilteredNonWapProjProjectOutput)">
  <SourceProject Condition="'%(_FilteredNonWapProjProjectOutput.SourceProject)'=='<your runtime fix project name goes here>'" />
  </FilteredNonWapProjProjectOutput>
  <_FilteredNonWapProjProjectOutput Remove="@(_FilteredNonWapProjProjectOutput)" />
  <_FilteredNonWapProjProjectOutput Include="@(FilteredNonWapProjProjectOutput)" />
</ItemGroup>
</Target>

Ajouter un projet pour le correctif du Runtime

Ajoutez un projet de bibliothèque de liens dynamiques (dll) C++ à la solution.

Bibliothèque de correctifs du Runtime

Cliquez avec le bouton droit sur le projet, puis choisissez Propriétés.

Dans les pages de propriétés, recherchez le champ standard du langage c++ , puis dans la liste déroulante en regard de ce champ, sélectionnez l’option ISO C++ 17 standard (/std : c++ 17) .

ISO 17 (option)

Cliquez avec le bouton droit sur ce projet puis, dans le menu contextuel, choisissez l’option gérer les packages NuGet . Assurez-vous que l’option source du package est définie sur All ou NuGet.org.

Cliquez sur l’icône des paramètres à côté de ce champ.

Recherchez le package NuGet *, puis installez-le pour ce projet.

package nuget

Si vous souhaitez déboguer ou étendre un correctif du runtime existant, ajoutez les fichiers de correction du runtime que vous avez obtenus à l’aide des conseils décrits dans la section Rechercher un correctif du runtime de ce guide.

Si vous envisagez de créer un tout nouveau correctif, n’ajoutez rien à ce projet pour l’instant. Nous vous aiderons à ajouter les bons fichiers à ce projet plus loin dans ce guide. Pour le moment, nous allons continuer à configurer votre solution.

ajouter un projet qui démarre le fichier exécutable Lanceur de fibres discontinues de polyester

ajoutez un projet Project vide C++ à la solution.

Projet vide

Ajoutez le package NuGet NuGet à ce projet en utilisant les mêmes instructions que celles décrites dans la section précédente.

Ouvrez les pages de propriétés du projet et, dans la page paramètres généraux , définissez la propriété nom cible sur PSFLauncher32 ou PSFLauncher64 en fonction de l’architecture de votre application.

référence du Lanceur des fibres discontinues

Ajoutez une référence de projet au projet de correctif du runtime dans votre solution.

Référence du correctif Runtime

Cliquez avec le bouton droit sur la référence, puis, dans la fenêtre Propriétés , appliquez ces valeurs.

Propriété Valeur
Copie locale True
Copier les assemblys satellites locaux True
Sortie de l’assembly de référence True
Lier les dépendances de la bibliothèque Faux
Entrées de dépendance de la bibliothèque de liens Faux

Configurer le projet de Packaging

Dans le projet d’empaquetage, cliquez avec le bouton droit sur le dossier applications , puis choisissez Ajouter une référence.

Ajouter une référence de projet

choisissez le projet de fibres discontinues Lanceur et votre projet d’application de bureau, puis choisissez le bouton OK .

Projet de bureau

Notes

si vous n’avez pas le code source pour votre application, choisissez simplement le projet de fibres discontinues Lanceur. Nous vous montrerons comment référencer votre exécutable lorsque vous créez un fichier de configuration.

dans le nœud Applications , cliquez avec le bouton droit sur l’application Lanceur de fibres discontinues, puis choisissez définir comme Point d’entrée.

Définir le point d’entrée

Ajoutez un fichier nommé config.json à votre projet de Packaging, puis copiez et collez le texte JSON suivant dans le fichier. Affectez à la propriété action de package la valeur contenu.

{
    "applications": [
        {
            "id": "",
            "executable": "",
            "workingDirectory": ""
        }
    ],
    "processes": [
        {
            "executable": "",
            "fixups": [
                {
                    "dll": "",
                    "config": {
                    }
                }
            ]
        }
    ]
}

Fournissez une valeur pour chaque clé. Utilisez ce tableau comme guide.

Array key Valeur
applications id Utilisez la valeur de l' Id attribut de l' Application élément dans le manifeste du package.
applications executable Chemin d’accès relatif au package à l’exécutable que vous souhaitez démarrer. Dans la plupart des cas, vous pouvez récupérer cette valeur à partir de votre fichier manifeste de package avant de le modifier. Il s’agit de la valeur de l' Executable attribut de l' Application élément.
applications workingDirectory Facultatif Chemin d’accès relatif au package à utiliser comme répertoire de travail de l’application qui démarre. Si vous ne définissez pas cette valeur, le système d’exploitation utilise le System32 répertoire comme répertoire de travail de l’application.
processus executable Dans la plupart des cas, il s’agit du nom du executable configuré ci-dessus avec le chemin d’accès et l’extension de fichier supprimés.
définitions dll Chemin d’accès relatif au package à la DLL de correction à charger.
définitions config Facultatif Contrôle le comportement de la DLL de correction. Le format exact de cette valeur varie en fonction de la correction, car chaque correction peut interpréter cet objet « BLOB » comme il le souhaite.

Une fois que vous avez terminé, votre fichier ressemble à config.json ce qui suit.

{
  "applications": [
    {
      "id": "DesktopApplication",
      "executable": "DesktopApplication/WinFormsDesktopApplication.exe",
      "workingDirectory": "WinFormsDesktopApplication"
    }
  ],
  "processes": [
    {
      "executable": ".*App.*",
      "fixups": [ { "dll": "RuntimeFix.dll" } ]
    }
  ]
}

Notes

Les applications processes clés, et fixups sont des tableaux. Cela signifie que vous pouvez utiliser le config.jssur un fichier pour spécifier plusieurs DLL d’application, de processus et de correction.

Déboguer un correctif du Runtime

dans Visual Studio, appuyez sur F5 pour démarrer le débogueur. la première chose qui commence est l’application de fibres discontinues Lanceur qui, à son tour, démarre votre application de bureau cible. Pour déboguer l’application de bureau cible, vous devez effectuer un attachement manuel au processus de l’application de bureau en choisissant Déboguer->attacher au processus, puis en sélectionnant le processus d’application. Pour autoriser le débogage d’une application .NET avec une DLL de correction du runtime natif, sélectionnez types de code managé et natif (débogage en mode mixte).

Une fois que vous l’avez configurée, vous pouvez définir des points d’arrêt en regard de lignes de code dans le code de l’application de bureau et le projet de correction du Runtime. Si vous n’avez pas le code source pour votre application, vous pouvez définir des points d’arrêt uniquement en regard de lignes de code dans votre projet de correction du Runtime.

Étant donné que le débogage F5 exécute l’application en déployant des fichiers libres à partir du chemin d’accès au dossier de disposition du package, au lieu d’installer à partir d’un package. msix/. AppX, le dossier de disposition n’a généralement pas les mêmes restrictions de sécurité qu’un dossier de package installé. Par conséquent, il n’est pas possible de reproduire les erreurs de refus d’accès au chemin d’accès du package avant d’appliquer un correctif du Runtime.

Pour résoudre ce problème, utilisez le déploiement de package. msix/. AppX plutôt que le déploiement de fichiers libres F5. pour créer un fichier de package. msix/. appx, utilisez l’utilitaire MakeAppx à partir du SDK Windows, comme décrit ci-dessus. ou, dans Visual Studio, cliquez avec le bouton droit sur le nœud de votre projet d’application, puis sélectionnez Store-> créer des Packages d’application.

un autre problème avec Visual Studio est qu’il ne dispose pas d’une prise en charge intégrée pour l’attachement à des processus enfants lancés par le débogueur. cela complique le débogage de la logique dans le chemin de démarrage de l’application cible, qui doit être attaché manuellement par Visual Studio après le lancement.

Pour résoudre ce problème, utilisez un débogueur qui prend en charge l’attachement de processus enfant. Notez qu’il n’est généralement pas possible de joindre un débogueur juste-à-temps (JIT) à l’application cible. Cela est dû au fait que la plupart des techniques JIT impliquent le lancement du débogueur à la place de l’application cible, via la clé de Registre ImageFileExecutionOptions. Cela annule le mécanisme de détournement utilisé par PSFLauncher.exe pour injecter des FixupRuntime.dll dans l’application cible. WinDbg, inclus dans les outils de débogage pour Windowset obtenu à partir du SDK Windows, prend en charge l’attachement de processus enfant. Il prend également en charge le lancement et le débogage directs d’une application UWP.

Pour déboguer le démarrage de l’application cible en tant que processus enfant, démarrez WinDbg .

windbg.exe -plmPackage PSFSampleWithFixup_1.0.59.0_x86__7s220nvg1hg3m -plmApp PSFSample

À l' WinDbg invite, activez le débogage enfant et définissez les points d’arrêt appropriés.

.childdbg 1
g

(exécuter jusqu’à ce que l’application cible démarre et s’arrête dans le débogueur)

sxe ld fixup.dll
g

(exécuter jusqu’à ce que la DLL de correction soit chargée)

bp ...

Notes

PLMDebug peut également être utilisé pour attacher un débogueur à une application lors du lancement, et est également inclus dans les outils de débogage pour Windows. Toutefois, il est plus complexe à utiliser que le support direct fourni à l’heure actuelle par WinDbg.

Support technique

Des questions ? Posez-nous des questions sur l’espace de conversation de l' infrastructure de support du package sur le site de la communauté MSIX Tech.