Prozess kann nicht erzeugt werden

[API]

Hallo,

ich stelle ein Projekt von Win32 auf Win64 um. Wenn die Platform Win32 ist, wird die EXE ausgeführt. Bei Auswahl Win64 gibt es eine Fehlermeldung.
Woran könnte das liegen?

Zitat:

---------------------------
Fehler
---------------------------
Prozess kann nicht erzeugt werden: 'C:\Users\ABC\OneDrive\Dokumente\Embarcadero\Studi o\Projekte\abc\abc.exe'.
---------------------------
OK
---------------------------

[Moombas]

an dem Leerzeichen evtl? Oder ist das ein Copy/Paste Fehler?^^

'C:\Users\ABC\OneDrive\Dokumente\Embarcadero\Studi o\Projekte\abc\abc.exe'.

[Uwe Raabe]

Sehe ich das richtig: Du erzeugst deine Projekte in einem OneDrive Ordner?

[himitsu]

Tja, das heißt dass deine EXE noch von irgendwem geöffnet ist -> Programm läft noch oder z.B. OneDrive greift noch darauf zu, um es in die Cloud zu schieben.

Zitat:

Zitat von Moombas (Beitrag 1455820)

an dem Leerzeichen evtl? Oder ist das ein Copy/Paste Fehler?^^

Ist vom Forum, welches regelmäßig Leerzeichen einfügt, in "überlange" Wörter.
In diesem Fall einfach seinen Beitrag zitieren und dieses Leerzeichen ist dort nicht im Text. :zwinker:

[API]

Das Leerzeichen wurde von der Forumsoftware hinzugefügt.

Wenn ich bei der Platform "Windows 32 Bit" auswähle und dann das Projekt starte (F9), startet die EXE

Zitat:

C:\Users\ABC\OneDrive\Dokumente\Embarcadero\Studio \Projekte\abc\abc.exe

Wenn ich bei der Platform "Windows 64 Bit" auswähle und dann das Projekt starte (F9), startet die EXE nicht, obwohl der Output-Pfad der EXE-Datei identisch ist.

Zitat:

C:\Users\ABC\OneDrive\Dokumente\Embarcadero\Studio \Projekte\abc\abc.exe

Der Dokuemnte-Ordner wurde auf diesem PC halt so eingestellt (nicht von mir): "C:\Users\ABC\OneDrive\Dokumente\" sollte aber keine Relevanz haben.

[API]

Habe nun gesehen, dass auch im 64 Bit Modus die EXE zwar erstellt wird. Wird sie außerhalb von Delphi ausgeführt, erscheint die Benutzerkontensteuerung.
Diese greift jedoch nur beim 64 Bit ein, beim 32 Bit Prozess nicht. Darum führt es im 32 Bit Modus auch aus.

Frage nun (kenne mich damit nicht gut aus): Wie deaktiviere ich diese Benutzerkontensteuerung (nur) für Delphi Anwendungen?

[Dalai]

Schau dir mal die Versionsinformationen deiner erzeugten EXE bzw. die im Projekt eingestellten genauer an. Dort ist (sehr) wahrscheinlich ein Begriff (wie "install", "setup" o.ä.) drin, der dazu führt, dass die erzeugte EXE Adminrechte anfordert. Alternativ könnte das auch durch ein Manifest ausgelöst werden, d.h. es könnte sein, dass für Win64 ein anderes eingebunden wird als für Win32.

Grüße
Dalai

[API]

Zitat:

Zitat von Dalai (Beitrag 1455860)

Schau dir mal die Versionsinformationen deiner erzeugten EXE bzw. die im Projekt eingestellten genauer an. Dort ist (sehr) wahrscheinlich ein Begriff (wie "install", "setup" o.ä.) drin, der dazu führt, dass die erzeugte EXE Adminrechte anfordert. Alternativ könnte das auch durch ein Manifest ausgelöst werden, d.h. es könnte sein, dass für Win64 ein anderes eingebunden wird als für Win32.

Grüße
Dalai

Volltreffer! Da war noch seine eine Manifest-Datei eingebunden. Entfernt und funktioniert's! Danke allen für eure Inputs!

[DukeM]

Habe auf einmal das gleiche Problem. Seit 2 Jahren nichts geändert an dieser Delphi installation.

Das Problem kommt auch wenn ich ein ganz neues, leeres Propjekt starte.

Projektoptionen >> Versionsinformation = steht nichts drin außer standards
Projektoptionen >> Anwendung = ohne Manifestdatei

[himitsu]

Warum ohne?

Gerade einige Teile des Manifestes würde ich für eine ordnungsgemäße Funkion von Programmen als essentiell ansehen. (z.B. die Komapatibilitätsangabe des OS und eigentlich auch bezügloch der "neuen" GUI/API)

[DukeM]

ich habe es auch ohne getestet, weil hier ja jemand schrieb das hat bei ihm gestört.

Jetzt ist es mittlerweile so, dass es mal wieder 2 Tage ging und nach einem Neustart wieder nicht. Egal ob VCL oder FMX 64Bit.
Egal ob ganz neues Projekt, oder bestehende.
Was kann es außer Virenscanner sein ?

