Condividi tramite


Introduzione a Package Support Framework

Package Support Framework è un kit open source che consente di applicare correzioni all'applicazione desktop esistente (senza modificare il codice) in modo che possa essere eseguita in un contenitore MSIX. PSF consente di seguire le procedure consigliate degli ambienti di runtime moderni per le app.

Questo articolo fornisce un'analisi indepth di ogni componente di Package Support Framework e guida dettagliata all'uso.

Informazioni su come si trova all'interno di un framework di supporto pacchetti

Il Package Support Framework contiene un file eseguibile, una DLL del gestore runtime e un set di correzioni di runtime.

Package Support Framework

Ecco il processo:

  1. Creare un file di configurazione che specifica le correzioni da applicare all'applicazione.
  2. Modificare il pacchetto in modo che punti al file eseguibile dell'utilità di avvio di Package Support Framework (PSF).

Quando gli utenti avviano l'applicazione, l'utilità di avvio di Package Support Framework è il primo eseguibile in esecuzione. Legge il file di configurazione e inserisce le correzioni di runtime e la DLL del gestore runtime nel processo dell'applicazione. Il gestore runtime applica la correzione quando è necessario per l'esecuzione dell'applicazione all'interno di un contenitore MSIX.

Package Support Framework DLL Injection

Passaggio 1: Identificare i problemi di compatibilità delle applicazioni in pacchetto

Creare prima di tutto un pacchetto per l'applicazione. Quindi, installarlo, eseguirlo e osservarne il comportamento. Potrebbero essere visualizzati messaggi di errore, utili per identificare un problema di compatibilità. Puoi anche usare Process Monitor per identificare i problemi. I problemi comuni si riferiscono ai presupposti dell'applicazione relativi alle autorizzazioni per la directory di lavoro e il percorso del programma.

Uso di Monitoraggio processi per identificare un problema

Monitoraggio processi è un'utilità potente per osservare le operazioni di file e registro di un'app e i relativi risultati. Ciò consente di comprendere i problemi di compatibilità delle applicazioni. Dopo aver aperto Monitoraggio processi, aggiungere un filtro (filtro filtro > ...) per includere solo gli eventi dell'eseguibile dell'applicazione.

ProcMon App Filter

Verrà visualizzato un elenco di eventi. Per molti di questi eventi, la parola SUCCESS verrà visualizzata nella colonna Risultato .

ProcMon Events

Facoltativamente, è possibile filtrare gli eventi in modo da visualizzare solo gli errori.

ProcMon Exclude Success

Se si sospetta un errore di accesso al file system, cercare gli eventi non riusciti che si trovano nel percorso System32/SysWOW64 o del file del pacchetto. Anche i filtri possono essere utili anche qui. Iniziare nella parte inferiore dell'elenco e scorrere verso l'alto. Gli errori visualizzati nella parte inferiore di questo elenco si sono verificati più di recente. Prestare la maggior parte dell'attenzione agli errori che contengono stringhe come "accesso negato" e "percorso/nome non trovato" e ignorare gli elementi che non sembrano sospetti. PSFSample presenta due problemi. È possibile visualizzare questi problemi nell'elenco visualizzato nell'immagine seguente.

ProcMon Config.txt

Nel primo problema visualizzato in questa immagine, l'applicazione non riesce a leggere dal file "Config.txt" che si trova nel percorso "C:\Windows\SysWOW64". È improbabile che l'applicazione stia tentando di fare riferimento direttamente a tale percorso. È molto probabile che stia tentando di leggere da tale file usando un percorso relativo e, per impostazione predefinita, "System32/SysWOW64" è la directory di lavoro dell'applicazione. Ciò suggerisce che l'applicazione prevede che la directory di lavoro corrente sia impostata su un punto qualsiasi del pacchetto. Guardando all'interno dell'appx, è possibile vedere che il file esiste nella stessa directory del file eseguibile.

App Config.txt

Il secondo problema viene visualizzato nell'immagine seguente.

ProcMon Logfile

