WDAC-Debuggen und -Problembehandlung

Hinweis

Einige Funktionen von Windows Defender Anwendungssteuerung sind nur in bestimmten Windows-Versionen verfügbar. Erfahren Sie mehr über die Verfügbarkeit der Windows Defender Anwendungssteuerungsfeature.

In diesem Artikel wird beschrieben, wie Sie App- und Skriptfehler bei verwendung von Windows Defender Anwendungssteuerung (WDAC) debuggen und beheben.

1. Sammeln von WDAC-Diagnosedaten

Vor dem Debuggen und Behandeln von WDAC-Problemen müssen Sie Informationen von einem Gerät sammeln, das das Problemverhalten aufweist.

Führen Sie die folgenden Befehle in einem PowerShell-Fenster mit erhöhten Rechten aus, um die diagnoseinformationen zu sammeln, die Sie möglicherweise benötigen:

  1. Sammeln Sie allgemeine WDAC-Diagnosedaten, und kopieren Sie sie in %userprofile%\AppData\Local\Temp\DiagOutputDir\CiDiag:

    cidiag.exe /stop

    Wenn CiDiag.exe in Ihrer Windows-Version nicht vorhanden ist, sammeln Sie diese Informationen manuell:

  2. Speichern Sie die Systeminformationen des Geräts im Ordner CiDiag:

    msinfo32.exe /report $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\SystemInformation.txt

  3. Verwenden Sie CiTool.exe , um die Liste der WDAC-Richtlinien auf dem Gerät zu inventarisieren. Überspringen Sie diesen Schritt, wenn CiTool.exe in Ihrer Version von Windows nicht vorhanden ist.

    citool.exe -lp -json > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\CiToolOutput.json

  4. Exportieren Sie AppLocker-Registrierungsschlüsseldaten in den Ordner CiDiag:

    reg.exe query HKLM\Software\Policies\Microsoft\Windows\SrpV2 /s > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerRegistry.txt; reg.exe query HKLM\Software\Policies\Microsoft\Windows\AppidPlugins /s >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerRegistry.txt; reg.exe query HKLM\System\CurrentControlSet\Control\Srp\ /s >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerRegistry.txt

    Hinweis

    Möglicherweise wird ein Fehler angezeigt, dass das System den angegebenen Registrierungsschlüssel oder Wert nicht finden konnte. Dieser Fehler weist nicht auf ein Problem hin und kann ignoriert werden.

  5. Kopieren Sie alle AppLocker-Richtliniendateien aus %windir%System32\AppLocker in den Ordner CiDiag:

    Copy-Item -Path $env:windir\System32\AppLocker -Destination $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\ -Recurse -Force -ErrorAction Ignore

  6. Sammeln Sie Dateiinformationen für die Im vorherigen Schritt gesammelten AppLocker-Richtliniendateien:

    Get-ChildItem -Path $env:windir\System32\AppLocker\ -Recurse | select Mode,LastWriteTime,CreationTime,Length,Name >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerPolicyFiles.txt

  7. Exportieren Sie die effektive AppLocker-Richtlinie:

    Get-AppLockerPolicy -xml -Effective > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLocker.xml

  8. Sammeln Sie Konfigurations- und Zustandsinformationen für AppLocker-Dienste:

    sc.exe query appid > $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt; sc.exe query appidsvc >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt; sc.exe query applockerfltr >> $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt

Core WDAC-Ereignisprotokolle

WDAC-Ereignisse werden an zwei Speicherorten generiert:

  • Anwendungs- und Dienstprotokolle – Microsoft – Windows – CodeIntegrity – Betriebsbereit
  • Anwendungs- und Dienstprotokolle – Microsoft – Windows – AppLocker – MSI und Skript

Im CiDiag-Ausgabeverzeichnis werden diese Ereignisprotokolle ciOperational.evtx bzw. ALMsiAndScript.evtx genannt.

Andere Windows-Ereignisprotokolle, die nützlich sein können

