Tray App unter WinSrv2022

[vnvjan]

Für ein kleines Tool, welches einen Windows Dienst überwacht, nutz ich ein TTrayIcon.
Unter Win10 ist alles iO...die App läuft und das Icon wird im Tray angezeigt.
Sobald ich die App aber unter WinSrv2022 starte, erscheint das Icon nicht im Tray bzw. die App ansich wird nicht gestartet. Egal wie ich es starte (mit/ohne Adminrechte). Ich habe in den Compilereinstellungen unter Linking schon die "Data Execution Prevention compatible" auf false gesetzt.
Gibts hier irgend einen Kniff oder startet der Srv nur signierte Apps?

[himitsu]

Ein Dienst hat "normal" keinen Zugriff auf den Desktop.
Und offiziell war das auch unter Windows 10 schon seit über 10 Jahren so ... tja, wer sich darauf verlässt, dass ein "interaktiver Dienst" es dennoch konnte, war selbst Schuld.

Drum starten die Dienste aller anderen auch eine weitere Anwendung, im Kontext des angemeldeten Benutzers, welcher sich dort anzeigt.

[lxo]

Zitat:

Zitat von himitsu (Beitrag 1540982)

Ein Dienst hat "normal" keinen Zugriff auf den Desktop.
Und offiziell war das auch unter Windows 10 schon seit über 10 Jahren so ... tja, wer sich darauf verlässt, dass ein "interaktiver Dienst" es dennoch konnte, war selbst Schuld.

Drum starten die Dienste aller anderen auch eine weitere Anwendung, im Kontext des angemeldeten Benutzers, welcher sich dort anzeigt.

Davon ist doch auch gar nicht die Rede, wie ich das rauslese.
Es geht ja um ein Tool das einen Dienst überwacht.
Also eine Art Verwaltungstool für den Dienst.

[himitsu]

Upps, aber es wird auch in richtigen aktiven UserSession gestartet?

Und in der Ereignisanzeige vom Windows steht auch nichts? (z.B. Windows-Protokolle > Anwendungen)
Oder im Virenscanner?

[Kas Ob.]

Zitat:

Zitat von vnvjan (Beitrag 1540981)

Gibts hier irgend einen Kniff oder startet der Srv nur signierte Apps?

Nope, on the contrary, on Windows Server Editions the Digital Signature is a little more relaxed than the other Editions, the assumption is the OS should be hardened enough and doesn't allow arbitrary users to run/install arbitrary software, these system managed by professionals as administrators.

Suggestion :
Use EurekaLog or Madshi to find and log a critical bug that your monitor have, most likely something to do with Windows Shell,
are you using exotic component(s) ?
and what about theming ?
Is there missed/mixed DLLs ?

Make sure you have logging facility (or the exception tools i mentioned) and see where this application is stopping, did it run and crash or the OS stopped it form running, because also that could be a policy, like a policy to prevent uploaded binary through RDP from running, these can go into quarantine waiting for Administrator to whitelist them.
Have a look at this from 2021
https://techcommunity.microsoft.com/...e/ba-p/2724685
This is very simple example, the search gave me this one as top (for some reason) on how Microsoft do introduce/change policies by default.

[Kas Ob.]

After little more thinking, i believe there must be a report in case the OS involved, so as Frank suggested start with Event Viewer.

[vnvjan]

Ok...ums mal zu lüften. Ich entwickle mir ein Monitoringtool ähnlich dem Apache Monitor für Subversion. Den SVN Server Dienst kann man sich schnell selbst installieren, aber ich hab das alles mal als Installpackage zusammengepackt. Anbei mal nen Screen bzw. das installierbare Projekt.
Wahrscheinlich ist es nur ein Benutzer bzw. Rechteproblem. Aber ich würde das Ganze gern unter WinSrv zum Laufen bekommen.
Da ich das nur für mich zum Spaß mache ist das nur als Test gedacht. Klar...es gibt mit Sicherheit schon ettliche andere Tools dieser Art.

[vnvjan]

Hier noch die Meldung aus dem EventViewer:

Code:

Name der fehlerhaften Anwendung: SVNServerAgent.exe, Version: 1.0.0.8, Zeitstempel: 0x66e1d546
Name des fehlerhaften Moduls: SVNServerAgent.exe, Version: 1.0.0.8, Zeitstempel: 0x66e1d546
Ausnahmecode: 0xc0000005
Fehleroffset: 0x000000000000da89
ID des fehlerhaften Prozesses: 0x428
Startzeit der fehlerhaften Anwendung: 0x01db069fd708ed16
Pfad der fehlerhaften Anwendung: C:\Program Files\SVN Server\agent\SVNServerAgent.exe
Pfad des fehlerhaften Moduls: C:\Program Files\SVN Server\agent\SVNServerAgent.exe
Berichtskennung: adaffd31-417b-4964-90e2-6ffd80b51809
Vollständiger Name des fehlerhaften Pakets: 
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

[himitsu]

$C0000005 = ACCESS_VIOLATION aka Zugriffsverletzung

Offset $000000000000da89 ... ja, in den ersten 64 KB ist wirklich garnichts (gesperrter Bereich, wo ausschließlich Treiber und der Kernel drauf kommen)
vielleicht irgendwas mit einem NIL-Pointer?

[vnvjan]

Übern Process Monitor konnte ich das Problem jetzt erfolgreich ausfindig machen.

Ursache war schlicht und ergreifend ein verwendetes SVG, was ich als Banner innerhalb der App benutze.
TImage + SVG verwendet Skia. Und hier liegt irgendwie in Skia der Hund begraben. Wenn Skia mit der App nicht verteilt wird (welche Bibliotheken auch immer dazu gehören), dann passiert auch einfach nix...bzw. taucht auch mal ein Runtime Error 217 auf.
Also hab ich die Skia Packages deaktiviert, im Source den Verweis auf die Skia-Units rausgeschmissen und ein normales PNG benutzt. Und siehe da...jetzt redet die App wieder mit Win2022Srv. 8-)