In questo problema, l'applicazione non riesce a scrivere un file con estensione log nel percorso del pacchetto. Ciò suggerisce che una correzione del reindirizzamento di file potrebbe essere utile.

Passaggio 2: Trovare una correzione di runtime

Psf contiene correzioni di runtime che è possibile usare in questo momento, ad esempio la correzione del reindirizzamento dei file.

Correzione reindirizzamento file

È possibile usare l'opzione Correzione reindirizzamento file per reindirizzare i tentativi di scrivere o leggere dati in una directory che non è accessibile da un'applicazione eseguita in un contenitore MSIX.

Ad esempio, se l'applicazione scrive in un file di log che si trova nella stessa directory del file eseguibile delle applicazioni, è possibile usare la correzione reindirizzamento file per creare tale file di log in un'altra posizione, ad esempio l'archivio dati dell'app locale.

Correzioni di runtime dalla community

Assicurarsi di esaminare i contributi della community alla pagina GitHub . È possibile che altri sviluppatori abbiano risolto un problema simile al proprio e abbiano condiviso una correzione di runtime.

Passaggio 3: Applicare una correzione di runtime

È possibile applicare una correzione di runtime esistente con alcuni semplici strumenti di Windows SDK e seguendo questa procedura.

  • Creare una cartella di layout del pacchetto
  • Ottenere i file di Package Support Framework
  • Aggiungerli al pacchetto
  • Modificare il manifesto del pacchetto
  • Creare un file di configurazione

Esaminiamo ogni attività.

Creare la cartella di layout del pacchetto

Se si dispone già di un file con estensione msix (o appx), è possibile decomprimerne il contenuto in una cartella di layout che fungerà da area di gestione temporanea per il pacchetto. È possibile eseguire questa operazione da un prompt dei comandi usando lo strumento MakeAppx, in base al percorso di installazione dell'SDK, si trova lo strumento makeappx.exe nel PC Windows 10: x86: C:\Programmi (x86)\Windows Kits\10\bin\x86\makeappx.exe x64: C:\Programmi (x86)\Windows Kits\10\bin\x64\makeappx.exe

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

In questo modo verrà visualizzato un aspetto simile al seguente.

Package Layout

Se non si dispone di un file con estensione msix (o appx) da cui iniziare, è possibile creare la cartella e i file del pacchetto da zero.

Ottenere i file di Package Support Framework

È possibile ottenere il pacchetto NuGet PSF usando lo strumento da riga di comando Nuget autonomo o tramite Visual Studio.

Ottenere il pacchetto usando lo strumento da riga di comando

Installare lo strumento da riga di comando NuGet da questo percorso: https://www.nuget.org/downloads. Quindi, dalla riga di comando nuget, eseguire questo comando:

nuget install Microsoft.PackageSupportFramework

In alternativa, è possibile rinominare l'estensione del pacchetto in .zip e decomprimerla. Tutti i file necessari si trovano nella cartella /bin.

Ottenere il pacchetto usando Visual Studio

In Visual Studio fare clic con il pulsante destro del mouse sul nodo della soluzione o del progetto e scegliere uno dei comandi Gestisci pacchetti NuGet. Cercare Microsoft.PackageSupportFramework o PSF per trovare il pacchetto in Nuget.org. Quindi, installarlo.

Aggiungere i file di Package Support Framework al pacchetto

Aggiungere le DLL PSF a 32 bit e a 64 bit necessarie e i file eseguibili alla directory del pacchetto. Utilizzare la tabella seguente come riferimento. È anche necessario includere eventuali correzioni di runtime necessarie. In questo esempio è necessaria la correzione del runtime di reindirizzamento dei file.

L'eseguibile dell'applicazione è x64 L'eseguibile dell'applicazione è x86
PSFLauncher64.exe PSFLauncher32.exe
PSFRuntime64.dll PSFRuntime32.dll
PSFRunDll64.exe PSFRunDll32.exe

Il contenuto del pacchetto dovrebbe ora essere simile al seguente.