In einigen Fällen können Sie die informationen, die in den grundlegenden WDAC-Ereignisprotokollen enthalten sind, durch Informationen in diesen anderen Ereignisprotokollen ergänzen. CIDiag.exe erfasst nicht die kursiv dargestellten.

  • Anwendungs- und Dienstprotokolle – Microsoft – Windows – CodeIntegrity – Ausführlich
  • Anwendungs- und Dienstprotokolle – Microsoft – Windows – AppLocker – EXE und DLL
  • Anwendungs- und Dienstprotokolle – Microsoft – Windows – AppLocker – App-Paketbereitstellung
  • Anwendungs- und Dienstprotokolle – Microsoft – Windows – AppLocker – App-Paketausführung
  • Anwendungs- und Dienstprotokolle – Microsoft – Windows – AppID – Betriebsbereit
  • Anwendungs- und Dienstprotokolle – Microsoft – Windows – CAPI2 – Betriebsbereit
  • Anwendungs- und Dienstprotokolle – Microsoft – Windows – DeviceGuard – Betriebsbereit
  • Anwendungs- und Dienstprotokolle – Microsoft – Windows – PowerShell – *
  • Windows – Anwendung
  • Windows – System

2 – Verwenden der Diagnose- und Protokolldaten zum Identifizieren von Problemen

Nachdem Sie die erforderlichen Diagnoseinformationen von einem Gerät gesammelt haben, können Sie mit der Analyse der im vorherigen Abschnitt gesammelten Diagnosedaten beginnen.

  1. Überprüfen Sie den Satz von WDAC-Richtlinien, die aktiv sind und erzwungen werden. Vergewissern Sie sich, dass nur die Richtlinien aktiv sind, von denen Sie erwarten, dass sie aktiv sind. Beachten Sie die Windows-Posteingangsrichtlinien , die möglicherweise auch aktiv sind. Sie können eine der folgenden Methoden verwenden:

  2. Überprüfen Sie alle Blockereignisse für ausführbare Dateien, DLLs und Treiber aus dem WDAC-Kernereignisprotokoll unter Anwendungs- und Dienstprotokolle – Microsoft – Windows – CodeIntegrity – Betriebsbereit. Innerhalb des CIDiag-Ausgabeverzeichnisses heißt dieses Ereignisprotokoll CIOperational.evtx. Verwenden Sie Informationen aus den Blockereignissen und deren korrelierten 3089-Signaturdetailsereignissen, um alle Blöcke zu untersuchen, die ungeklärt oder unerwartet sind. Weitere Informationen finden Sie weiter unten in diesem Artikel beschrieben im Beispiel für eine blockierte ausführbare Datei.

  3. Überprüfen Sie alle Blockereignisse für gepackte Apps, MSI-Installationsprogramme, Skripts und COM-Objekte aus dem Hauptereignisprotokoll zur Skripterzwingung unter Anwendungs- und Dienstprotokolle – Microsoft – Windows – AppLocker – MSI und Skript. Im CIDiag-Ausgabeverzeichnis heißt dieses Ereignisprotokoll ALMsiAndScript.evtx. Verwenden Sie Informationen aus den Blockereignissen und deren korrelierten 8038-Signaturdetailsereignissen, um Blöcke zu untersuchen, die unerklärlich oder unerwartet sind.

Die meisten WDAC-bezogenen Probleme, einschließlich App- und Skriptfehlern, können mithilfe der vorherigen Schritte diagnostiziert werden.

Ereignisanalyse für eine blockierte ausführbare Beispieldatei

Hier sehen Sie ein Beispiel für detaillierte EventData aus einem typischen Blockereignis des WDAC-Erzwingungsmodus 3077 und eines der korrelierten 3089-Signaturinformationsereignisse. In den Tabellen, die auf den Screenshot jedes Ereignisses folgen, werden einige der elemente beschrieben, die in den Ereignissen enthalten sind. Das Folgen der Ereignisbeschreibungen ist eine schritt-für-Schritt-exemplarische Vorgehensweise, in der erläutert wird, wie Sie die Ereignisse verwenden, um zu verstehen, warum der Block aufgetreten ist.

Ereignis 3077 – WDAC-Erzwingungsblockereignis

Beispiel 3077 Blockereignis für PowerShell.exe.

