Zwar sicher nicht die professionellste Art zwischen Prozessen zu kommunizieren, aber wie alpines vorgschlagen hat lassen sich auch beliebige (unsichtare) GUI controls zur Kommunikation missbrauchen. Habe ich selbst mal in einem Script mit mehreren ausgelagerten Prozessen verwendet. Vorteil war, dass es beachtliche Performance Vorteile brachte und man keine künstlichen Pausen einbauen musste um den beteiligten Prozessen genug Zeit zu geben die Datei fertig zu beschreiben. Das Abfragen der GUI verursacht auch keine vergleichbare Systemlast wie es Dateizugriffe in schneller Folge tun.
Beiträge von misterspeed
-
-
Vermutlich schreiben und lesen deine Scripte unverhältnismässig oft. Poste am besten dein Script, damit man dir den Fehler bzw. elegantere Lösungen zeigen kann. Es ist auch nicht unbedingt notwendig ständig die Dateien neu zu erzeugen bzw. zu löschen. Wenn man schon auf diese eher unperformante Art Daten austauscht kann man das auch anderst lösen.
Die explorer.exe läuft vermutlich Amok, weil die Dateien viel zu schnell verschwinden und neu erstellt werden. der Explorer analysiert Dateien im Verzeichnis um z.B. das korrekte Verknüpfungsicon oder die integrierte Vorschau anzuzeigen, je nach Dateiformat und installierter Software. Auch für die Windows Suche müssen die Dateien indiziert werden.
-
Somit müssen zum einen der Temporäre Pfad und der Zielpfad aus dem Echtzeitschutz und dem Ransomware- Schutz genommen werden, um brauchbare Resultate zu erzielen.
Den Tempordner als Ausnahme zu definieren halte ich für eine sehr gefährliche Lösung, denn gerade dort werden oftmals Schadprogramme automatisch entpacket, ausgeführt und versteckt.
Ich würde dir stattdessen empfehlen andere Compiler Settings zu testen. Als ich zuletzt Probleme mit Avira und Autoit hatte war das Problem z.B. nur bei 64bit Compilaten vorhanden. Außerdem verursacht der Laufzeitpacker UPX oft Fehlalarme und sollte daher besser nicht genutzt werden.
Ebenfalls testen könntest du den Wechsel auf eine neuere oder ggf. auch ältere Autoit Version. Evtl. mag Avira nur die Signaturen einer bestimmten Autoit Version nicht.
Was die "wiederhergestellte" und "nicht löschbare" Datei anbelangt:
- Wie sind die Dateisystemrechte denn nun gesetzt? Fehlen deinem Benutzeraccount evtl. nur die Besitzrechte?
- Bedenke bitte auch, dass der Explorer normalerweise als Benutzer und nicht als Administrator ausgeführt wird, selbst wenn dein Benutzer in der Administratorgruppe ist. Evtl reicht schon ein CMD Shell als Administrator um die Datei zu löschen.
CMD als Administrator User starten
- Prinzipiell kannst du auch eine CMD Shell mit SYSTEM Rechten öffnen. Darüber kann die Datei dann vermutlich auch gelöscht oder die Berechtigungen korrigiert werden.
- Ein sauberer vollständiger Windows Neustart löst auch so manches Problem, W10 nutz normalerweise nur einen Standby Fast Boot, was zu diversen Problemen führen kann
-
Je nach Fall kann man es sich auch sparen mehrere verschiedene aber sehr gleichartige Fenster zu erstellen.
Hab dein Script zwar nur überflogen, aber mein Eindruck war, dass deine Optionen Fenster sich kaum unterscheiden. Da wäre es auch eine möglichkeit nur mit unterschiedlichen Control-Gruppen zu arbeiten, welche je nach gewünschter "Otionsseite" ein- oder ausgebelendet werden.
-
Einfach keine Adminrechte für Programmteile anfordern, die ganz sicher keine benötigen. Deine GUI kann getrost auch mit Userrechten laufen.
Als Administrator zu arbeiten ist ein Privileg und sollte seit Einführung der Benutzerkontensteuerung kein Standard mehr in Programmen sein.
Die Trennung von GUI und Arbeitsprozessen hat in der Regel auch Performance Vorteile, da du von Multitprocessing profitierst und heutige CPU's auf Paralellisierung ausgelegt sind.
Würde dir also eher einen Programmaufbau mit multiplen Prozessen nahelegen:
-
Naja wie schon gesagt wurde ist W10 "sicherer" und lässt nicht mehr zu, dass bestimmte WindowMessages (hier Drag&Drop) von nieder Privilegierten Benutzerkontexten an höher Privilegierten gesendet werden.
Das konnte man nämlich ausnutzen um ohne Adminrechte Code im Administratorkontext auszuführen, sofern ein entsprechendes Fenster existent war.
Dein Desktop und Explorer Fenster läuft normalerweise im Kontext deines Benutzeraccount mit normalen Privilegien, daher funktioniert Drag&Drop auch nicht mit GUI's im Adminkontext.
Anstatt das Verhalten zu umgehen oder gar eine Explorer Instanz mit erhöhten Privilegien zu starten sollte man eher modular und sorgsam mit hohen Privilegien umgehen. Erreichen kann man das z.B. durch Trennung der Prozesse für GUI und "Worker". In der Regel benötigt nämlich nur der Worker höhere Privilegien.
Durch getrennte Prozesse von GUI und dem eigentlichen Code kann man übrigens auch andere Probleme wie eine nicht mehr reagierende Oberfläche vermeiden.
-
Ja also bei der Beschreibung ist definitiv die Windows Aufgabenplanung die erste Wahl. Als Trigger kann dort auch die Benutzeranmeldung gewählt werden, dann wird dein Script wie gewünscht ausgeführt und du benötigst nicht mal Einträge im Autostart des Users.
Davon mal abgesehen... ich kenne deine Backuplösung nicht, aber alle Backuplösungen die ich so kenne arbeiten ihre angelegten Backupjobs voll automatisch nach definiertem Zeitplan ab. Die Backup Software installiert dafür einen Dienst der immer aktiv ist und ausreichend Rechte besitzt. Kann mir kaum vorstellen, dass das bei deiner Software nicht der Fall ist.
-
Ahja eine Lösung wäre auch noch die Nutzung von runas und die Angabe eines Benutzeraccounts mit deaktivierten UAC Prompts (kann man per Registry oder Gruppenrichtlinie deaktivieren).
Der Superadministrator Account "Administrator", welcher standardmässig deaktiviert ist hat diese UAC Einstellung normalerweise.
Die Angabe von solchen Zugangsdaten in deinem Script ist aber nicht wirklich "sicher" und nicht zu empfehlen.
-
Vielleicht nochmal genauer beschreiben was du erreichen willst bzw. wie dein Wunschablauf ist.
Grundsätzlich hilft dir runas denke ich soweiso nicht, denn mit runas wird lediglich der Benutzer definiert unter dessen Account das Script ausgeführt wird, das hat erstmal nichts mit erhöhten (Admin-)Rechten zu tun.
Standardmässig arbeite seit Windows Vista nämlich jeder Benutzeraccount mit normalen Benutzer Privilegien. Werden Adminprivilegien benötigt erscheint der UAC Dialog, welcher dir erlaubt mit erhöhten Rechten weiterzuarbeiten.
Ob der UAC Dialog eine Angabe von Username und Passwort, einfach nur einen Klick auf JA erfordert oder garnicht erscheint hängt von mehreren Gegebenheiten bzw. den Einstellungen von UAC ab.
Also kurz nochmal:
Selbst wenn du bei runas Administratordaten angibst startet der Prozess nur im Benutzermodus, siehe auch deine Beobachtungen.
---------
Das ganze funktioniert über die Windowsaufgabenplannung, wenn dort der Haken "Mit höchsten Privilegien ausführen" gesetzt wird und sich der dort hinterlegte Account in der Administratorgruppe befindet. In diesem Fall wird UAC tatsächlich automatisiert.
Um Aufgaben in der Aufgabenplannung anzulegen werden allerdings ebenfalls Administratorprivilegien benötigt. Du müsstest also zumindestens für die Installation deiner "Hintertür" einmalig diese Privilegien durch Benutzerinteraktion mit UAC erhalten.
--------
Sofern es für dich kein Problem ist bei jedem Script Start einmalig UAC zu bestätigen kannst du dir auch die Vererbung der Berechtigungen zu Nutze machen.
Jeder Prozess, der mit erhöhten Privilegien arbeitet gibt diese auch an Prozesse weiter, welche er aufruft. Du kannst also dein Script nutzen um die Berechtigungen anzufordern und danach über das Script z.B. 10 andere Programm mit erhöhten Privilegien starten ohne weitere Angabe von Benutzerdaten oder Bestätigung von UAC Dialogen.
Diese Lösung erfordert zwar Benutzerinteraktion, dafür werden aber keine Zugangsdaten irgendwo gespeichert.
-
Grundsätzlich würde ich auch eher die Backupdateien prüfen. Das sollte dein Script aber ohnehin tun, denn wenn eine Backupdatei warum auch immer nicht erstellt werden kann solltest du davon zeitnah Kenntnis erhalten, damit das Problem behoben werden kann und nicht monatelang unentdeckt bleibt. Eine Warn-/Fehlermeldung sollte den Anwender hier informieren.
Aber natürlich hast du recht, dass die mehrmalige Scriptausführung im Fehlerfall dann evtl. nicht mehr sauber unterbunden wird. Daher ist eine zusätzliche Logdatei sinnvoll. Hier würde ich dann nicht nur die Ausführung ansich protokollieren, sondern auch den Erfolg/Misserfolg, rein informativ die Dauer und alle "gewollten" Abbrüche der Ausführung. Ob Abbruch oder nicht kannst du einfach durch das Änderungsdatum der Logdatei entscheiden.
Rechtetechnisch solltest du beim Schreiben von (Log-)Dateien vielleicht noch beachten, dass Windows Standardverzeichnisse in der Regel von der Benutzerkontensteuerung und evtl. Antivirensoftware geschützt werden. Deine Log Datei sollte also nicht unbedingt unter "C:\programme\.." liegen. Ich empfehle die Logdatei im Zielverzeichnis der Backups abzulegen, da du hier ohnehin Schreibrechte sicherstellen musst.
Du solltest die Rückgabewerte der Log Schreibfunktion prüfen und so schon vor Beginn des Backups bei Schreibproblemen der Logdatei eine Warnung und einen Programmabbruch auslösen.
-
-
Nachtrag: Ich habe es jetzt "temporär" via Windows Aufgabenplanung gelöst, d.h. sobald ich mich anmelde, wird die 1. EXE gestartet. Dienst wäre etwas schicker.
Nein wäre es nicht. Da der Dienst vermutlich in einem anderen Benutzerkontext laufen würde (local system?) kann dein Script sehr wahrscheinlich auch keine Fenster auf dem Desktop eines anderen angemeldeten Benutzers finden. Das Script im Kontext des entsprechenden Users auszuführen ist also in diesem Fall die beste / einzigste Lösung. Deine Konstruktion mit zwei Scripten ist eigentlich dann auch überflüssig, anstatt ein weiteres Script aufzurufen könnte dein Script die Fenster auch selbst verschieben und dann auch problemlos in Intervallen die Position prüfen bzw. wiederherstellen falls nötig.
-
Bildanalyse mag ja vielleicht eine Möglichkeit sein um das Problem zu lösen, aber ist das wirklich die beste und einzigste Möglichkeit? Woher stammen die Bilder? Vermutlich von einer Webseite. Es sollte also grundsätzlich die Möglichkeit geben den Sitzplatzstatus direkt live abzufragen. Jenachdem ob du dort beschäftigt bist oder quasi extern auf die Daten zugreifst hast du vielleicht sogar die Möglichkeit direkt oder indirekt via API auf die zugrundeliegende DB zuzugreifen.
-
Jupp seh ich auch so. Mit WinGetPos() kannst du die Position und Größe der Fenster ermitteln wenn du sie von Hand positionierst. Die ermittelten Infos kannst du dann nutzen um die Fenster zukünftig immer gleich mit winmove() zu positionieren.
Die einzige Schwierigkeit hierbei ist, dass die Fenster nicht sofort existieren wenn der Prozess von dir gestartet wurde. Je nach Anwendung kann der Startvorgang mehrere Sekunden benötigen. Du solltest dir also auch noch die Funktionen winexists() oder winwait() ansehen. Aber selbst dann kann es bei bestimmten Anwendungen vorkommen, dass das Fenster zwar früh erzeugt wird und existiert, aber zunächst unsichtbar ist und später im Startvorgang durch die Anwendung nochmals neu positioniert und sichtbar gemacht wird, dies kann auch mit dem Titel des Fensters passieren, welcher evtl. erst später gesetzt oder geändert wird.
Um solche Timing Probleme zu vermeiden bzw. zu korrigieren solltest du die neue Zielposition nochmals am Ende des Scriptes nach kurzer Wartezeit für alle Fenster mit WinGetPos() überprüfen und ggf. eine erneute Positionierung durchführen wenn dies zuvor nicht erfolgreich war.
-
Das (/T) wird mit seiner Synology NAS nicht funktionieren, weil er dort mit Sicherheit kein NTFS hat.
Also zumindestens unser QNAP NAS verwendet/unterstützt NTFS. Der Hinweis ist aber natürlich berechtigt.
Das scheint mir auch die sauberste Lösung zu sein !
Ob das die sauberste Lösung ist sei mal dahingestellt. Ich würde mir anschauen ob das ganze Vorgehen Sinn macht. Warum 100 Clients zeitgleich auf das NAS zugreifen und die älteste Datei ermitteln müssen ist mir nachwievor unklar.
Wie kommen die Dateien denn dahin?
Was steht da drin?
Was machen die Clients mit der Information?
Was soll eigentlich am Ende erreicht werden?
Das sind die Fragen die man sich stellen sollte um eine saubere Lösung zu finden.
-
Teste mal ob es nicht wesentlich schneller geht auf Autoit Funktionen zu verzichten und stattdessen Windows Boardmittel zu nutzen. Soweit ich dich verstehe willst du lediglich den Dateinamen der ältesten TXT-Datei im Verzeichnis (modify date). Folgender DOS Befehl liefert dir in der ersten Zeile die gewünschte (älteste) Datei.
Du sparst dir damit eigentlich alles. Du musst nur noch via Autoit den stdout Stream mitlesen und mit den Stringfunktionen die erste Zeile parsen. Theoretisch kannst du nach der ersten Zeile sogar das stdout lesen abbrechen und die Schleife verlassen.
Ob der DOS Befehl "dir" jedoch auf deinem Netzlaufwerk nicht die selben Performanceprobleme hat müsstest du testen. Falls das hier auch der Fall ist liegt das Problem eher am Netzwerk oder NAS.
-
Stimmt hab ich übersehen. Kann man trotzdem so machen. Man nutzt run um die PID des Launchers "hhexew,exe" zu ermitteln, wartet bis der Launcher seine Arbeit erledigt hat und prüft dann mit processlist nach existierenden Prozessen der "hhpxprojwinframe.exe" processlist gibt soweit ich mich erinnere auch die PID der Prozesse zurück. Die korrekte Instanz sollte eine PID größer des unmittelbar zuvor gestarteten Launchers haben. Eine korrekte Zuordnung ist also recht zuverlässig möglich, sofern nicht nahezu zeitgleich mehrere Nutzer am System angemeldet werden. Es sollte aber auch möglich sein eine direkte Zuordnung von Benutzeraccount und Prozess / PID abzufragen, der Taskmanager listet den ausführenden Benutzer ja auch auf.
EDIT:
Alpines hat ja schon das dazu nötige Script gepostet in Beitrag #6
-
Man kann das auch ganz simpel mit runwait lösen.
Bei der Useranmeldung wird dann folgendes gemacht:
- Alles verschwinden lassen, sprich kein nutzbarer desktop usw. keine Ahnung wie du das bislang realisierst
- Dein Autoitscript wird gestartet
- Das Autoitscript übernimmt den Start der Anwendung und zwar nicht mit run, sondern mit runwait, alternativ ginge natürlich auch run und eine Schleife mit processexists Prüfung auf die PID des gestarteten Prozesses, welche dir run ja zurückgibt und eindeutig ist
- Solange die Anwendung nicht geschlossen wird macht dein Autoitscript nichts ausser darauf zu warten, dass die gestartete Anwendung geschlossen wird
- Sollte sie geschlossen werden wartest du am besten erstmal x Sekunden, da es ja sein könnte, dass dies gewollt ist (z.b Userabmeldung oder Serverneustart), in diesam Fall wird dein Autoitscript dann früher oder später auch beendet und macht nix mehr, was ja gewollt ist
- Andernfalls startet dein Script die Anwendung einfach neu und fängt wieder an darauf zu warten, dass sie beendet wird, alternativ kannst du den User natürlich auch abmelden
-
Versteh das Problem ehrlich gesagt nicht so ganz.
Um eine Liste und Pfade aller Dateien des Desktops zu bekommen benötigt man lediglich die Funktion _FileListToArray. Hier kann man bei Bedarf auch nach Dateien / Ordnern und bestimmten Dateiendungen wie "*.txt" filtern, oder aber man wertet das Array eben selbst aus wenn auch Dateien mit anderen Endungen verschoben werden sollen.
Um die Pfade für den eigenen Desktop / AllUser Desktop oder auch Desktop eines spezifischen Users zu ermitteln sind folgende Makros hilfreich:
Der Userspezifische Desktop liegt normalerweise immer unter "C:\Users\BENUTZERNAME\Desktop".
Ahja und dir sollte natürlich klar sein, dass dein Script Administratorrechte benötigt, wenn es den Desktop bzw. den Benutzerordner eines anderen Nutzers verändern soll.
-
Je mehr Prozesse du startest desto mehr ist dein Betriebssystem damit beschäftigt die anfallenden Aufgaben (Tasks) der Prozesse sinnvoll auf die physikalischen CPU Kerne und sofern vorhanden virtuellen Kerne (HT) zu verteilen. Dies erledigt der Taskscheduler des Betriebssystem. Damit im Endeffekt die verfügbaren Ressourcen gleichmäßig genutzt werden. Sollte dieser der Meinung sein ein anderer Core ist weniger ausgelastet und besser geeignet werden alle Task Daten des L1/L2 Caches in den Cache des anderen Kerns transferiert und die Aufgabe dort fortgesetzt. Wenn da dann zufällig auch noch ein anderer Task läuft muss deiner warten bis dieser abgeschlossen ist oder ebenfalls auf einen anderen Kern verschoben wurde. Dieser Vorgang kostet Rechenzeit.
Dein Testscript generiert im Erfolgsfall außerdem noch ein externes Event und nutzt hierfür vermutlich einen Systemprozess (Beep). Auch der Zugriff auf die Festplatte findet unglaublich oft statt, da du keine Pause in der Schleife verwendest. Dein Code ist also nicht nur CPU limitiert, sondern auch davon abhängig schnellstmöglich Rückmeldungen vom Betriebssystem zu erhalten. Das könnte aber durch die Anzahl an Tasks zu beschäftigt sein, insbesondere Wenn Windows nur 1-2 Cores hierfür paralell nutzt. Deine System Tasks werden vom Taskscheduler dann eben eingereiht bis die Tasks abgeabeitet wurden. Der Mehrnutzen durch paralelle Anfragen geht dann weitestgehendst verloren.
Anderst schaut das wahrscheiunlich aus, wenn du massive Berechnungen in deinen eigenen Scripten durchführst und weitgehend unabhängig vom Betriebssystem vor dich hinrechnest.
Das Thema wurde vor ein paar Wochen hier übrigens schonmal sehr ausführlich beleuchtet. Vielleicht hat ja jemand Lust dir den Thread rauszusuchen.