Package Binaries

Modificare il manifesto del pacchetto

Aprire il manifesto del pacchetto in un editor di testo e quindi impostare l'attributo Executable dell'elemento Application sul nome del file eseguibile di PSF Launcher. Se si conosce l'architettura dell'applicazione di destinazione, selezionare la versione appropriata, PSFLauncher32.exe o PSFLauncher64.exe. In caso contrario, PSFLauncher32.exe funzionerà in tutti i casi. Ecco un esempio.

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

Creare un file di configurazione

Creare un nome config.jsonfile e salvare il file nella cartella radice del pacchetto. Modificare l'ID app dichiarato del file config.json in modo che punti al file eseguibile appena sostituito. Usando le conoscenze acquisite dall'uso di Monitoraggio processi, è anche possibile impostare la directory di lavoro e usare la correzione di reindirizzamento dei file per reindirizzare letture/scritture ai file con estensione log nella directory "PSFSampleApp" relativa al pacchetto.

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

Di seguito è riportata una guida per lo schema config.json:

Matrice key valore
applications ID Usare il valore dell'attributo Id dell'elemento Application nel manifesto del pacchetto.
applications eseguibile Percorso relativo al pacchetto dell'eseguibile da avviare. Nella maggior parte dei casi, è possibile ottenere questo valore dal file manifesto del pacchetto prima di modificarlo. È il valore dell'attributo Executable dell'elemento Application .
applications Workingdirectory (Facoltativo) Percorso relativo al pacchetto da usare come directory di lavoro dell'applicazione che viene avviata. Se non si imposta questo valore, il sistema operativo usa la System32 directory come directory di lavoro dell'applicazione.
di sistema eseguibile Nella maggior parte dei casi, questo sarà il nome dell'oggetto executable configurato in precedenza con il percorso e l'estensione di file rimossi.
correzioni Libreria dll Percorso relativo al pacchetto per il caricamento di .msix/.appx.
correzioni config (Facoltativo) Controlla il comportamento della dll di correzione. Il formato esatto di questo valore varia in base alla correzione per correzione, perché ogni correzione può interpretare questo "BLOB" come vuole.

Le applicationschiavi , processese fixups sono matrici. Ciò significa che è possibile usare il file config.json per specificare più di un'applicazione, un processo e una DLL di correzione.

Creare un pacchetto e testare l'app

Creare quindi un pacchetto.

makeappx pack /d PackageContents /p PSFSamplePackageFixup.msix

Poi firmalo.

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

Per altre informazioni, vedere come creare un certificato di firma del pacchetto e come firmare un pacchetto usando signtool

Usando PowerShell, installare il pacchetto.

Nota

Ricordarsi di disinstallare prima il pacchetto.

powershell Add-AppPackage .\PSFSamplePackageFixup.msix

Eseguire l'applicazione e osservare il comportamento con correzione di runtime applicata. Ripetere i passaggi di diagnostica e creazione del pacchetto in base alle esigenze.

Verificare se Package Support Framework è in esecuzione

È possibile verificare se la correzione di runtime è in esecuzione. Un modo per eseguire questa operazione consiste nell'aprire Gestione attività e fare clic su Altri dettagli. Trovare l'app a cui è stato applicato il framework di supporto del pacchetto ed espandere i dettagli dell'app per visualizzare altri dettagli. Dovrebbe essere possibile visualizzare che Package Support Framework è in esecuzione.

Usare la correzione della traccia

Una tecnica alternativa per diagnosticare i problemi di compatibilità delle applicazioni in pacchetto consiste nell'usare la correzione della traccia. Questa DLL è inclusa in PSF e fornisce una visualizzazione diagnostica dettagliata del comportamento dell'app, simile a Process Monitor. È appositamente progettato per rivelare i problemi di compatibilità delle applicazioni. Per usare Trace Fixup, aggiungere la DLL al pacchetto, aggiungere il frammento seguente al file config.json e quindi creare il pacchetto e installare l'applicazione.

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