Elementname Beschreibung
System – Korrelation – [ActivityID] Nicht im Screenshot angezeigt
Verwenden Sie die Korrelationsaktivitäts-ID, um ein WDAC-Blockereignis mit einem oder mehreren 3089-Signaturereignissen abzugleichen.
Dateiname Der Pfad und Name der Datei auf dem Datenträger, der für die Ausführung blockiert wurde. Da der Name auf dem Datenträger änderbar ist, ist dieser Wert nicht der, der beim Erstellen von WDAC-Dateiregeln mit -Level FileNameverwendet wird. Sehen Sie sich stattdessen das OriginalFileName-Element weiter unten in dieser Tabelle an.
Prozessname Der Pfad und Name der Datei, die versucht hat, die blockierte Datei auszuführen. Wird auch als übergeordneter Prozess bezeichnet.
Angeforderte Signaturstufe Die Windows-Signaturautorisierungsebene, die der Code übergeben muss, um ausgeführt zu werden. Weitere Informationen finden Sie unter Angeforderte und überprüfte Signaturstufe.
Überprüfte Signaturstufe Die Windows-Signaturautorisierungsstufe, die dem Code gegeben wurde. Weitere Informationen finden Sie unter Angeforderte und überprüfte Signaturstufe.
Status Windows NT status Code. Sie können verwendencertutil.exe -error <status>, um die Bedeutung des status Codes nachzuschlagen.
SHA1-Hash Der SHA1 Authenticode-Hash für die blockierte Datei.
SHA256-Hash Der SHA256 Authenticode-Hash für die blockierte Datei.
SHA1 Flat Hash Der SHA1-Flatfile-Hash für die blockierte Datei.
SHA256 Flat Hash Der SHA256-Flatfile-Hash für die blockierte Datei.
Policyname Der Anzeigename der WDAC-Richtlinie, die das Blockereignis verursacht hat. Für jede Richtlinie, die die Ausführung der Datei blockiert, wird ein separates 3077-Blockereignis (oder 3076 Überwachungsblockereignis) angezeigt.
PolicyId Der Wert der benutzerfreundlichen ID der WDAC-Richtlinie, die das Blockereignis verursacht hat.
PolicyHash Der SHA256 Authenticode-Hash der WDAC-Richtlinienbinärdatei, die das Blockereignis verursacht hat.
OriginalFileName Der unveränderliche Dateiname, der vom Entwickler im Ressourcenheader der blockierten Datei festgelegt wird. Dieser Wert wird beim Erstellen von WDAC-Dateiregeln mit -Level FileNameverwendet.
InternalName Ein weiterer unveränderlicher Wert, der vom Entwickler im Ressourcenheader der blockierten Datei festgelegt wird. Sie können diesen Wert für OriginalFileName in Dateiregeln durch -Level FileName -SpecificFileNameLevel InternalNameersetzen.
FileDescription Ein weiterer unveränderlicher Wert, der vom Entwickler im Ressourcenheader der blockierten Datei festgelegt wird. Sie können diesen Wert für OriginalFileName in Dateiregeln durch -Level FileName -SpecificFileNameLevel FileDescriptionersetzen.
ProductName Ein weiterer unveränderlicher Wert, der vom Entwickler im Ressourcenheader der blockierten Datei festgelegt wird. Sie können diesen Wert für OriginalFileName in Dateiregeln durch -Level FileName -SpecificFileNameLevel ProductNameersetzen.
FileVersion Der VersionEx-Wert der Richtlinie, der verwendet wird, um die Versionskontrolle für signierte Richtlinien zu erzwingen.
PolicyGUID Die PolicyId der WDAC-Richtlinie, die das Blockereignis verursacht hat.
UserWriteable Ein boolescher Wert, der angibt, ob sich die Datei an einem vom Benutzer schreibbaren Speicherort befand. Diese Informationen sind nützlich für die Diagnose von Problemen beim Zulassen von FilePath-Regeln.
PackageFamilyName Der Paketfamilienname für die gepackte App (MSIX), die die blockierte Datei enthält.

Ereignis 3089 – WDAC-Signaturinformationsereignis

Beispielereignis für 3089-Signaturinformationen für PowerShell.exe.