[himitsu]

Ich sollte mich mal wieder mit dem WindowsEventsLog beschäftigen. (hatte da mal angefangen einen Logger/LiveLogger zu basteln)
Da bekommt man auch gestartet Prozesse, bzw. StartVersuche und noch viel mehr mit.

Mit ProcMon sieht man zwar auch viel (zumindest Dateizugriffe und Zugriffsfehler, welche es auch beim Start einer Anwendung gibt)
dagegen kann hat aber das HighPerformenceLog vom Windows enorm viel drin.
Da kann man sogar sehen wo CriticalSections erstellt/angefragt/gesperrt/freigegeben werden. (blöd nur, dass der Billignachbau TMonitor von Embarcadero das Log vergisst zu benachrichtigen)

Die Grundfunktionen vom dotNET / C# füllen das Log sehr gut.
Da hatte ich mal gesehn, wie jemand ein Auswertetool für schrieb, um das Log zu analysieren. Und am Ende konnte für seinen damit geschriebenen WebServer rausfinden wo und raum der immer mal wieder kurz hängt.
Selbst für Delphi kann man Unmassen an Infos darüber rausbekommen -> Speicherverwaltung (nicht FastMM, die Systemfunktionen dahinter), CriticalSections/TCriticalSections (nicht den eigenen TMonitor und TMultiReadWriter oder wie der heißt), Exceptions, Auslagerungsdatei, DLLs/Packages laden, Datei und Registtryzugriffe, Netzwerk und eben auch gestartete oder nichtgestartete Programme uvm.

Wer besondert krank masochistisch veranlagt ist, darf gern mal mit dem Windows Performance Recorder (wpr.exe / wprui.exe) und dem Windows Performance Analyzer (wpa.exe) spielen.

Wir suchen grade bei einem Kunden, warum bei einem seiner Rechner dort unser Programm oft so extrem langsam startet. Dafür hatte ich im Support bei uns mal das zusammengeklimpert:

Zitat:

Außer im Taskmanager und Ressourcenmonitor

Delphi-Quellcode:

%windir%\system32\perfmon.exe /res

(im Win10-Taskmanager als Link unter Leistung)
zu schauen, ob man irgendwas sieht, was ausgelastet ist oder bremst,

oder explizit Logs erstellen zu lassen, um dort nachzusehn (die Logs lassen sich speichern und an uns schicken),
fällt mir auf die Schnelle auch erstmal noch nichts ein.

Also in den Logs des Prozessmonitors https://learn.microsoft.com/de-de/sy...nloads/procmon
oder dem Windows Performance Recorder

Delphi-Quellcode:

C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\WPRUI.exe

Der Recorder, bzw. das Windows SDK, ist bestimmt nicht installiert.
(müsste man echt mal nachsehn, ob man solche Tools auch ohne die fette Installation des SDK bekommt jupp geht, ist bloß ein paar 100MB das nötige Unterverzeichnis)

LiveLogger -> direkt an eine/mehrere LogSources hängen und sofort filtern zu können, ohne dass erst Gigabyte an Logdaten anfallen.

[DukeM]

..danke, aber selber auf die Suche gehen ist schon mühsam :-)

jetzt habe ich das hier gefunden und es hat zumindest mal auf anhibe was gebracht. Ich werde es mal verfolgen, ob es nur Zufall war


=====

The debugger fails to connect to the port 64448 because the port is in the excluded ports list. To check the list execute:

netsh int ipv4 show excludedportrange protocol=tcp

To flush this list stop and restart the winnat service.
Run as Admin: net stop winnat and net start winnat
Now recheck the list with netsh.
Debug works again.

=====

[DukeM]

Fazit: Bei mir hilft es definitiv "net stop winnat and net start winnat" auszuführen VOR Delphi start.

Weiß Jemand warum und auf welchem Port Delphi 10 lauscht? Nutzen die das um die Lizenz zu prüfen.
Wir wissen auch, dass Embarcadero innerhalb des lokalen Netzwerks Delphi Installationen sucht!

[himitsu]

Die Lizenz wird (glaub ich) nicht bei jedem Start geprüft.
Erst wieder, wenn die letzte Prüfung mehr als 30 Tage her ist. (außer z.B. im eigenen ELC ist eine kürzere Zeit eingestellt)

Ja, es gibt einen lokalen Server + Prüfung auf andere aktive Delphis. (beim Debuggen der IDE knallt es auch wunderschön, wenn lokal bereits ein Delphi läuft, da dann der "zweite" Server nicht gestartet werden kann).

Falls es nicht deaktiviert ist, gibt es noch den UpdateCheck, beim Delphi-Start.
Und dann eventuell auch noch GetIt (z.B. wenn das auf der Willkommensseite läuft).

Bei Win64 läuft im Hintergrund auch immer ein RemoteDebugger, welcher ja via TCP mit'm Delphi redet. (ebenso für Android/iOS/Linux/usw.)