cmd.exe /c durch Shell Aufruf klappt unter WIN 10 nicht mehr

[wschrabi]

Hallo
Ich habe einen Shell Call folgendermassen:

ShellExecute ( 0, nil, PChar('cmd.exe'), PChar('/C '+ myapp), nil, SW_HIDE)

unter WIN 7 klappt es super. DOch er will nicht mehr unter WIN 10 (geschützt mit KASPESKY Endpoint Sec 10)
Wenn ich es manuell in eine cmd shell eintippe klappt es aber.

Wer weiß Rat wie ich das wieder aus meinem Delphi Prg unter WIN 10 zum Laufen bringe?
DANKE:roll:

[sakura]

Zitat:

Zitat von wschrabi (Beitrag 1354816)

unter WIN 7 klappt es super. DOch er will nicht mehr unter WIN 10 (geschützt mit KASPESKY Endpoint Sec 10)

Checke mal mit Kaspersky. Bei mir klappt es ohne Probleme (habe es gerade mal mit "notepad.exe" getestet).

Windows 10, Build 1607.14393.447, alle Updates installiert.

...:cat:...

[wschrabi]

Danke, kannst mir bitte noch sagen wie ich KAS 10 unter win 10 kurzzeitig abschalte? Ich seh kein KAS 10 Icon neben der UHR aber er läuft.

[wschrabi]

Also mit NOtepad.exe geht es auch. Doch nicht mit sqlite3.exe !
In WIN 7 wo das gleiche ist klappt es aber. Kann das mit den Einstellungen in KAS bei den vertrauenswürdige Prg zu tun haben, sodaß notepad als Vertrauenswürdig gilt und sqlite3.exe nicht?:roll::?

[sakura]

Das ist möglich, kannst Du sqlite3.exe ohne Sicherheitsabfrage von der Kommandozeile starten?

Wie Du Kaspersky abschaltest, weiß ich nicht, da ich es nicht nutze, aber Google wird Dir da sicherlich weiter helfen ;)

...:cat:...

[Luckie]

Notepad liegt im Suchpfad. Tut das sqlite3.exe eventuell nicht?

[wschrabi]

ja sakura im manuellen shell kann ich das sqlite3 mit db und import skript laufen lassen.
ich hab den absulten pfad angegeben daher kein suchpfad nötig
:?

[wschrabi]

Also ich hab den KAS ausgeschaltet.
An einem PC mit WIN 10 (PC 1) klappt es ohne Probleme (ohne KAS)
An dem anderen WIN 10 (PC 2) nicht (ohne KAS bzw. abgeschaltet.)
PC1 neu aufgesetzt in einer VM
PC2 mit eventl. anderen Policies. Doch wo stellt man dies ein?
DANKE

[Dalai]

Was passiert stattdessen? Was passiert, wenn du die Konsole mal nicht vesteckst (SW_SHOW)? Welchen Rückgabewert bekommst du durch ShellExecute?

Grüße
Dalai

[wschrabi]

@Dalai die Console geht gar nicht auf. AUF WIN 7 und WIN 10 (PC ok) geht die Console auf (GLEICHES PRG ) und macht ein schwarzes Window ohne Err. Kann das an den Policies liegen, daß shells unterbunden werden. :?

[Dalai]

Welchen Rückgabewert bekommst du denn nun von ShellExecute?

Grüße
Dalai

[himitsu]

Zitat:

Zitat von Dalai (Beitrag 1354854)

Welchen Rückgabewert bekommst du denn nun von ShellExecute?

Wollte auch gerade diese vollkommen abwägige Frage stellen. Zum Glück grade noch so die Seite zwei entdeckt. :lol:
Es ist ja nicht so, dass diese WinAPI einem nicht sagen würde, was ihr fehlt.


Zusätzlich auch noch ShellExecuteEx oder CreateProcess und den ExitCode des Programms prüfen.
Es könnte auch sein, dass es zwar gestartet wird, es sich aber sofort wieder mit einem Fehler beendet.

Leerzeichen in myapp?

Zitat:

ja sakura im manuellen shell kann ich das sqlite3 mit db und import skript laufen lassen.
ich hab den absulten pfad angegeben daher kein suchpfad nötig