Elementname Beschreibung
System – Korrelation – [ActivityID] Verwenden Sie die Korrelationsaktivitäts-ID, um ein WDAC-Signaturereignis mit seinem Blockereignis abzugleichen.
TotalSignatureCount Die Gesamtanzahl der für die blockierte Datei erkannten Signaturen.
Signatur Die Indexanzahl der aktuellen Signatur, die bei 0 beginnt, die in diesem 3089-Ereignis angezeigt wird. Wenn die Datei mehrere Signaturen enthält, finden Sie weitere 3089-Ereignisse für die anderen Signaturen.
Hash Der Hashwert, den WDAC zum Abgleichen der Datei verwendet hat. Dieser Wert sollte mit einem der vier Hashes übereinstimmen, die im Blockereignis 3077 oder 3076 angezeigt werden. Wenn für die Datei keine Signaturen gefunden wurden (TotalSignatureCount = 0), wird nur der Hashwert angezeigt.
SignatureType Der Signaturtyp.
ValidatedSigningLevel Die Windows-Signaturautorisierungsstufe, die die Signatur erfüllt hat. Weitere Informationen finden Sie unter Angeforderte und überprüfte Signaturstufe.
VerificationError Der Grund, warum diese spezielle Signatur die WDAC-Richtlinie nicht übergeben konnte. Weitere Informationen finden Sie unter VerificationError.
Publishername Der CN-Wert (Common Name) aus dem Blattzertifikat.
Issuername Der CN-Wert aus dem höchsten verfügbaren Zertifikat in der Zertifikatkette. Diese Ebene ist in der Regel ein Zertifikat unterhalb des Stamms.
PublisherTBSHash Der TBS-Hash des Blattzertifikats.
IssuerTBSHash Der TBS-Hash des höchsten verfügbaren Zertifikats in der Zertifikatkette. Diese Ebene ist in der Regel ein Zertifikat unterhalb des Stamms.

Schritt-für-Schritt-Vorgehensweise zu den Beispielereignissen 3077 und 3089

Lassen Sie uns nun durchgehen, wie Sie die Ereignisdaten in den Beispielereignissen 3077 und 3089 verwenden, um zu verstehen, warum die WDAC-Richtlinie diese Datei blockiert hat.

Grundlegendes zur blockierten Datei und zum Blockkontext

Wenn Sie auf das Ereignis 3077 verweisen, suchen Sie die Informationen, die die Richtlinie identifizieren, die Datei, die blockiert wird, und den übergeordneten Prozess, der versucht hat, sie auszuführen. Berücksichtigen Sie diese Kontextinformationen, um zu bestimmen, ob der Block erwartet und gewünscht wird.

Im Beispiel ist die datei, die blockiert wird, PowerShell.exe, die Teil von Windows ist und normalerweise erwartet wird, dass sie ausgeführt wird. In diesem Fall basiert die Richtlinie jedoch auf der Richtlinienvorlage Windows im S Modus, die nicht zulässt, dass Skripthosts ausgeführt werden, um die Angriffsfläche zu begrenzen. Für den S-Modus ist dieses Blockereignis ein Erfolg. Angenommen, der Richtlinienautor wusste diese Einschränkung bei der Auswahl der Vorlage nicht und behandelt diesen Block als unerwartet.

Ermitteln, warum WDAC die Datei abgelehnt hat

Auch in Bezug auf das Ereignis 3077 sehen wir, dass die angeforderte Signaturstufe 2 bedeutet, dass der Code die WDAC-Richtlinie übergeben muss. Die überprüfte Signaturstufe 1 bedeutet jedoch, dass der Code wie unsigniert behandelt wurde. "Unsigned" kann bedeuten, dass die Datei wirklich nicht signiert, aber mit einem ungültigen Zertifikat signiert oder signiert wurde, aber ohne Zertifikate, die von der WDAC-Richtlinie zulässig sind.

Sehen wir uns nun die korrelierten 3089-Ereignisse für die blockierte Datei an. In diesem Beispiel betrachten wir nur die erste Signatur (Signaturindex 0), die in einer Datei mit mehreren Signaturen gefunden wurde. Für diese Signatur ist ValidatedSigningLevel 12, was bedeutet, dass es eine Microsoft Windows-Produktsignatur aufweist. Der VerificationError von 21 bedeutet, dass die Signatur die WDAC-Richtlinie nicht bestanden hat.

Es ist wichtig, die Informationen für jedes korrelierte 3089-Ereignis zu überprüfen, da jede Signatur einen anderen ValidatedSigningLevel und VerificationError aufweisen kann.

Wichtig

Beachten Sie, dass die Überprüfte Signaturstufe für das Ereignis 3077 ganz anders interpretiert wird als das ValidatedSigningLevel-Ereignis für das Ereignis 3089.

Im Fall des Ereignisses 3077 gibt die überprüfte Signaturstufe an, wie die Binärdatei tatsächlich von Windows behandelt wurde.

