Partager via


Prise en main de Package Support Framework

Package Support Framework est un kit code source ouvert qui vous aide à appliquer des correctifs à votre application de bureau existante (sans modifier le code) afin qu’il 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 un aperçu indépible de chaque composant de l’infrastructure de prise en charge de package et un guide pas à pas pour l’utiliser.

Comprendre ce qui se trouve à l’intérieur d’un framework de support 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.

Package Support Framework

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 PSF (Package Support Framework).

Lorsque les utilisateurs démarrent votre application, le lanceur Package Support Framework est le premier exécutable qui s’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.

Package Support Framework DLL Injection

É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 concernent les hypothèses d’application concernant le répertoire de travail et les autorisations de 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 avoir ouvert Process Monitor, ajoutez un filtre (Filtre > de filtre...) pour inclure uniquement les événements de l’exécutable de l’application.

ProcMon App Filter

Une liste d’événements s’affiche. Pour la plupart de ces événements, le mot SUCCESS apparaît dans la colonne Résultat .

ProcMon Events

Si vous le souhaitez, vous pouvez filtrer les événements pour afficher uniquement les échecs.

ProcMon Exclude Success

Si vous soupçonnez un échec d’accès au système de fichiers, recherchez les événements ayant échoué qui se trouvent sous System32/SysWOW64 ou le chemin du fichier de package. Les filtres peuvent également vous aider ici. Commencez en bas de cette liste et faites défiler vers le haut. Les échecs qui apparaissent en bas de cette liste se sont produits récemment. Faites attention aux erreurs qui contiennent des chaînes telles que « accès refusé » et « chemin/nom introuvable » et ignorez les éléments qui ne semblent pas suspects. Le PSFSample a deux problèmes. Vous pouvez voir ces problèmes dans la liste qui s’affichent dans l’image suivante.

ProcMon Config.txt

Dans le premier problème qui apparaît dans cette image, l’application ne parvient pas à lire à partir du fichier « Config.txt » situé dans le chemin d’accès « C :\Windows\SysWOW64 ». Il est peu probable que l’application tente de référencer ce chemin directement. Probablement, il tente de lire à partir de ce fichier à l’aide d’un chemin relatif, et par défaut, « System32/SysWOW64 » est le répertoire de travail de l’application. Cela suggère que l’application s’attend à ce que son répertoire de travail actuel soit défini quelque part dans le package. À l’intérieur de l’appx, nous pouvons voir que le fichier existe dans le même répertoire que l’exécutable.

App Config.txt

Le deuxième problème s’affiche dans l’image suivante.

ProcMon Logfile

Dans ce problème, l’application ne parvient pas à écrire un fichier .log dans son chemin d’accès au package. Cela suggère qu’un correctif de redirection de fichier peut vous aider.

Étape 2 : Rechercher un correctif d’exécution

PsF contient des correctifs d’exécution que vous pouvez utiliser pour le moment, tels que le correctif de redirection de fichiers.

Correctif de redirection de fichiers

Vous pouvez utiliser le correctif 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 vos applications, vous pouvez utiliser le correctif de redirection de fichiers pour créer ce fichier journal dans un autre emplacement, tel que le magasin de données d’application local.

Correctifs d’exécution de la communauté

Veillez à consulter les contributions de la communauté à notre page GitHub . Il est possible que d’autres développeurs aient résolu un problème similaire à votre vôtre et ont partagé un correctif d’exécution.

Étape 3 : Appliquer un correctif d’exécution

Vous pouvez appliquer un correctif d’exécution existant avec quelques outils simples à partir du Kit de développement logiciel (SDK) Windows, et en suivant ces étapes.

  • Créer un dossier de disposition de package
  • Obtenir les fichiers Package Support Framework
  • Ajoutez-les à votre package
  • Modifier le manifeste du package
  • Créer un fichier de configuration

Passons à chaque tâche.

Créer le dossier de disposition du package

