ShellExecute: Fehler beim Öffnen einer PDF

    Gibt es eine andere Möglichkeit abzufragen ob der angemeldete Benutzer über Administratorrechte verfügt (und wenn ja Excel mit Adminrechten zu starten, und wenn nicht das Script zu stoppen) ohne dass das AutoIt-Script selber Adminrechte benötigt? Je sicherer das Script umso besser. Nur auf Administratorkonten soll das Tool zu öffnen sein.

    • Offizieller Beitrag
    Zitat von AspirinJunkie

    Edit: Geht ja noch viel einfacher:

    Upps! Das funktioniert ja wirklich!
    Wobei: Auf einem x64-System braucht man noch: #AutoIt3Wrapper_UseX64=y am Anfang, sonst stimmt der Pfad zu hosts nicht.
    Aber woher hast Du das "runas"?
    Das steht gar nicht in der Hilfe und unter MSDN findet man das auch nicht.

    Zitat von AspirinJunkie


    Edit: Geht ja noch viel einfacher:

    Gilt das auch für Excel und dem Aufruf der Exceldatei, inklusive Übergabe der Kennwörter? Oder ist das nur für die PDF-Datei gedacht?

    Die Quick&Dirty-Lösung interessiert mich auch, irgendwann muss ich ja mal anfangen zu lernen. ;)

    Zitat von Oscar

    Aber woher hast Du das "runas"?
    Das steht gar nicht in der Hilfe und unter MSDN findet man das auch nicht.

    Die Verben richten sich nach dem was in der Registry hinterlegt ist.
    Hier wird eine .exe aufgerufen. Unter HKCR\.exe finden wir den Verweis wo die Eintragungen zu finden sind was ShellExecute mit .exe-Dateien alles anfangen kann.
    In dem Fall also unter HKCR\exefile. Dort finden sich unter HKCR\exefile\Shell alle Verben die bei exe-Dateien verwendet werden können. Unter anderem auch das ominöse runas. Das Aufrufkommando unterscheidet sich hierbei nicht von "open" aber interessant ist der gesetzte Wert HasLUAShield. Wenn der gesetzt ist kommt für das Kommando vorher die UAC-Abfrage.

    Zum ersten mal bin ich vor einigen Jahren auf das HasLUAShield gestoßen als ich eine Lösung gesucht habe um Admin-Rechte in einer Batch-Datei zu erzwingen.

    Zitat von mumpel

    Gilt das auch für Excel und dem Aufruf der Exceldatei, inklusive Übergabe der Kennwörter?

    Wenn Excel die Übergabe des Passwortes als Kommandozeilenparameter zulassen würde ja. Soweit ich gelesen habe gibts den aber nicht.
    Du arbeitest ja daher eh anscheinend mit dem Excel-Objekt.
    Von daher hast du nun schon hinreichende Gründe dem Skript Adminrechte zu geben.

    Zitat von mumpel

    Die Quick&Dirty-Lösung interessiert mich auch, irgendwann muss ich ja mal anfangen zu lernen.

    War im Grunde die selbe Lösung - nur viel umständlicher (über ein externes VBS-File).

    • Offizieller Beitrag
    Zitat von AspirinJunkie

    Die Verben richten sich nach dem was in der Registry hinterlegt ist.
    Hier wird eine .exe aufgerufen. Unter HKCR\.exe finden wir den Verweis wo die Eintragungen zu finden sind was ShellExecute mit .exe-Dateien alles anfangen kann.
    In dem Fall also unter HKCR\exefile. Dort finden sich unter HKCR\exefile\Shell alle Verben die bei exe-Dateien verwendet werden können. Unter anderem auch das ominöse runas. Das Aufrufkommando unterscheidet sich hierbei nicht von "open" aber interessant ist der gesetzte Wert HasLUAShield. Wenn der gesetzt ist kommt für das Kommando vorher die UAC-Abfrage.

    Zum ersten mal bin ich vor einigen Jahren auf das HasLUAShield gestoßen als ich eine Lösung gesucht habe um Admin-Rechte in einer Batch-Datei zu erzwingen.

    Ok! Vielen Dank für die Erklärung!
    Diesen Trick werde ich mir auf jeden Fall archivieren. Das kann ich bestimmt mal gebrauchen. :thumbup:

    Bei den Office-Dateien hätte man mit "RunAs" ohenhin ein Problem. Denn für "RunAs" ist in der Registrierungsdatenbank standardmäßig kein Kommando hinterlegt. Den RunAs-Schlüssel muss ich immer manuell eintragen und mit dem zugehörigen Officeprogramm (den Pfad dorthin) versehen. Bei mehreren Dateitypen ganz schon viel Zeit erforderlich, und auf einem Rechner der mir nicht gehört kann ich das nicht einfach ungefragt per Script setzen. Man kann also nur das Officeprogramm per RunAs scriptgesteuert starten, eine Office-Datei dagegen nicht wenn auf dem Zielrechner kein RunAs-Kommando in der Registrierungsdatenbank gesetzt ist.

    Der Trick wäre ja nicht die xlsx-Datei per Shellexecute aufzurufen sondern direkt die excel.exe und die zu öffnende xlsx-Datei als Parameter mitzugeben. Es gilt also was in der Registry für .exe hinterlegt ist und nicht für .xlsx.

    • Neu

    Hallo,

    ich grabe mal diesen alten Beitrag hoch.

    Habe aktuell mit dem Acrobat Reader DC genau dieses Problem. Ich möchte eine PDF öffnen über meine Autoit Gui.
    Als au3 klappt das super, als EXE keine Chance.

    Meine Anwendung hat alle Tipps hier beherzigt. RequireAdmin, Shellexecute mit Workingdir. Geschütze Ansicht in den
    Sicherheitseinstellungen ist aus.

    Es will einfach nicht.

    Hat Jemand noch eine Idee woran das liegen kann?

    Grüße

    JB

    • Neu

    Erstmal willkommen im Forum.

    Dann: Am besten wäre ein Minimalskript.
    Also ein Skript, welches den Fehler reproduziert aber vorher schrittweise um die Teile entschlackt wurde die für die Fehlerreproduktion irrelevant sind.
    In deinem Fall könnte das sogar ein Einzeiler am Ende bedeutet: der Aufruf der pdf per z.B. Run oder ShellExecute().

    Vorteil für dich: Die deutlich höhere Wahrscheinlichkeit, dass dir auf dieser Basis jemand das Problem analysieren kann ist meistens nur der Nebeneffekt, da du beim Entschlackungsvorgang mit hoher Wahrscheinlichkeit selbst das Problem extrahieren konntest.

    • Neu

    +1 zum Statement von AspirinJunkie .

    Hi JB72ger 👋 ,

    auch wenn du bereits gut beschrieben hast, dass du die vorangegangenen Dinge des Threads berücksichtigt hast, zeigt uns der Code doch ggf. etwas mehr.

    Mal ganz wild gefragt 😅 :
    Kannst du die Umgebung (mit Acrobat Reader DC) irgendwie bereit stellen? Per Docker oder Cloud Instanz oder so? Dann könnten wir direkt dort testen.
    ==> Ja, dies ist mit Kanonen auf Spatzen schießen, in diesem Fall, da wirklich nur 'ne Kleinigkeit. Doch heutzutage haben "die Leute" manchmal versteckte Services von denen man gar nichts ahnt.

    💡 Wenn nicht, wovon ich ausgehe, dann bleibt es bei der Code-Anfrage - Danke.

    Viele Grüße
    Sven

    • Neu

    Hallo,

    danke :-).

    Ich bin schon weiter. Habe mal FoxIt Reader installiert und ohne was zu ändern öffnet sich der FoxIt Reader auch wenn ich es mit einer EXE aufrufe.
    Bekomme aber die Meldung: Das FoxIt Reader von einer Anwendung geöffnet ohne gültige Signatur.

    Man kann das dann wegklicken und die PDF ansehen. Ich denke mal das Adobe Reader da ähnlich reagiert nur das er dann im Taskmanager "verschwindet".

    Habe die EXE mal mit einem eigenen Zertifikat signiert, bringt aber keine Lösung. Das muss dann irgendwo aus den Sicherheitseinstellungen kommen, entweder
    Adobe Reader oder per GPO.

    Selbst wenn ich simpel:
    $acrobatReaderPath = '"C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe"'
    ShellExecute ($acrobatReaderPath)

    Verschiwndet der Reader im Taskmanager sobald ich die au3 zur exe mache.

    EDIT:

    Ich gehe nun folgenden Weg:

    ; Microsoft Edge öffnen und die PDF anzeigen
    ShellExecute("msedge.exe", '"' & $pdfPath & '"')

    Das klappt immer. Mir geht es nur darum die PDF anzeigen zu lassen, das macht der Edge auch. Das geht als au3 oder exe.

    SOLVE-SMART
    Ja das wäre wild, das dürfte ich nicht.

    Danke für die Hilfe dennoch. Es liegt zu 100% am Adobe Reader, Sicherheitseinstellungen. Ich denke wenn ich meine Autoit.exe signieren lasse (eigenes bringt nix)
    dann wird das laufen. Aber das ist mir zu aufwändig. Dann eben Edge, der zeigt die PDF an und man kann in der FAQ mal kurz was lesen.

    Gruß
    Jerry

    2 Mal editiert, zuletzt von JB72ger (20. September 2024 um 11:08)