Im Fall des 3089-Ereignisses teilt Uns ValidatedSigningLevel hingegen mit, welche maximale Ebene die Signatur erhalten könnte. Wir müssen den VerificationError verwenden, um zu verstehen, warum die Signatur abgelehnt wurde.

3. Beheben allgemeiner Probleme

Nachdem Sie die WDAC-Diagnosedaten analysiert haben, können Sie schritte ausführen, um das Problem zu beheben oder weitere Debugschritte auszuführen. Im Folgenden finden Sie einige häufige Probleme und Schritte, die Sie versuchen können, das Grundproblem zu beheben oder weiter zu isolieren:

Problem: Eine Datei wurde blockiert, die Sie zulassen möchten.

  • Verwenden Sie Daten aus den kernen WDAC-Ereignisprotokollen, um Regeln hinzuzufügen, die die blockierte Datei zulassen.
  • Stellen Sie die Datei oder App mit einem verwalteten Installationsprogramm erneut bereit, wenn Ihre Richtlinie verwalteten Installationsprogrammen vertraut.

Problem: Eine Richtlinie ist aktiv, die unerwartet ist.

Diese Bedingung kann in folgenden Bedingungen vorhanden sein:

  • Eine Richtlinie wurde entfernt, aber das System wurde nicht neu gestartet.
  • Eine Richtlinie wurde teilweise entfernt, aber eine Kopie der Richtlinie ist weiterhin in der System- oder EFI-Partition vorhanden.
  • Eine Richtlinie mit der PolicyId {A244370E-44C9-4C06-B551-F6016E563076} (Einzelrichtlinienformat) wurde vor der Aktivierung in den Speicherort der Richtlinie im Format mehrerer Richtlinien kopiert, was zu einer doppelten Richtlinienbinärdatei auf dem Datenträger führte. Überprüfen Sie die Dateien SiPolicy.p7b und {A244370E-44C9-4C06-B551-F6016E563076}.cip in den Partitionen System und EFI.
  • Eine Richtlinie wurde fälschlicherweise auf dem Gerät bereitgestellt.
  • Ein Angreifer mit Administratorzugriff hat eine Richtlinie angewendet, um eine Denial-of-Service-Instanz für einige kritische Prozesse auszulösen.

Um ein solches Problem zu beheben, befolgen Sie die Anweisungen unter Entfernen von WDAC-Richtlinien für die identifizierte Richtlinie.

Problem: Es tritt ein nicht behandelter App-Fehler auf, und es werden keine WDAC-Ereignisse beobachtet.

Einige Apps ändern ihr Verhalten, wenn eine WDAC-Richtlinie im Benutzermodus aktiv ist, was zu unerwarteten Fehlern führen kann. Dies kann auch ein Nebeneffekt der Skripterzwingung für Apps sein, die das von den Skripthosts implementierte Erzwingungsverhalten nicht ordnungsgemäß behandeln.

Versuchen Sie, die Grundursache zu isolieren, indem Sie die folgenden Aktionen ausführen:

  • Überprüfen Sie die anderen Ereignisprotokolle, die in Abschnitt 1 dieses Artikels aufgeführt sind, auf Ereignisse, die den unerwarteten App-Fehlern entsprechen.
  • Ersetzen Sie die WDAC-Richtlinie vorübergehend durch eine andere Richtlinie, die die Skripterzwingung und den erneuten Test deaktiviert .
  • Ersetzen Sie die WDAC-Richtlinie vorübergehend durch eine andere Richtlinie, die alle COM-Objekte zulässt und erneut testen kann.
  • Ersetzen Sie die WDAC-Richtlinie vorübergehend durch eine andere Richtlinie, die andere Richtlinienregeln lockert und einen erneuten Test ausführt.

Problem: Eine von einem verwalteten Installationsprogramm bereitgestellte App funktioniert nicht.