Genau so, wie du es hier startest?
Oder rufst du dort "nur" den Inhalt von myapp auf.
In der CMD kann man ja nocheine CMD starten und sieht dann deren Fehlermeldungen.

[Dalai]

Zitat:

Zitat von himitsu (Beitrag 1354858)

Wollte auch gerade diese vollkommen abwägige Frage stellen.

[Klugscheiß] abwegig [/Klugscheiß]

Zitat:

Zum Glück grade noch so die Seite zwei entdeckt. :lol:

Vielleicht musst du in deinem Benutzerkontrollzentrum doch mal einstellen, mehr als 10 Beiträge pro Seite zu sehen zu bekommen ;).


Mir fällt aber grade noch etwas anderes ein: CMD /C erwartet den kompletten Befehl in Anführungszeichen, erst recht, wenn man dem Programm (hier myapp) noch Parameter mitgibt.

Grüße
Dalai

[wschrabi]

Nein mein Prg klappt ja. Daran liegts nicht. Es liegt sicherlich an den Policies.
Hab das hier von der Powershell gefunden. http://stackoverflow.com/questions/2...on-of-powershe

Denn es klappt auf WIN 10 (mein PC) und WIN 7 (mein PC) aber am Work PC geht es sowohl WIN 7 als auch WIN 10 nicht.
Wenn ich nur wüßte wo man diese Policy zweck Shell-Execution einstellt.
daran liegst sicher...

[hoika]

Hallo,
liest du auch die Artikel hier?

Welchen Rückgabewert bekommst du denn nun von ShellExecute bzw. ShellExecuteEx?

[wschrabi]

hoika, das Shell Fenster geht ja gar nicht auf: Und ich ruf die app (= sqlite3.exe ) via folgendem Script auf, und das gibt true zurück.

Aufruf:

Delphi-Quellcode:

            WriteLogMemo(Format(' SHell: %s %s ',['c:\windows\system32\cmd.exe','/C '+ myapp +' '+uniconnection2.Database+' < '+gettempdirectory+'SQLIteIMportScript.txt']));
            exeRet:=StartandWait('c:\windows\system32\cmd.exe','/C '+ myapp+' '+uniconnection2.Database+' < '+gettempdirectory+'SQLIteIMportScript.txt');

Definition:

Delphi-Quellcode:

 
{******************************************************************************}
FUNCTION StartAndWait(CONST ExecuteFile, ParamString: STRING): boolean;
//http://delphi.about.com/library/weekly/aa040803a.htm
{******************************************************************************}
VAR
  SEInfo : TShellExecuteInfo;
  ExitCode : DWORD;
BEGIN
  Result := False;
  IF NOT FileExists(ExecuteFile) THEN Exit;
  FillChar(SEInfo, SizeOf(SEInfo), 0);
  SEInfo.cbSize := SizeOf(TShellExecuteInfo);
  WITH SEInfo DO
    BEGIN
      fMask := SEE_MASK_NOCLOSEPROCESS;
      Wnd := Application.Handle;
      lpFile := PChar(ExecuteFile);
      lpParameters := PChar(ParamString);
      nShow := SW_SHOWNORMAL;
    END;
  IF ShellExecuteEx(@SEInfo) THEN
    BEGIN
      REPEAT
        Application.ProcessMessages;
        // Damit die Prozessorauslastung sinkt :-)
        Sleep(100);
        GetExitCodeProcess(SEInfo.hProcess, ExitCode);
      UNTIL (ExitCode <> STILL_ACTIVE) OR Application.Terminated;
      Result := True;
    END;
END;

[wschrabi]

Ich glaub ich habs. Ich muss es mit der Powershell machen.
Doch da kommt ein rot-geschriebener Error im schwarzen Fenster, und das Fenster ist immer gleich weg, wie kann ich das Powershell fenster dauerhaft anzeigen lassen.
Habe das hier:

Delphi-Quellcode:

            myshell:='C:\Windows\syswow64\WindowsPowerShell\v1.0\powershell.exe';
            WriteLogMemo(Format(' SHell: %s %s ',[myshell,' c:\windows\system32\cmd.exe /C "'+ myapp+' '+uniconnection2.Database+' < '+gettempdirectory+'SQLIteIMportScript.txt" ']));
            //exeRet:=StartandWait('c:\windows\system32\cmd.exe','/C '+ myapp+' '+uniconnection2.Database+' < '+gettempdirectory+'SQLIteIMportScript.txt');
            //C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
            exeRet:=StartandWait(myshell,' c:\windows\system32\cmd.exe /C "'+ myapp+' '+uniconnection2.Database+' < '+gettempdirectory+'SQLIteIMportScript.txt" ');

[wschrabi]

Hab die Ursache:
In der Powershell kommt folgender Error:

Delphi-Quellcode:

In Zeile:1 Zeichen:160
+ ... l\Temp\aaa_1et <
C:\Users\O_SCHR~1\AppData\Local\Temp\SQLIteIMportScript.txt`
+                    ~
Der Operator "<" ist für zukünftige Versionen reserviert.
In Zeile:1 Zeichen:160
+ ... l\Temp\aaa_1et <
C:\Users\O_SCHR~1\AppData\Local\Temp\SQLIteIMportScript.txt`
+                    ~
    + CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordEx
   ception
    + FullyQualifiedErrorId : RedirectionNotSupported

PS C:\Users\o_schrabm\Documents\Programming\CitaviISBNLinker\Win32\Debug>

Mein Aufruf ist:

Delphi-Quellcode:

 C:\Windows\syswow64\WindowsPowerShell\v1.0\powershell.exe  -NoExit c:\windows\system32\cmd.exe /C "`"C:\Users\o_schrabm\Documents\Programming\CitaviISBNLinker\Win32\Debug\sqlite3.exe C:\Users\O_SCHR~1\AppData\Local\Temp\aaa_1et < C:\Users\O_SCHR~1\AppData\Local\Temp\SQLIteIMportScript.txt`""

Was kann ich machen, daß < richtig interpretiert wird?
DANKE

[wschrabi]

Habe jetzt den Fehler:

Der Shell aufruf muss folgendermaßen lauten:

Delphi-Quellcode:

 C:\Windows\syswow64\WindowsPowerShell\v1.0\powershell.exe  -NoExit c:\windows\system32\cmd.exe /C "type C:\Users\O_SCHR~1\AppData\Local\Temp\SQLIteIMportScript.txt| C:\Users\o_schrabm\Documents\Programming\CitaviISBNLinker\Win32\Debug\sqlite3.exe C:\Users\O_SCHR~1\AppData\Local\Temp\aaa_1eww"

[Aviator]

Oh mann. Ich glaube du liest echt keine Antworten oder willst sie nicht lesen. Es wurde bereits von mehreren Usern gefragt, was denn ShellExecute für einen Rückgabewert hat. Es wäre sinnvoll wenn du solche Fragen beantworten würdest, damit man dir richtig helfen kann.

Das was mit der Powershell geht, funktioniert auch mit der Eingabeaufforderung. Zumindest dann, wenn du nur ein Programm aufrufen möchtest.

Ich frage mich, was diese unnötigen doppelten und dreifachen Anführungszeichen sollen. Du brauchst genau ein " vorne und ein " hinten um deine Exe auszuführen. Das wars. Alles was hintendran kommt wird automatisch als Parameter an deine Anwendung weitergegeben. Diesen Parameter kannst du dann auch nochmal mit jeweils einem Anführungszeichen vorne und hinten übergeben um sicherzustellen, dass das auch ankommt wenn Leerzeichen drin enthalten sind.

Ich hoffe das war jetzt nicht wertvolle Zeit die Toilette runtergespült und du beherzigst mal die Tipps die man dir gibt und gibst auch entsprechende Antworten darauf. :roll:

[wschrabi]

ja danke herzlich, war eifrig am Werken, .
ja das mit den `war von hier: http://stackoverflow.com/questions/8...hs-with-spaces
:?:

[Aviator]

Tja. Da haben sich unsere Antworten irgendwo überschnitten. :shock:

Aber bitte merke dir für deine nächsten Fragen, dass du auch auf die Fragen von anderen Forenteilnehmern eingehen solltest. Ansonsten kann nicht oder nur sehr schlecht geholfen werden.

Aber schön das es jetzt funktioniert. :thumb:

[Dalai]

[sarcasm] Jep, mache ich auch immer so - wenn etwas in der CMD nicht funktioniert, klemme ich die PowerShell noch davor. So richtig von hinten durch die Brust ins Auge.
[/sarcasm]

Mal im Ernst: ich bin mir ziemlich sicher, dass dir der Rückgabewert von ShellExecute verraten hätte, wo es klemmt. Und damit hätte man die Problematik gezielter lösen können als mit so einem ... sehr seltsamen Konstrukt.

Grüße
Dalai

[Aviator]

Zitat:

Zitat von Dalai (Beitrag 1354935)

[sarcasm] Jep, mache ich auch immer so - wenn etwas in der CMD nicht funktioniert, klemme ich die PowerShell noch davor. So richtig von hinten durch die Brust ins Auge.
[/sarcasm]

Mal im Ernst: ich bin mir ziemlich sicher, dass dir der Rückgabewert von ShellExecute verraten hätte, wo es klemmt. Und damit hätte man die Problematik gezielter lösen können als mit so einem ... sehr seltsamen Konstrukt.

Grüße
Dalai

Der Meinung bin ich auch. Aber wenn es für ihn jetzt funktioniert und er auf Fragen nicht antworten will, dann kann ihm keiner helfen.

[sakura]

Zitat:

Zitat von wschrabi (Beitrag 1354878)

Der Shell aufruf muss folgendermaßen lauten:

Delphi-Quellcode:

 C:\Windows\syswow64\WindowsPowerShell\v1.0\powershell.exe  -NoExit c:\windows\system32\cmd.exe /C "type C:\Users\O_SCHR~1\AppData\Local\Temp\SQLIteIMportScript.txt| C:\Users\o_schrabm\Documents\Programming\CitaviISBNLinker\Win32\Debug\sqlite3.exe C:\Users\O_SCHR~1\AppData\Local\Temp\aaa_1eww"

Und wenn PowerShell nicht installiert ist (ist immerhin eine OPTIONALE Komponente)...?

...:cat:...

[wschrabi]

ja ich habs mit cmd.exe probiert aber das hat nicht geklappt, weis auch nicht. Mir hat einer gesagt man muss die powershell verwenden. Müßte es nur mit cmd.exe auch unter win 10 gehen?
Jetzt hab ich eine Checkbox wo man zwischen Powershell und cmd.exe schalten kann. DOCH das cmd.exe klappt nicht, nur die Powershell.
der Cmd.exe wird einfach abgewürgt. Wenn mir jemand sagen kann wie ich den Rückgabewert (ausser true/false meiner Wait routine) ermittlen kann - wüßte ich mehr.

Delphi-Quellcode:

            if checkbox8.Checked then
               begin
               myshell:='C:\Windows\syswow64\WindowsPowerShell\v1.0\powershell.exe';
               myshellarg:=' -noExit c:\windows\system32\cmd.exe /C "  type '+gettempdirectory+'SQLIteIMportScript.txt'+'| '+ myapp+' '+uniconnection2.Database+'  " ';
               end
            else
               begin   
               myshell:='c:\windows\system32\cmd.exe';
               myshellarg:=' /C "  type '+gettempdirectory+'SQLIteIMportScript.txt'+'| '+ myapp+' '+uniconnection2.Database+'  " ';
               end;
            WriteLogMemo(Format(' DEBUG: SHell: %s %s ',[myshell,myshellarg]));
            //exeRet:=StartandWait('c:\windows\system32\cmd.exe','/C '+ myapp+' '+uniconnection2.Database+' < '+gettempdirectory+'SQLIteIMportScript.txt');
            //C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
            exeRet:=StartandWait(myshell,myshellarg);

[wschrabi]

Aviator. also der Rückgabe wert war true lt. meiner Wait Routine. ODer wie kann ich den Rückgabewert erfragen? (Sorry für die bloede frage, aber ich lern gern dazu.)

[nahpets]

