Verrücktes Problem mit Delphi7 und ShellExecute

[iphi]

Hallo,

ich bin kurz vor dem Verrücktwerden!
Ich versuche etwas zu machen, das ich schon zig mal gemacht habe und bekomme die seltsamsten Fehler.

Hier der Code, ganz einfach:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, ShellAPI;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
ShellExecute(Handle,'open','notepad.exe','', nil, SW_SHOWNORMAL);
end;

end.

Auf Knopfdruck soll der notepad öffnen. Unter der Delphi6 IDE funktioniert das auch.

Unter der Delphi7 IDE compiliert das zwar auch, aber beim ersten Starten liefert die IDE die Fehlermeldung:

Zitat:

Unable to create process: Zugriff verweigert

Bei jedem weiteren Startversuch kommt

Zitat:

Could not find program D:\test\project1.exe

Es wurde aber genau da vom Compiler erzeugt.

Wenn ich die IDE schließe und die exe von Hand starten will, dann kommt

Zitat:

Zugriff verweigert

Löschen kann ich die exe aber.

Wenn ich den ShellExecute auskommentiere, dann läuft alles normal.

Kann sich irgend jemand einen Raum darauf machen???

[Dalai]

Verhindert vielleicht dein Virenscanner den Zugriff bzw. das Starten des Delphi-Kompilats?

MfG Dalai

[bra]

Fehlt da nicht auch der Pfad zur notepad.exe?

[Der schöne Günther]

Bist du dir sicher dass

Delphi-Quellcode:

'open'

das richtige Verb ist? Ich hätte, beim Ausführen von Anwendungen, einfach

Delphi-Quellcode:

Nil

genommen:

Zitat:

The default verb is used, if available. If not, the "open" verb is used. If neither verb is available, the system uses the first verb listed in the registry.

Analog die Parameter (nach dem 'Notepad.exe'): Auch hier würde ich Nil und keinen leeren String übergeben.

Weiterhin verstehe ich dein "Wenn ich das auskommentiere ..." nicht. Sieht dein Quellcode wirklich so aus wie gezeigt? Ein ShellExecute an sich wirft keine Fehler, sondern gibt nur eine Zahl zurück. Oder hast du es so?

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
   if ShellExecute(Handle,'open','notepsd.exe','', nil, SW_SHOWNORMAL) <= 32 then
      RaiseLastOSError();
end;

[nahpets]

Prinzipiell sollte der Aufruf in der genannten Form unter Delphi 7 funktionieren.

Zur Fehlereingrenzung:

1. Programm mit Strg+F9 kompilieren
2. kurzen Moment warten und unter D:\test\nachschauen, ob das die project1.exe dort vorliegt.
3. Wenn vorhanden
   • per Doppelklick starten und schauen, ob NotePad gestartet wird.
   • Wird Notepad nicht gestartet prüfen, ob der Virenscanner einen Alarm gemeldet hat...
4. Wenn nicht vorhanden
   • prüfen, ob der Virenscanner einen Alarm gemeldet hat, das Programm in die Quarantäne verschoben hat...
   • Ist dem so, dass Ausgabeverzeichnis von Delphi vom Virenscanner nicht überwachen lassen.

Ansonsten:

• Wie von Günther vorgeschlagen, den Rückgabewert von ShellExecute abfragen und im Programm entsprechend reagieren.
• Da es bei Programmen, die mit Delphi 7 erstellt werden, ab und an von Virenscannern (zumindest bei Avira ist das so) Fehlalarme geben kann, habe ich bei mir das Ausgabeverzeichnis für die Exen aus der Überwachung durch den Virenscanner herausgenommen.

[iphi]

Tatsächlich. Der Avira Professional Virenscanner blockiert das Exe, sobald es erzeugt wird.
Eine Meldung kommt aber nicht!
Wenn er deaktiviert ist, dann gehts. Was kann man denn dagegen machen?

[Dalai]

Zitat:

Zitat von iphi (Beitrag 1331148)