Si vous avez déjà un fichier .msix (ou .appx), vous pouvez décompresser son contenu dans un dossier de disposition qui servira de zone intermédiaire pour votre package. Vous pouvez le faire à partir d’une invite de commandes à l’aide de l’outil MakeAppx, en fonction de votre chemin d’installation du Kit de développement logiciel (SDK), vous trouverez l’outil makeappx.exe sur votre PC Windows 10 : 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

Cela vous donnera quelque chose qui ressemble à ce qui suit.

Package Layout

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

Obtenir les fichiers Package Support Framework

Vous pouvez obtenir le package Nuget PSF à l’aide de l’outil en ligne de commande Nuget autonome ou via Visual Studio.

Obtenir le package à l’aide de l’outil en ligne de commande

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

nuget install Microsoft.PackageSupportFramework

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

Obtenir le package à l’aide de Visual Studio

Dans Visual Studio, cliquez avec le bouton droit sur votre nœud solution ou projet, puis sélectionnez l’une des commandes Gérer les packages Nuget. Recherchez Microsoft.PackageSupportFramework ou PSF pour rechercher le package sur Nuget.org. Ensuite, installez-le.

Ajouter les fichiers Package Support Framework à votre package

Ajoutez les DLL ET fichiers exécutables PSF 32 bits et 64 bits requis au répertoire du package. Inspirez-vous du tableau suivant. Vous devez également inclure les correctifs d’exécution 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
PSF Lanceur 64.exe PSF Lanceur 32.exe
PSFRuntime64.dll PSFRuntime32.dll
PSFRunDll64.exe PSFRunDll32.exe

Votre contenu de package doit maintenant ressembler à ceci.

Package Binaries

Modifier le manifeste du package

Ouvrez votre manifeste de package dans un éditeur de texte, puis définissez l’attribut Executable de l’élément Application sur le nom du fichier exécutable LANCEUR PSF. Si vous connaissez l’architecture de votre application cible, sélectionnez la version appropriée, PSF Lanceur 32.exe ou PSF Lanceur 64.exe. Si ce n’est pas le cas, PSF Lanceur 32.exe fonctionnera dans tous les cas. Prenons 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 config.jsonde fichier et enregistrez ce fichier dans le dossier racine de votre package. Modifiez l’ID d’application déclaré du fichier config.json pour pointer vers l’exécutable que vous venez de remplacer. À l’aide des connaissances que vous avez acquises à l’aide de Process Monitor, vous pouvez également définir le répertoire de travail et utiliser le correctif de redirection de fichier pour rediriger les lectures/écritures dans les 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"
                                    ]
                                }
                            ]
                        }
                    }
                }
            ]
        }
    ]
}

Voici un guide pour le schéma config.json :

Tableau key Valeur
applications id Utilisez la valeur de l’attribut Id de l’élément Application dans le manifeste du package.
applications executable Chemin d’accès relatif au package vers l’exécutable que vous souhaitez démarrer. Dans la plupart des cas, vous pouvez obtenir cette valeur à partir de votre fichier manifeste de package avant de le modifier. Il s’agit de la valeur de l’attribut Executable de l’élément Application .
applications workingDirectory (Facultatif) Chemin 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 fichier configuré ci-dessus avec le chemin d’accès et l’extension de fichier supprimés.
correctifs dll Chemin relatif au package du correctif, .msix/.appx à charger.
correctifs config (Facultatif) Contrôle le comportement de la dll fixup. Le format exact de cette valeur varie selon un correctif par correction, car chaque correctif peut interpréter ce « blob » comme il le souhaite.

Les applicationstableaux et processesfixups les clés sont des tableaux. Cela signifie que vous pouvez utiliser le fichier config.json pour spécifier plusieurs applications, processus et DLL 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.

Remarque

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 d’exécution 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 case activée si votre correctif d’exécution est en cours d’exécution. Pour ce faire, ouvrez le Gestionnaire des tâches et cliquez sur Plus de détails. Recherchez l’application sur laquelle l’infrastructure de prise en charge du package a été appliquée et développez les détails de l’application pour obtenir 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 trace

Une autre technique pour diagnostiquer les problèmes de compatibilité des applications empaquetées consiste à utiliser le correctif de trace. Cette DLL est incluse dans psF 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 les problèmes de compatibilité des applications. Pour utiliser trace Fixup, ajoutez la DLL au package, ajoutez le fragment suivant à votre config.json, puis empaqueter et installer votre application.

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

Par défaut, trace Fixup filtre les échecs qui peuvent être considérés comme « attendus ». Par exemple, les applications peuvent essayer de supprimer sans condition un fichier sans case activée pour voir s’il existe déjà, en ignorant le résultat. Cela a la conséquence malheureuse que certains échecs inattendus peuvent être filtrés. Par conséquent, dans l’exemple ci-dessus, nous choisissons de recevoir tous les échecs des fonctions de système de fichiers. Cela est dû au fait que nous savons d’avant que la tentative de lecture à partir du fichier Config.txt échoue avec le message « fichier introuvable ». Il s’agit d’un échec qui est fréquemment observé et qui n’est généralement pas supposé être inattendu. Dans la pratique, il est préférable de commencer le filtrage uniquement en cas d’échecs inattendus, puis de revenir à tous les échecs s’il existe un problème qui ne peut toujours pas être identifié.

Par défaut, la sortie du correctif de trace est envoyée au débogueur attaché. Pour cet exemple, nous ne allons pas attacher un débogueur et utiliserons plutôt le programme DebugView de SysInternals pour afficher sa sortie. Après avoir exécuté l’application, nous pouvons voir les mêmes échecs que précédemment, ce qui nous dirigerait vers les mêmes correctifs d’exécution.

TraceShim File Not Found

TraceShim Access Denied

Déboguer, étendre ou créer un correctif d’exécution

Vous pouvez utiliser Visual Studio pour déboguer un correctif d’exécution, étendre un correctif d’exécution ou en créer un à partir de zéro. Vous devrez faire ces choses pour réussir.

  • Ajouter un projet d’empaquetage
  • Ajouter un projet pour le correctif d’exécution
  • Ajouter un projet qui démarre l’exécutable Lanceur PSF
  • Configurer le projet d’empaquetage

Lorsque vous avez terminé, votre solution ressemblera à ceci.

Completed solution

Examinons chaque projet dans cet exemple.

Project Objectif
DesktopApplicationPackage Ce projet est basé sur le projet d’empaquetage d’applications Windows et génère le package MSIX.
Runtimefix Il s’agit d’un projet de bibliothèque dynamique C++ qui contient une ou plusieurs fonctions de remplacement qui servent de correctif d’exécution.
PSF Lanceur Il s’agit d’un projet vide C++. Ce projet est un endroit où collecter les fichiers distribuables du runtime du Package Support Framework. 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 solution vide dans Visual Studio.

Blank solution

Vous pouvez également ajouter tous les projets d’application dont vous disposez.

Ajouter un projet d’empaquetage

Si vous n’avez pas encore de projet d’empaquetage d’applications Windows, créez-en un et ajoutez-le à votre solution.

Package project template

Pour plus d’informations sur le projet d’empaquetage d’applications Windows, consultez Empaqueter votre application à l’aide de Visual Studio.

Dans Explorateur de solutions, cliquez avec le bouton droit sur le projet d’empaquetage, 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 d’exécution

Ajoutez un projet DLL (Dynamic-Link Library) C++ à la solution.

Runtime fix library

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

Dans les pages de propriétés, recherchez le champ C++ Language Standard, 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. Vérifiez que l’option source du package est définie sur All ou nuget.org.

Cliquez sur l’icône paramètres en regard de ce champ.

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

nuget package

Si vous souhaitez déboguer ou étendre un correctif d’exécution existant, ajoutez les fichiers de correctif d’exécution que vous avez obtenus à l’aide des instructions décrites dans la section Rechercher un correctif d’exécution de ce guide.

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