ShellExecute ist eine Funktion mit einem nummerischen Rückgabewert.

Gibt man in die Suchmaschine seiner Wahl z. B. "ShellExecute ReturnCode" ein, so erhält man einen Link auf folgende Seite: https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

Dort ist detailiert beschrieben, was der erhaltene Rückgabewert bedeutet.

Dabei sind nur Rückgabewerte <= 32 von Bedeutung.

Methode extrem unelegant:

Delphi-Quellcode:

ShowMessage(IntToStr(ShellExecute ( 0, nil, PChar('cmd.exe'), PChar('/C '+ myapp), nil, SW_HIDE));

[mal ganz böse]
Rückgabewerte von Funktionen können bei der Fehlersuche durchaus hilfreich sein. Insbesondere, wenn man sie auswertet ;-)
[/mal ganz böse]

[praktische Erfahrung]
Die Auswertung von Rückgabewerten kann stunden-, tage-, ja sogar wochenlange Fehlersuche gegen 0 reduzieren ;-)
[/praktische Erfahrung]

[wschrabi]

Danke jetzt weiß ich bescheid. AUch habe ich die Ursache für das NICHT FUNKTIONIEREN des cmd.exe gefunden.
WENN ICH das Delphi Prg als ADMINISTRATOR ausführe, siehe an da klappt das cmd.exe
KOmischerweise ging das ohne Admin REchte zuhause auch. Aber am WORKPLACE muss man Admin rechte haben.

Jetzt ist das Problem gelöst, auch hätte der Rückgabewert vielleicht nichts gebracht, weil ja der cmd.exe nicht ausführbar war.
Danke an alle die geholfen haben.

:-D

[himitsu]

Vermutlich weil die auf Arbeit schlauer sind und den von dir gestarteten Programmen nicht "immer" automatisch Adminrechte geben.

[nahpets]

Zitat:

Zitat von wschrabi (Beitrag 1354966)

... auch hätte der Rückgabewert vielleicht nichts gebracht, weil ja der cmd.exe nicht ausführbar war.

Doch, das hätte Dir der Rückgabewert sagen können. Z. B. mit dem Wert ERROR_FILE_NOT_FOUND.

Den bekommt man nämlich, wenn man irgendwas vorhandenes aus Rechtsgründen nicht nutzen darf.

Oder heißt es aus Rechtegründen ;-)

Ok: Mangels entsprechender Rechte.

[wschrabi]

Zitat:

Vermutlich weil die auf Arbeit schlauer sind und den von dir gestarteten Programmen nicht "immer" automatisch Adminrechte geben.

aber wo in den Policies stellt man das ein?

[wschrabi]

Zitat:

Den bekommt man nämlich, wenn man irgendwas vorhandenes aus Rechtsgründen nicht nutzen darf.

Nächste mal weiss ich wieder mehr :P

[Luckie]

Nix Policies. Du wirst an der Arbeit einfach kein Admin sein.

[Aviator]

Zitat:

Zitat von wschrabi (Beitrag 1354972)

Zitat:

Vermutlich weil die auf Arbeit schlauer sind und den von dir gestarteten Programmen nicht "immer" automatisch Adminrechte geben.

aber wo in den Policies stellt man das ein?

Und selbst wenn es Policies wären. Ich glaube nicht das du als einfacher Programmierer Zugriff auf die GPOs bekommen würdest oder der Admin dich in eine andere OU verschiebt die vielleicht mehr Rechte besitzt.

Werte einfach mal den Rückgabewert von ShellExecute aus. Dann siehst du auch, dass er dir entsprechend etwas zurückgibt. Und das Ergebnis postest du dann nochmal hier. Und du wirst lachen. Wahrscheinlich kommt dabei etwas rum, was hier schon mehrfach gesagt wurde. :roll:

[wschrabi]

Doch ersten habe ich admin Rechte, denn sonst könnte ich ja auch nicht das Prg mit Admin ausführen (Rechtsklick und AUSFÜHREN ALS ADMIN)
Denke das sind schon Policies. Außerdem frage ich mich, da ja die powershell ja auch mit admin REchte läuft. (Ohne Anclick Ausführen als ADMIN)
:?