Per impostazione predefinita, la correzione della traccia filtra gli errori che potrebbero essere considerati "previsti". Ad esempio, le applicazioni potrebbero provare a eliminare in modo incondizionato un file senza controllare se esiste già, ignorando il risultato. Ciò ha la sfortunata conseguenza che alcuni errori imprevisti potrebbero essere filtrati, quindi nell'esempio precedente si opta per ricevere tutti gli errori dalle funzioni del file system. Questa operazione viene eseguita perché è noto da prima che il tentativo di leggere dal file Config.txt non riesce con il messaggio "file non trovato". Si tratta di un errore osservato di frequente e non generalmente considerato imprevisto. In pratica è preferibile iniziare a filtrare solo gli errori imprevisti e quindi eseguire il fallback a tutti gli errori se si verifica un problema che non è ancora possibile identificare.

Per impostazione predefinita, l'output di Trace Fixup viene inviato al debugger collegato. Per questo esempio, non verrà collegato un debugger e verrà invece usato il programma DebugView da SysInternals per visualizzarne l'output. Dopo aver eseguito l'app, è possibile visualizzare gli stessi errori di prima, che ci inderebbero verso le stesse correzioni di runtime.

TraceShim File Not Found

TraceShim Access Denied

Eseguire il debug, estendere o creare una correzione di runtime

È possibile usare Visual Studio per eseguire il debug di una correzione di runtime, estendere una correzione di runtime o crearne una da zero. Dovrai eseguire queste operazioni per avere successo.

  • Aggiungere un progetto di creazione pacchetti
  • Aggiungere un progetto per la correzione di runtime
  • Aggiungere un progetto che avvia l'eseguibile dell'utilità di avvio PSF
  • Configurare il progetto di creazione del pacchetto

Al termine, la soluzione avrà un aspetto simile al seguente.

Completed solution

Esaminiamo ogni progetto in questo esempio.

Project Scopo
DesktopApplicationPackage Questo progetto si basa sul progetto Di creazione pacchetti di applicazioni Windows e restituisce il pacchetto MSIX.
Prefisso di runtime Si tratta di un progetto libreria dinamica collegata C++ che contiene una o più funzioni di sostituzione che fungono da correzione di runtime.
PSFLauncher Si tratta di un progetto vuoto C++. Questo progetto è un luogo in cui raccogliere i file distribuibili di runtime di Package Support Framework. Restituisce un file eseguibile. Il file eseguibile è la prima cosa che viene eseguita all'avvio della soluzione.
WinFormsDesktopApplication Questo progetto contiene il codice sorgente di un'applicazione desktop.

Per esaminare un esempio completo che contiene tutti questi tipi di progetti, vedere PSFSample.

Verranno ora illustrati i passaggi per creare e configurare ognuno di questi progetti nella soluzione.

Creare una soluzione di pacchetto

Se non si ha già una soluzione per l'applicazione desktop, creare una nuova soluzione vuota in Visual Studio.

Blank solution

È anche possibile aggiungere tutti i progetti di applicazione disponibili.

Aggiungere un progetto di creazione pacchetti

Se non si ha già un progetto di creazione pacchetti di applicazioni Windows, crearne uno e aggiungerlo alla soluzione.

Package project template

Per altre informazioni sul progetto di creazione pacchetti di applicazioni Windows, vedere Creare un pacchetto dell'applicazione usando Visual Studio.

In Esplora soluzioni fare clic con il pulsante destro del mouse sul progetto di creazione del pacchetto, scegliere Modifica e quindi aggiungerlo nella parte inferiore del file di progetto:

<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>

Aggiungere un progetto per la correzione di runtime

Aggiungere un progetto DLL (Dynamic Link Library) C++ alla soluzione.

Runtime fix library

Fare clic con il pulsante destro del mouse sul progetto e scegliere Proprietà.

Nelle pagine delle proprietà individuare il campo Standard del linguaggio C++ e quindi nell'elenco a discesa accanto a tale campo selezionare l'opzione ISO C++17 Standard (/std:c++17).