Was kann man denn dagegen machen?

Whitelisten, wie bereits gesagt wurde. Möglicherweise kann es helfen, ein Sample an Avira zu schicken, damit die das aus ihren Signaturen nehmen bzw. selbige anpassen. Von Avast kenne ich es aber so, dass man das sehr oft machen muss, bevor die ihren Krempel auf die Reihe bringen und keine uralten Programme mehr als False Positive erkannt werden.

MfG Dalai

[nahpets]

Zitat:

Zitat von iphi (Beitrag 1331148)

Tatsächlich. Der Avira Professional Virenscanner blockiert das Exe, sobald es erzeugt wird.
Eine Meldung kommt aber nicht!
Wenn er deaktiviert ist, dann gehts. Was kann man denn dagegen machen?

In der Konfiguration von AVira: (Taste F8)

Unter

• PC-Sicherheit
• Echtzeit-Scanner
• Scan
• Ausnahmen
• Vom Echtzeit-Scanner auszulassende Dateiobjekt
  • Im Eingabefeld D:\Test\ eintragen
  • Button "Hinzufügen" betätigen
• Button "Übernehmen" klicken und testen, ob das Problem weg ist.

[jaenicke]

Wer Delphi nutzt, für den ist Avira definitv der falsche Virenscanner. False Positives gibt es dort seit gefühlt 10 Jahren in Zusammenhang mit Delphi immer und immer wieder (genau kann ich das zeitlich gar nicht einordnen). Ich habe schon sicher dutzende Samples eingeschickt, es ist auch etwas besser geworden, aber an einer echten Lösung scheint dort niemand Interesse zu haben.

Ich kann nur raten einen anderen Virenscanner zu nutzen, es gibt genügend wirklich gute...

[mm1256]

Zitat:

Zitat von jaenicke (Beitrag 1331154)

Wer Delphi nutzt, für den ist Avira definitv der falsche Virenscanner...

+1 :thumb: Das Problem ist, dass Avira auch bei Kunden öfter anschlägt, ohne Grund. Dagegen hilft dann nur noch signieren, dann wird es weniger, aber ganz auf null geht es leider nicht zurück. Avira ist ein Sche...

[iphi]

Vielen Dank für die Tipps!

Es ist übrigens nicht nur Avira, was anschlägt. Hab spasseshalber das Programm bei VirusTotal scannen lassen.
9 von 55 positiv:

Zitat:

AegisLab Troj.W32.Llac 20160223
Antiy-AVL Trojan/Win32.Agent 20160223
Avast Win32:Malware-gen 20160223
Avira (no cloud) TR/ATRAPS.Gen 20160223
DrWeb Trojan.DownLoader1.14855 20160223
Jiangmin TrojanDownloader.Banload.almf 20160223
Qihoo-360 HEUR/QVM05.1.Malware.Gen 20160223
Zillya Downloader.Banload.Win32.16248 20160223
nProtect Trojan-Downloader/W32.Banload.375296.R 20160223

P.S.
Interessant nur, dass das Delphi6 Kompilat keinen Alarm auslöst.

[mm1256]

Interessant auch, dass es so viele verschiedene Viren sind. Da sieht man mal, wie krank das System teilweise ist.

[Luckie]

Es wird wohl immer das selbe Bit-Muster sein, nur jeder Hersteller gibt ihr einen anderen Namen.

[jaenicke]

Zitat:

Zitat von iphi (Beitrag 1331156)

Es ist übrigens nicht nur Avira, was anschlägt. Hab spasseshalber das Programm bei VirusTotal scannen lassen.
9 von 55 positiv:

Keiner der dort aufgeführten Scanner fällt bei mir in die Kategorie gut. Überraschen tut mich das Ergebnis (leider) nicht.

[sahimba]

Etwas OT: ShellExecute funktioniert unter Windows 10 nicht mehr so, wie bisher und man sollte ShellExecuteEx den Vorzug geben. Hier bspw. wurden Dateien (bspw. PNG) nicht mehr mit den verknüpften Anwendungen geöffnet. Finde leider gerade den Link nicht, in welchem Genaueres steht.
Vielleicht eine gute Gelegenheit, das anzupassen?