Führen Sie die folgenden Schritte aus, um Probleme mit dem verwalteten Installationsprogramm zu debuggen:

  • Überprüfen Sie, ob die WDAC-Richtlinie, die die App blockiert, die Option zum Aktivieren des verwalteten Installationsprogramms enthält.
  • Überprüfen Sie, ob die effektive AppLocker-Richtlinie $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLocker.xml richtig ist, wie unter Automatisches Zulassen von Apps, die von einem verwalteten Installationsprogramm bereitgestellt werden, beschrieben wird.
  • Überprüfen Sie, ob die AppLocker-Dienste ausgeführt werden. Diese Informationen finden Sie in $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt erstellt in Abschnitt 1 dieses Artikels.
  • Überprüfen Sie, ob eine AppLocker-Datei mit dem Namen MANAGEDINSTALLER vorhanden ist. APPLOCKER ist im zuvor erstellten CiDiag-Ordner vorhanden. Wenn dies nicht der Fall ist, wiederholen Sie die Schritte zum Bereitstellen und Aktivieren der AppLocker-Konfiguration des verwalteten Installationsprogramms.
  • Starten Sie den Prozess des verwalteten Installers neu, und überprüfen Sie mit PolicyName = MANAGEDINSTALLER, ob im Ereignisprotokoll AppLocker – EXE und DLL für den Prozess des verwalteten Installationsprogramms ein Ereignis 8002 beobachtet wird. Wenn stattdessen ein Ereignis mit 8003 oder 8004 mit PolicyName = MANAGEDINSTALLER angezeigt wird, überprüfen Sie die ManagedInstaller-Regeln im AppLocker-Richtlinien-XML, und stellen Sie sicher, dass eine Regel dem prozess des verwalteten Installationsprogramms entspricht.
  • Verwenden Sie fsutil.exe , um zu überprüfen, ob Dateien, die vom Prozess des verwalteten Installationsprogramms geschrieben wurden, über das erweiterte Attribut "Verwalteter Installerursprung" verfügen. Wenn nicht, stellen Sie die Dateien mit dem verwalteten Installationsprogramm erneut bereit, und überprüfen Sie es erneut.
  • Testen Sie die Installation einer anderen App mithilfe des verwalteten Installationsprogramms.
  • Fügen Sie Ihrer AppLocker-Richtlinie ein weiteres verwaltetes Installationsprogramm hinzu, und testen Sie die Installation mithilfe des anderen verwalteten Installationsprogramms.
  • Überprüfen Sie, ob die App mit dem verwalteten Installationsprogramm auf eine bekannte Einschränkung stößt. Wenn ja, müssen Sie die App mit anderen Mitteln autorisieren.

Problem: Eine App, die der Intelligent Security Graph (ISG) zulässt, funktioniert nicht.

Führen Sie die folgenden Schritte aus, um Probleme mithilfe von ISG zu debuggen:

  • Überprüfen Sie, ob die WDAC-Richtlinie, die die App blockiert, die Option zum Aktivieren des intelligenten Sicherheitsdiagramms enthält.
  • Überprüfen Sie, ob die AppLocker-Dienste ausgeführt werden. Diese Informationen finden Sie in $env:USERPROFILE\AppData\Local\Temp\DiagOutputDir\CiDiag\AppLockerServices.txt erstellt in Abschnitt 1 dieses Artikels.
  • Verwenden Sie fsutil.exe , um zu überprüfen, ob Dateien über das erweiterte Attribut des ISG-Ursprungs verfügen. Wenn nicht, stellen Sie die Dateien mit dem verwalteten Installationsprogramm erneut bereit, und überprüfen Sie es erneut.
  • Überprüfen Sie, ob für die App eine bekannte Einschränkung mit ISG auftritt.

4. Melden von Problemen an Microsoft, falls zutreffend

Wenn Sie nach dem Befolgen der in diesem Artikel beschriebenen Anleitungen der Meinung sind, dass Sie ein Produktproblem identifiziert haben, melden Sie das Problem an Microsoft.

  • Kunden mit Microsoft Premier Support sollten eine Serviceanfrage über normale Kanäle protokollieren.
  • Alle anderen Kunden können Probleme direkt an das WDAC-Produktteam über den Windows Feedback Hub melden. Wählen Sie die Kategorie Sicherheit & Datenschutz – Anwendungssteuerung aus, um sicherzustellen, dass das Problem ordnungsgemäß an das WDAC-Produktteam weitergeleitet wird.

Stellen Sie beim Melden von Problemen sicher, dass Sie die folgenden Informationen angeben:

  • Alle zuvor beschriebenen WDAC-Diagnosedaten .
  • Wenn möglich, die blockierten Dateien.
  • Klare Anweisungen zum Reproduzieren des Problems.