ISO 17 Option

Fare clic con il pulsante destro del mouse sul progetto e scegliere l'opzione Gestisci pacchetti NuGet dal menu di scelta rapida. Assicurarsi che l'opzione Origine pacchetto sia impostata su Tutti o nuget.org.

Fare clic sull'icona delle impostazioni accanto a tale campo.

Cercare il pacchetto NuGet PSF* e quindi installarlo per questo progetto.

nuget package

Se si vuole eseguire il debug o estendere una correzione di runtime esistente, aggiungere i file di correzione di runtime ottenuti usando le indicazioni descritte nella sezione Trovare una correzione di runtime di questa guida.

Se si intende creare una nuova correzione, non aggiungere ancora nulla a questo progetto. Più avanti in questa guida verranno aggiunti i file corretti a questo progetto. Per il momento, si continuerà a configurare la soluzione.

Aggiungere un progetto che avvia l'eseguibile dell'utilità di avvio PSF

Aggiungere un progetto progetto vuoto C++ alla soluzione.

Empty project

Aggiungere il pacchetto NuGet PSF a questo progetto usando le stesse indicazioni descritte nella sezione precedente.

Aprire le pagine delle proprietà per il progetto e nella pagina Impostazioni generali impostare la proprietà Nome destinazione su PSFLauncher32 o PSFLauncher64 a seconda dell'architettura dell'applicazione.

PSF Launcher reference

Aggiungere un riferimento al progetto di correzione del runtime nella soluzione.

runtime fix reference

Fare clic con il pulsante destro del mouse sul riferimento e quindi nella finestra Proprietà applicare questi valori.

Proprietà valore
Copiare localmente True
Copia assembly satellite locale True
Output assembly di riferimento True
Collega dipendenze di libreria False
Input delle dipendenze della libreria di collegamenti False

Configurare il progetto di creazione del pacchetto

Nel progetto di creazione del pacchetto fare clic con il pulsante destro del mouse sulla cartella Applicazioni e quindi scegliere Aggiungi riferimento.

Add Project Reference

Scegliere il progetto di utilità di avvio PSF e il progetto di applicazione desktop, quindi scegliere il pulsante OK .

Desktop project

Nota

Se non si dispone del codice sorgente per l'applicazione, è sufficiente scegliere il progetto utilità di avvio PSF. Verrà illustrato come fare riferimento al file eseguibile quando si crea un file di configurazione.

Nel nodo Applicazioni fare clic con il pulsante destro del mouse sull'applicazione Launcher PSF e quindi scegliere Imposta come punto di ingresso.

Set entry point

Aggiungere un file denominato config.json al progetto di creazione del pacchetto, quindi copiare e incollare il testo JSON seguente nel file. Impostare la proprietà Azione pacchetto su Contenuto.

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

Specificare un valore per ogni chiave. Usare questa tabella come riferimento.

Matrice key valore
applications ID Usare il valore dell'attributo Id dell'elemento Application nel manifesto del pacchetto.
applications eseguibile Percorso relativo al pacchetto dell'eseguibile da avviare. Nella maggior parte dei casi, è possibile ottenere questo valore dal file manifesto del pacchetto prima di modificarlo. È il valore dell'attributo Executable dell'elemento Application .
applications Workingdirectory (Facoltativo) Percorso relativo al pacchetto da usare come directory di lavoro dell'applicazione che viene avviata. Se non si imposta questo valore, il sistema operativo usa la System32 directory come directory di lavoro dell'applicazione.
di sistema eseguibile Nella maggior parte dei casi, questo sarà il nome dell'oggetto executable configurato in precedenza con il percorso e l'estensione di file rimossi.
correzioni Libreria dll Percorso relativo al pacchetto della DLL di correzione da caricare.
correzioni config (Facoltativo) Controlla il comportamento della DLL di correzione. Il formato esatto di questo valore varia in base alla correzione per correzione, perché ogni correzione può interpretare questo "BLOB" come vuole.