Ajouter un projet qui démarre l’exécutable Lanceur PSF

Ajoutez un projet de projet vide C++ à la solution.

Empty project

Ajoutez le package Nuget PSF à ce projet à l’aide des mêmes instructions 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é PSFLauncher32 Nom cible sur ou PSFLauncher64 selon l’architecture de votre application.

PSF Launcher reference

Ajoutez une référence de projet au projet de correctif d’exécution dans votre solution.

runtime fix reference

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

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

Configurer le projet d’empaquetage

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

Add Project Reference

Choisissez le projet PSF Lanceur et votre projet d’application de bureau, puis cliquez sur le bouton OK.

Desktop project

Remarque

Si vous n’avez pas le code source de votre application, choisissez simplement le projet PSF Lanceur. Nous allons vous montrer 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 PSF, puis choisissez Définir comme point d’entrée.

Set entry point

Ajoutez un fichier nommé config.json à votre projet d’empaquetage, puis copiez et collez le texte json suivant dans le fichier. Définissez la propriété Action de package sur Content.

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

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

Tableau key Valeur
applications id Utilisez la valeur de l’attribut Id de l’élément Application dans le manifeste du package.
applications executable Chemin d’accès relatif au package vers l’exécutable que vous souhaitez démarrer. Dans la plupart des cas, vous pouvez obtenir cette valeur à partir de votre fichier manifeste de package avant de le modifier. Il s’agit de la valeur de l’attribut Executable de l’élément Application .
applications workingDirectory (Facultatif) Chemin 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 fichier configuré ci-dessus avec le chemin d’accès et l’extension de fichier supprimés.
correctifs dll Chemin relatif au package vers la DLL de correction à charger.
correctifs config (Facultatif) Contrôle le comportement de la DLL de correction. Le format exact de cette valeur varie selon un correctif par correction, car chaque correctif peut interpréter ce « blob » comme il le souhaite.

Lorsque vous avez terminé, votre config.json fichier ressemblera à ceci.

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

Remarque

Les applicationstableaux et processesfixups les clés sont des tableaux. Cela signifie que vous pouvez utiliser le fichier config.json pour spécifier plusieurs applications, processus et DLL de correction.

Déboguer un correctif d’exécution

Dans Visual Studio, appuyez sur F5 pour démarrer le débogueur. La première chose qui démarre est l’application Lanceur PSF, qui démarre à son tour votre application de bureau cible. Pour déboguer l’application de bureau cible, vous devez attacher manuellement le processus d’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 correctif d’exécution native, sélectionnez des types de code managés et natifs (débogage en mode mixte).

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

Étant donné que le débogage F5 exécute l’application en déployant des fichiers libres à partir du chemin du dossier de disposition du package, au lieu d’effectuer l’installation à 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 peut ne pas être possible de reproduire les erreurs de déni d’accès au chemin d’accès du package avant d’appliquer un correctif d’exécution.

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 Kit de développement logiciel (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 n’a pas de prise en charge intégrée de l’attachement à des processus enfants lancés par le débogueur. Cela rend difficile le débogage de la logique dans le chemin d’accès de démarrage de l’application cible, qui doit être attachée 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 d’attacher 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 élimine le mécanisme de détour utilisé par PSF Lanceur.exe pour injecter FixupRuntime.dll dans l’application cible. WinDbg, inclus dans les outils de débogage pour Windows et obtenu à partir du Kit de développement logiciel (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’invite, activez le WinDbg débogage enfant et définissez les points d’arrêt appropriés.

.childdbg 1
g

(exécuter jusqu’au démarrage et à l’interruption de l’application cible dans le débogueur)

sxe ld fixup.dll
g

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

bp ...

Remarque

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 d’utiliser que la prise en charge directe fournie par WinDbg.

Assistance technique

Des questions ? Demandez-nous sur l’espace de conversation Package Support Framework sur le site de la communauté technique MSIX.