23
Heruasfinden, warum ein Programm die Benutzerkontensteuerung auf den Plan ruft
Hallo zusammen,
kann man irgendwie herausfinden, warum ein bestimmtes Programm die Benutzerkontensteuerung auf den Plan ruft?
Konkret geht es um das Programm PDFMetaEdit, und zwar um den Aufruf mit folgender Befehlszeile:
Hintergrund
Wir nutzen das Tool in der Batch-Verarbeitung unseres Gemeindebriefes. Im Prinzip funktioniert es wunderbar, doch leider meldet sich immer die Benutzerkontensteuerung und fragt nach, ob das Programm "Veränderungen an der Festplatte dieses Computers" vornehmen darf. Bisher lief das Programm immer unter einem administrativen Benutzer, so dass man einfach bestätigen konnte. Nun aber soll das Tool unter einem Benutzer ohne Adminrechte laufen, und da hakt es dann.
Ich möchte den Benutzer nun nicht gleich zum Admin machen, sondern ihm gezielt die Rechte geben, die er braucht. Dazu müsste ich aber wissen, was in dem Tool die Benutzerkontensteuerung auf den Plan ruft. Zuerst hatte ich einen Schreibzugriff im Programmverzeichnis befürchtet, aber die Benutzerkontensteuerung meldet sich auch, wenn ich die EXE-Datei ins Temp-Verzeichnis kopiere und von dort aus starte (siehe Befehlszeile oben).
Der Programmierer des Tools kann oder will mir nicht weiterhelfen, er meint, er wüsste auch nicht, was in dem Programm die Benutzerkontensteuerung auf den Plan ruft. Kann ich mir zwar nicht vorstellen, wenn er das Ding programmiert hat ... aber naja
Danke im Voraus,
Sarek \\//_
kann man irgendwie herausfinden, warum ein bestimmtes Programm die Benutzerkontensteuerung auf den Plan ruft?
Konkret geht es um das Programm PDFMetaEdit, und zwar um den Aufruf mit folgender Befehlszeile:
C:\Users\Sekretariat\AppData\Local\Temp\Gemeindebrief\PDFMetaEdit.exe "C:\Users\Sekretariat\AppData\Local\Temp\Gemeindebrief\Gemeindebrief.pdf" -d 2 -T "Gemeindebrief 2/2017" -A "Ev.-luth. Kirchengemeinde Musterstadt" -PL 1 -PM 3 -DDT 1 -q Hintergrund
Wir nutzen das Tool in der Batch-Verarbeitung unseres Gemeindebriefes. Im Prinzip funktioniert es wunderbar, doch leider meldet sich immer die Benutzerkontensteuerung und fragt nach, ob das Programm "Veränderungen an der Festplatte dieses Computers" vornehmen darf. Bisher lief das Programm immer unter einem administrativen Benutzer, so dass man einfach bestätigen konnte. Nun aber soll das Tool unter einem Benutzer ohne Adminrechte laufen, und da hakt es dann.
Ich möchte den Benutzer nun nicht gleich zum Admin machen, sondern ihm gezielt die Rechte geben, die er braucht. Dazu müsste ich aber wissen, was in dem Tool die Benutzerkontensteuerung auf den Plan ruft. Zuerst hatte ich einen Schreibzugriff im Programmverzeichnis befürchtet, aber die Benutzerkontensteuerung meldet sich auch, wenn ich die EXE-Datei ins Temp-Verzeichnis kopiere und von dort aus starte (siehe Befehlszeile oben).
Der Programmierer des Tools kann oder will mir nicht weiterhelfen, er meint, er wüsste auch nicht, was in dem Programm die Benutzerkontensteuerung auf den Plan ruft. Kann ich mir zwar nicht vorstellen, wenn er das Ding programmiert hat ... aber naja
Danke im Voraus,
Sarek \\//_
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 335398
Url: https://administrator.de/forum/heruasfinden-warum-ein-programm-die-benutzerkontensteuerung-auf-den-plan-ruft-335398.html
Ausgedruckt am: 31.03.2025 um 15:03 Uhr
23 Kommentare
Neuester Kommentar
Schau ins Manifest der Datei. Dort steht im <requestedPrivileges> Knoten das angeforderte Execution Level drin.
Das Manifest kannst du dir z.B. mit ResourceHacker oder PEExplorer ansehen.
Sowas sieht dann bspw. so aus:
Gruß
Das Manifest kannst du dir z.B. mit ResourceHacker oder PEExplorer ansehen.
Sowas sieht dann bspw. so aus:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Copyright (c) Microsoft Corporation -->
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
<assemblyIdentity
processorArchitecture="x86"
version="5.1.0.0"
name="Microsoft.Windows.MMC"
type="win32"
/>
<description>Microsoft Management Console</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="highestAvailable"
uiAccess="false"
/>
</requestedPrivileges>
</security>
</trustInfo>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>Gruß
Moin,
probier mal, ob das Programm auch in einem anderen Pfad "meckert".
Also weg von Appdata.
Gruss
probier mal, ob das Programm auch in einem anderen Pfad "meckert".
Also weg von Appdata.
Gruss
Hallo,
https://superuser.com/questions/595496/what-triggers-a-uac-warning
http://www.mcseboard.de/topic/159518-uac-was-l%C3%B6st-den-dialog-aus/
https://books.google.de/books?id=6O1yDAAAQBAJ&pg=PT406&lpg=PT406 ...
http://www.winhelponline.com/blog/run-programs-elevated-without-getting ...
http://meridian.ws/wordpress/?p=306
https://technet.microsoft.com/en-us/library/dd919180%28v=ws.10%29.aspx
http://www.techrepublic.com/blog/windows-and-office/run-uac-restricted- ...
Nur weil jemand etwas in ein Quellcode presst und Kompiliert - bedeutet dies nicht das er auch über einer UAC jemals was gehört hat. Du machst ja auch in Netzwerke und PCs und hast wenig Wissen in den Bereichen.
Gruß,
Peter
Zitat von @SarekHL:
kann man irgendwie herausfinden, warum ein bestimmtes Programm die Benutzerkontensteuerung auf den Plan ruft?
http://stackoverflow.com/questions/20096706/how-does-windows-decide-whe ...kann man irgendwie herausfinden, warum ein bestimmtes Programm die Benutzerkontensteuerung auf den Plan ruft?
https://superuser.com/questions/595496/what-triggers-a-uac-warning
http://www.mcseboard.de/topic/159518-uac-was-l%C3%B6st-den-dialog-aus/
https://books.google.de/books?id=6O1yDAAAQBAJ&pg=PT406&lpg=PT406 ...
http://www.winhelponline.com/blog/run-programs-elevated-without-getting ...
http://meridian.ws/wordpress/?p=306
https://technet.microsoft.com/en-us/library/dd919180%28v=ws.10%29.aspx
http://www.techrepublic.com/blog/windows-and-office/run-uac-restricted- ...
Zuerst hatte ich einen Schreibzugriff im Programmverzeichnis befürchtet, aber die Benutzerkontensteuerung meldet sich auch, wenn ich die EXE-Datei ins Temp-Verzeichnis kopiere und von dort aus starte (siehe Befehlszeile oben).
Das hat nichts damit zu tun wo dein Ausführbares Programm abgelegt wurde, sondern wo es Schreiben will. Tabu (Generell) sind Root deiner Festplatte, Programm (32 und 64Bit), HKLM (Registrierung).Kann ich mir zwar nicht vorstellen
Schau dir seine Webseite an, dann soltest du dir das schon Vortsellen können. Letzte Neuigkeit dort 2008, also als Vista mal da war (und die erste UAC).Nur weil jemand etwas in ein Quellcode presst und Kompiliert - bedeutet dies nicht das er auch über einer UAC jemals was gehört hat. Du machst ja auch in Netzwerke und PCs und hast wenig Wissen in den Bereichen.
Gruß,
Peter
Zitat von @Pjordorf:
Das hat nichts damit zu tun wo dein Ausführbares Programm abgelegt wurde, sondern wo es Schreiben will.
Das hat nichts damit zu tun wo dein Ausführbares Programm abgelegt wurde, sondern wo es Schreiben will.
Das ist mir schon klar - aber alte Programme wollten eben oft dort schreiben, wo auch das Programm liegt (App.Path)
Tabu (Generell) sind Root deiner Festplatte, Programm (32 und 64Bit), HKLM (Registrierung).
Auch das ist mir klar, mir fehlt nur das Tool, um herauszufinden, wo das Programm schreiben will.
Schau dir seine Webseite an, dann soltest du dir das schon Vortsellen können. Letzte Neuigkeit dort 2008, also als Vista mal da war (und die erste UAC). Nur weil jemand etwas in ein Quellcode presst und Kompiliert - bedeutet dies nicht das er auch über einer UAC jemals was gehört hat.
Naja, der Mann arbeitet (laut seinem LinkEd-Profil) am Apache mit - ich denke schon, dass der nicht nur "etwas in einen Quellcode presst".
Du machst ja auch in Netzwerke und PCs und hast wenig Wissen in den Bereichen.
Das ist relativ. Im Vergleich zu denen, für die ich das mache, habe ich sehr umfangreiches Wissen
Klar, im Vergleich zu vielen hier habe ich kräftige Lücken, die vor allem daran liegen, dass ich die englischsprachigen Anleitungen nicht verstehe. Damit muss ich leben, ich bin halt nicht sprachbegabt. Aber für 97% meines Tagesgeschäfts reicht mein Wissen völlig aus.
Moin,
im Zweifel wechsel doch auf ein anderes Programm, eventuell auch einfach das PDF normal öffnen und erneut als PDF drucken mit den entsprechenden Anpassungen, geht bisweilen sogar mit Word 2013
Gruss
im Zweifel wechsel doch auf ein anderes Programm, eventuell auch einfach das PDF normal öffnen und erneut als PDF drucken mit den entsprechenden Anpassungen, geht bisweilen sogar mit Word 2013
Gruss
Zitat von @132895:
Schau ins Manifest der Datei. Dort steht im <requestedPrivileges> Knoten das angeforderte Execution Level drin.
Das Manifest kannst du dir z.B. mit ResourceHacker oder PEExplorer ansehen.
Schau ins Manifest der Datei. Dort steht im <requestedPrivileges> Knoten das angeforderte Execution Level drin.
Das Manifest kannst du dir z.B. mit ResourceHacker oder PEExplorer ansehen.
Und was, wenn dieser Knoten gar nicht existiert? Das Manifest sieht so aus:
<?xml version="1.0" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<description>BeCyPDFMetaEdit</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="*" />
</dependentAssembly>
</dependency>
</assembly>Auch das ist mir klar, mir fehlt nur das Tool, um herauszufinden, wo das Programm schreiben will.
Process Monitor damit siehst du das direkt.
Hallo Sarek,
hab gerade nur einen simplem Texteditor zur Hand. Aufgrund der API Funktionen kann es aber sein, dass versucht wird an "verbotenen Stellen" in die Registry zu schreiben. Falls das das Problem ist (und es nicht kriegsentscheidend ist) probier mal vor den Aufruf folgende Zeile zu schieben.
Ohne Gewähr. Kann helfen, muss aber nicht ...
Grüße
rubberman
hab gerade nur einen simplem Texteditor zur Hand. Aufgrund der API Funktionen kann es aber sein, dass versucht wird an "verbotenen Stellen" in die Registry zu schreiben. Falls das das Problem ist (und es nicht kriegsentscheidend ist) probier mal vor den Aufruf folgende Zeile zu schieben.
set "__COMPAT_LAYER=RunAsInvoker" Grüße
rubberman
Verwendest du die Software mit Installationroutine oder nur die rein Programmdatei (portabel)? Denn die portable Version triggert hier testweise unter W10 x64 1703 nirgendwo die UAC, egal ob ich über die GUI hantieren oder per Kommandozeile agiere.
- Wie ist die UAC eingestellt?
- Wo ist das Programm gespeichert?
- Wo liegen die Dateien die du bearbeitest?
- Welches OS?
So, das einzige, was keinen SUCCESS-Status hat, bevor die UAC aufgerufen wird, ist ein versuchter Create-Zugriff auf den Prefetch-Ordner:
15:14:50,7104816,"PDFMetaEdit.exe","10184","CreateFile","C:\Windows\Prefetch\PDFMETAEDIT.EXE-83BE8D3E.pf","NAME NOT FOUND","Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode: None, AllocationSize: n/a"
Kann es das sein?
Verwendest du die Software mit Installationroutine oder nur die rein Programmdatei (portabel)?
Ich habe nur eine Exe-Datei, also wohl die portable Version
* Wie ist die UAC eingestellt?
Auf Standard (Benachrichtigen, wenn Änderungen am Computer von Programmen vorgenommen werden)
* Wo ist das Programm gespeichert?
In diesem Fall auf %temp%, aber auch wenn es unter %ProgramFiles% liegt, geht es nicht.
* Wo liegen die Dateien die du bearbeitest?
in %temp%
* Welches OS?
Windows 7 x64 (SP1)Professional
Zitat von @SarekHL:
15:14:50,7104816,"PDFMetaEdit.exe","10184","CreateFile","C:\Windows\Prefetch\PDFMETAEDIT.EXE-83BE8D3E.pf","NAME NOT FOUND","Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode: None, AllocationSize: n/a"
Kann es das sein?
Eher nicht, das ist ein Zugriff eines anderen Systemprozesses der die Prefetch Infos in den Windows-Prefetch Ordner schreibt, filtere die Ausgabe auf den Prozess deiner EXE dann hast du eine bessere Übersicht.15:14:50,7104816,"PDFMetaEdit.exe","10184","CreateFile","C:\Windows\Prefetch\PDFMETAEDIT.EXE-83BE8D3E.pf","NAME NOT FOUND","Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode: None, AllocationSize: n/a"
Kann es das sein?
* Wo ist das Programm gespeichert?
In diesem Fall auf %temp%, aber auch wenn es unter %ProgramFiles% liegt, geht es nicht.
Zitat von @132895:
Zitat von @SarekHL:
15:14:50,7104816,"PDFMetaEdit.exe","10184","CreateFile","C:\Windows\Prefetch\PDFMETAEDIT.EXE-83BE8D3E.pf","NAME NOT FOUND","Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode: None, AllocationSize: n/a"
Kann es das sein?
Eher nicht, das ist ein Zugriff eines anderen Systemprozesses der die Prefetch Infos in den Windows-Prefetch Ordner schreibt, filtere die Ausgabe auf den Prozess deiner EXE dann hast du eine bessere Übersicht.15:14:50,7104816,"PDFMetaEdit.exe","10184","CreateFile","C:\Windows\Prefetch\PDFMETAEDIT.EXE-83BE8D3E.pf","NAME NOT FOUND","Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode: None, AllocationSize: n/a"
Kann es das sein?
Habe ich doch. Da steht als ausführender Prozess doch auch PDFMetaEdit.exe (jetzt oben fett hervorgehoben)
OK, sorry übersehen, das wäre in der Tat ungewöhnlich das das Teil dort etwas lesen möchte, der Ordner ist normalerweisen ja auch nur Administratoren zugänglich.
Schick das mal dem Entwickler.
p.s. schalte mal testweise Superfetch in den Diensten ab wenn es nicht schon von einer SSD dazu gezwungen wurde.
Schick das mal dem Entwickler.
p.s. schalte mal testweise Superfetch in den Diensten ab wenn es nicht schon von einer SSD dazu gezwungen wurde.
Zitat von @132895:
OK, sorry übersehen, das wäre in der Tat ungewöhnlich das das Teil dort etwas lesen möchte, der Ordner ist normalerweisen ja auch nur Administratoren zugänglich.
OK, sorry übersehen, das wäre in der Tat ungewöhnlich das das Teil dort etwas lesen möchte, der Ordner ist normalerweisen ja auch nur Administratoren zugänglich.
Mittlerweile - ich habe auch mal nach Eingabe eines Admin-Kennwortes in der UAC weiterprotokolliert - kristallisiert sich heraus, dass das Programm ziemlich oft in Unterordnern des Windows-Ordners schreiben will. Es gibt diverse CreateFile-Ereignisse für DLL-Dateien, nicht nur für C:\Windows\Prefetch\PDFMETAEDIT.EXE-83BE8D3E.pf, sondern z.B. auch für C:\Windows\System32\wow64.dll.
Aber genau das verstehe ich gerade nicht. Letzeres ist doch z.B. eine Systemdatei. Wieso will ein Anwendungsprogramm eine DLL erstellen. Oder missinterpretiere ich gerade den Begriff "CreateFile"?
Schick das mal dem Entwickler.
Ich habe den Eindruck, dass der kein Interesse mehr an seinem Produkt hat. Pjordorf hat ja schon darauf hingewiesen, dass die letzte News auf seiner Seite von 2008 ist ...
Ich würde Dir das Logfile gerne mal zeigen ... aber hier kann ich leider nur Bilder hochladen.
Oder missinterpretiere ich gerade den Begriff "CreateFile"?
Ja, das steht hier eher für CreateFileHandle. Ob der Prozess schreiben will/anfordert steht hinten in den Details (Flags).Ich würde Dir das Logfile gerne mal zeigen ... aber hier kann ich leider nur Bilder hochladen.
Exportiere den Log in eine Datei und lade es bei einem Filehoster hoch.Zitat von @132895:
Exportiere den Log in eine Datei und lade es bei einem Filehoster hoch.
Exportiere den Log in eine Datei und lade es bei einem Filehoster hoch.
https://we.tl/00cobTzRhO
Wäre einfacher wenn du es im nativen Procmon Format exportieren würdest, dann muss ich hier nicht in 5 MB XML wühlen, Danke
Wäre einfacher wenn du es im nativen Procmon Format exportieren würdest,
Dann muss es bis morgen warten, denn da ich darin nicht editieren kann, kann ich es auch nicht anonymisieren und muss es entweder Dir persönlich schicken oder mit neue erstellten Testbenutzern neu erstellen
dann muss ich hier nicht in 5 MB XML wühlen,
Welches Stichwort steht denn da für einen "echten" Schreibversuch? Dann kann ich ja selber suchen ... Steuerung+F ist da sehr hilfreich ;)
Welches Stichwort steht denn da für einen "echten" Schreibversuch?
In den Flags muss Write Zugriff angefordert werden, aber es reicht ja auch schon wenn das Programm versucht nur in einem Ordner zu lesen in dem es nicht darf.Zitat von @132895:
In den Flags muss Write Zugriff angefordert werden, aber es reicht ja auch schon wenn das Programm versucht nur in einem Ordner zu lesen in dem es nicht darf.
In den Flags muss Write Zugriff angefordert werden, aber es reicht ja auch schon wenn das Programm versucht nur in einem Ordner zu lesen in dem es nicht darf.
Das mit den Flags war ein guter Hinweis. Ich habe mir das Log mal genauer angeschaut und festgestellt, dass das Programm dreimal aufgerufen wird. Bei den ersten beiden Aufrufen wird es kurz danach wieder geschlossen. Der dritte Aufruf, bei dem sofort die UAC-Abfrage folgt, unterscheidet sich durch enen zusätzlichen Eintrag in den Flags: __COMPAT_LAYER=VistaSetUp. Also habe ich mal den Tipp von Rubberman, der mir vorhin untergegangen ist, ausprobiert, und die Batch-Datei um ein set "__COMPAT_LAYER=RunAsInvoker" ergänzt. Und siehe da: Es läuft!
Schön und wenn du willst packst du dann einfach die Einstellung direkt ins Manifest der EXE dann braucht es die Umgebungsvariable nicht mehr extra. (mit Resource-Hacker kannst du die ebenfalls anpassen).
<?xml version="1.0" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<description>BeCyPDFMetaEdit</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="*" />
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>Zitat von @132895:
Schön und wenn du willst packst du dann einfach die Einstellung direkt ins Manifest der EXE dann braucht es die Umgebungsvariable nicht mehr extra.
Schön und wenn du willst packst du dann einfach die Einstellung direkt ins Manifest der EXE dann braucht es die Umgebungsvariable nicht mehr extra.
Danke! Ich habe diese Info jetzt an den Entwickler von PDFMetaEdit weitergegeben. Jetzt wird sich zeigen, ob er sich noch für sein Programm verantwortlich fühlt und ein Update erstellt, oder ob es ihn nicht mehr interessiert. Da er neun Jahre lang nichts an der Software getan hat, befürchte ich letzteres ...
Ich für meinen Teil habe jetzt eine Lösung - also noch mal Danke an elchapo und rubberman.
Ich für meinen Teil habe jetzt eine Lösung
Die Frage, warum das Tool erhöhte Rechte anfordert, ist damit aber nicht beantwortet. Teste nochmal ausgiebig, ob alles wie gewünscht funktioniert. Insbesondere auf einem Rechner, auf dem das Tool nie gelaufen ist. Es ist vorstellbar, dass du zumindest einmalig mit administrativen Rechten starten musst, weil das Tool irgendwo Daten ablegt, auf die im nachhinein nur noch lesend zugegriffen werden muss.Grüße
rubberman