Al termine, il config.json file avrà un aspetto simile al seguente.

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

Nota

Le applicationschiavi , processese fixups sono matrici. Ciò significa che è possibile usare il file config.json per specificare più di un'applicazione, un processo e una DLL di correzione.

Eseguire il debug di una correzione di runtime

In Visual Studio premere F5 per avviare il debugger. La prima cosa che viene avviata è l'applicazione Launcher PSF, che a sua volta avvia l'applicazione desktop di destinazione. Per eseguire il debug dell'applicazione desktop di destinazione, è necessario collegarsi manualmente al processo dell'applicazione desktop scegliendo Debug-Collega> a processo e quindi selezionando il processo dell'applicazione. Per consentire il debug di un'applicazione .NET con una DLL di correzione del runtime nativo, selezionare tipi di codice gestiti e nativi (debug in modalità mista).

Dopo aver configurato questa impostazione, è possibile impostare punti di interruzione accanto a righe di codice nel codice dell'applicazione desktop e nel progetto di correzione del runtime. Se non si dispone del codice sorgente per l'applicazione, sarà possibile impostare punti di interruzione solo accanto a righe di codice nel progetto di correzione del runtime.

Poiché il debug F5 esegue l'applicazione distribuendo file separati dal percorso della cartella del layout del pacchetto, invece di eseguire l'installazione da un pacchetto con estensione msix/.appx, la cartella di layout in genere non presenta le stesse restrizioni di sicurezza di una cartella del pacchetto installato. Di conseguenza, potrebbe non essere possibile riprodurre gli errori di negazione dell'accesso al percorso del pacchetto prima di applicare una correzione di runtime.

Per risolvere questo problema, usare la distribuzione di pacchetti con estensione msix/appx anziché la distribuzione di file separati F5. Per creare un file di pacchetto con estensione msix/appx, usare l'utilità MakeAppx di Windows SDK, come descritto in precedenza. In alternativa, dall'interno di Visual Studio fare clic con il pulsante destro del mouse sul nodo del progetto dell'applicazione e selezionare Store - Create App Packages (Store -> Crea pacchetti app).

Un altro problema con Visual Studio è che non dispone del supporto predefinito per il collegamento a processi figlio avviati dal debugger. Ciò rende difficile eseguire il debug della logica nel percorso di avvio dell'applicazione di destinazione, che deve essere collegato manualmente da Visual Studio dopo l'avvio.

Per risolvere questo problema, usare un debugger che supporta il collegamento di processi figlio. Si noti che in genere non è possibile collegare un debugger JIT (Just-In-Time) all'applicazione di destinazione. Ciò è dovuto al fatto che la maggior parte delle tecniche JIT implica l'avvio del debugger al posto dell'app di destinazione, tramite la chiave del Registro di sistema ImageFileExecutionOptions. In questo modo il meccanismo di deviazione usato da PSFLauncher.exe viene sconfitto per inserire FixupRuntime.dll nell'app di destinazione. WinDbg, incluso negli strumenti di debug per Windows e ottenuto da Windows SDK, supporta il collegamento di processi figlio. Ora supporta anche l'avvio diretto e il debug di un'app UWP.

Per eseguire il debug dell'avvio dell'applicazione di destinazione come processo figlio, avviare WinDbg.

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

WinDbg Al prompt abilitare il debug figlio e impostare i punti di interruzione appropriati.

.childdbg 1
g

(eseguire fino all'avvio e all'interruzione dell'applicazione di destinazione nel debugger)

sxe ld fixup.dll
g

(eseguire fino al caricamento della DLL fixup)

bp ...

Nota

IL DEBUGGERDebug può essere usato anche per collegare un debugger a un'app al momento dell'avvio ed è incluso anche in Strumenti di debug per Windows. Tuttavia, è più complesso usare rispetto al supporto diretto ora fornito da WinDbg.

Supporto tecnico

Altre domande? Chiedici nello spazio di conversazione Package Support Framework nel sito della community tecnica MSIX.