[bra]

Zitat:

Zitat von jaenicke (Beitrag 1331159)

Keiner der dort aufgeführten Scanner fällt bei mir in die Kategorie gut. Überraschen tut mich das Ergebnis (leider) nicht.

Bei mir hat Avira bisher immer ganz gute Dienste geleistet und auch keine falschen Alarme verursacht. Bei Tests schneidet der auch immer ganz gut ab. Ich glaube das ist alles sehr subjektiv.

Außerdem ist es immer noch besser, wenn der falsche Alarm schon beim Entwickeln kommt, als erst beim Kunden...

[baumina]

Ich konnte nach einem Avira-Update nicht mehr debuggen, dauerte ewig bis sie den Fehler damals behoben hatten. In der Zwischenzeit wurde Avira in unserem Haus durch GData ersetzt, das Ding bremst nur, macht aber sonst keinen Kummer.

[Der schöne Günther]

Zitat:

Zitat von sahimba (Beitrag 1331164)

ShellExecute funktioniert unter Windows 10 nicht mehr so, wie bisher und man sollte ShellExecuteEx den Vorzug geben. Hier bspw. wurden Dateien (bspw. PNG) nicht mehr mit den verknüpften Anwendungen geöffnet. Finde leider gerade den Link nicht, in welchem Genaueres steht.

Das wäre mir neu. Meine PNGs gehen auch unter Windows 10 genauso wie vor zehn Jahren. :|

[himitsu]

Zitat:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
   if ShellExecute(Handle,'open','notepsd.exe','', nil, SW_SHOWNORMAL) <= 32 then
      RaiseLastOSError();
end;

Mit einer falschen Fehlerbehandlung kann man auch viel Schrott produzieren.

ShellExecute/ShellExecuteEx gibt den Fehler nicht per GetLastError zurück.

RaiseLastOSError nutzt aber GetLastError
Und den Result als Parameter an RaiseLastOSError zu übergeben geht auch nicht, da die Fehlercodes sich unterscheiden.

Delphi-Quellcode:

function ShellExecuteGLE(hWnd: HWND; Operation, FileName, Parameters, Directory: PWideChar; ShowCmd: Integer): HINST; overload;
begin
  Result := ShellExecuteGLE(hWnd, Operation, FileName, Parameters, Directory, ShowCmd);
  if Result <= 32 then begin
    case Result of  // Übersetzung: DDE Error > Win32 Error Code
      0:                      Result := ERROR_OUTOFMEMORY;
      ERROR_BAD_FORMAT:       ;
      SE_ERR_ACCESSDENIED:    Result := ERROR_ACCESS_DENIED;
      SE_ERR_ASSOCINCOMPLETE: Result := {?}ERROR_ACCESS_DENIED;
      SE_ERR_DDEBUSY:         Result := {?}ERROR_BUSY;
      SE_ERR_DDEFAIL:         Result := ERROR_DDE_FAIL;
      SE_ERR_DDETIMEOUT:      Result := {?}ERROR_TIMEOUT;
      SE_ERR_DLLNOTFOUND:     Result := ERROR_DLL_NOT_FOUND;
      SE_ERR_FNF:             Result := ERROR_FILE_NOT_FOUND;
      SE_ERR_NOASSOC:         Result := ERROR_NO_ASSOCIATION;
      SE_ERR_OOM:             Result := {?}RPC_S_OUT_OF_RESOURCES;
      SE_ERR_PNF:             Result := ERROR_PATH_NOT_FOUND;
      SE_ERR_SHARE:           Result := ERROR_SHARING_VIOLATION;
    end;
    SetLastError(Result);
    Result := 0;  // INVALID_HANDLE_VALUE?
  end;
end;

[Der schöne Günther]

Guter Hinweis, mein Fehler :warn: