☰

Die App stürzt sofort ab, wenn sie von einem Domänencomputer ausgeführt wird. Wenn der Computer aus der Domäne entfernt wird, läuft sie einwandfrei

tag-icon • tag-icon group-policy domain application
Die App stürzt sofort ab, wenn sie von einem Domänencomputer ausgeführt wird. Wenn der Computer aus der Domäne entfernt wird, läuft sie einwandfrei

Unser Unternehmen hat eine neue Windows-App für die Verbindung mit einer SQL-Datenbank entwickelt. Wenn die App außerhalb der Domänenumgebung ausgeführt wird, funktioniert sie einwandfrei. Wenn der Computer, auf dem sie ausgeführt wird, an die Domäne angeschlossen ist, stürzt die App sofort ab.

Ich habe ein paar Fehler gefunden, die meiner Meinung nach auf das Problem hinweisen könnten, aber ich bin mir nicht sicher, wie ich sie genau interpretieren soll oder was das Programm behindern könnte. Ich glaube nicht, dass es ein Problem mit der Firewall ist, da das Programm einwandfrei funktioniert, wenn der PC nicht in der Domäne ist. Ich habe jede Gruppenrichtlinieneinstellung durchgesehen und es scheint auch dort nichts zu geben, was den Betrieb der App behindern könnte, obwohl es unter den gegebenen Umständen ein wahrscheinlicher Übeltäter zu sein scheint.

Hier sind die Fehler:

Anwendungsprotokoll

Faulting application name: WcBc.UWP.exe, version: 1.0.0.0, time stamp: 0x5e1b7efb
Faulting module name: ntdll.dll, version: 10.0.18362.418, time stamp: 0x99ca0526
Exception code: 0xc0000005
Fault offset: 0x000000000001792d
Faulting process id: 0x5e2c
Faulting application start time: 0x01d5cd738a0fa05b
Faulting application path: C:\Program Files\WindowsApps\WcBc_6.0.3.0_x64__x092f3jx59vf4\WcBc.UWP.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: fc0e2bd5-9704-4ad2-b601-b61c8bfd53a7
Faulting package full name: WcBc_6.0.3.0_x64__x092f3jx59vf4
Faulting package-relative application ID: App

Sicherheitsprotokoll

The Windows Filtering Platform has blocked a packet.

Application Information:
               Process ID:                           24108
               Application Name:              \device\harddiskvolume3\program files\windowsapps\wcbc_6.0.3.0_x64__x092f3jx59vf4\wcbc.uwp.exe

Network Information:
               Direction:                             Outbound
               Source Address:                   10.80.243.64
               Source Port:                         58988
               Destination Address:           10.101.10.18
               Destination Port:                 4118
               Protocol:               6

Filter Information:
               Filter Run-Time ID:              71531
               Layer Name:                         Connect
               Layer Run-Time ID:              48

Antwort1

Die Entwickler sollten Ihnen sagen können, wo genau der Fehler liegt, aber ich gehe davon aus, dass es an der Sicherheit des Ordners in WindowsApps liegt. Versuchen Sie, die App mit erhöhten Rechten auszuführen und sehen Sie, ob das funktioniert.

Wenn ja, dann würde ich sagen, dass die App nicht richtig entwickelt ist, da Benutzer normalerweise nicht in Programmdateien schreiben können, aber in ProgramData, wo alle von der Anwendung generierten Daten gespeichert werden sollten.

Wenn nicht, gewähren Sie ihnen Zugriff auf Ihre Umgebung, damit sie es in Ihrer Umgebung testen und debuggen können, oder bitten Sie sie, ein detailliertes Protokoll in eine Datei zu schreiben, das bei der Analyse hilft.

PS: Wenn Sie können, richten Sie eine schnelle Domäne mit SQL Server ein und testen Sie sie in der Standardumgebung. Wenn es dort funktioniert, handelt es sich um eine Gruppenrichtlinie. Arbeiten Sie also rückwärts, indem Sie eine nach der anderen hinzufügen, bis Sie herausfinden, wo es nicht funktioniert.

Antwort2

Da Sie mit Reverse Engineering arbeiten, scheint es, als könnten Sie den Filter anhand der Filterlaufzeit-ID selbst identifizieren.

Aus den Dokumenten [hier][1] sollten Sie in der Lage sein, die Sperrschicht über netsh wfp show filtersdie Filterlaufzeit-ID 71531 zu ermitteln und dort nachzuschauen (Filter Run-Time ID: 71531

Filter Run-Time ID [Type = UInt64]: unique filter ID which blocked the packet.

Um einen bestimmten Filter der Windows Filtering Platform nach ID zu finden, müssen Sie den folgenden Befehl ausführen: netsh wfp show filters. Als Ergebnis dieses Befehls wird die Datei filters.xml generiert. Sie müssen diese Datei öffnen und eine bestimmte Teilzeichenfolge mit der erforderlichen Filter-ID () finden.

Damit sollten Sie einen Ausgangspunkt haben. Außerhalb von GPO gibt es noch einige andere Elemente, bei denen eine Fehlerbehebung sinnvoll sein könnte:

Kerberos und Authentifizierung: Befindet sich der SQL-Server auch in der Domäne? Wird er über den DNS-Namen oder die IP-Adresse verwendet? SQL-Konto oder Domänenkonto? Gibt es einen Zeitunterschied von mehr als 5 Minuten? (https://web.mit.edu/Kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Clock-Skew.html)

Firewall auf der Empfangsseite: Sie stellen eine Verbindung zu einem anderen Subnetz her. Liegt möglicherweise ein Firewall-/Routenproblem vor, das konfiguriert werden muss?

viel Glück!

verwandte Informationen