Inoffizielles deutsches Xbase-Forum

Windows 10
Blöde Sache - keine Ahnung woran das liegt : 2 Programme (.EXE) in einem Verzeichnis auf einer F:Partition - eins davon startet normal -
das andere nur mit Administratorrechten, also oben in der Menüleiste "als Administrator ausführen" NUR SO.
Wenn ich das Feld bei Eigenschaften setze startet es auch nicht - beides normal erzeugte .EXE.
Wenn ich es nach C: kopiere läuft es dort ... also irgendwas mit Rechten aber welche wo und wieso unterschiedlich ?
Eine Idee ? Danke fürs Überlegen ....
Gruß Rainer

Moin Rainer,
wie heißt es denn? Irgendwas mit Setup oder Install o.ä. im Namen?

Viele Grüße,
Martin

rech_01_printer.exe ...geht da irgendwas nicht ?
Gruß Rainer

Nö - damit ist alles i.O.
Was für ein Filesystem ist C: und was für eines F:?
Ist F: lokal oder extern?

Viele Grüße,
Martin

Soweit ich mich erinnere wird immer dann nach einem Admin gefragt, wenn die lokalen Rechte des Users nicht ausreichen.
Am EXE Namen sehe ich jetzt kein Problem, aber um sicher zu sein, benenne doch mal die EXEs gegenseitig um.
Wenn die Aufforderung mit wechselt, liegt es an der EXE bzw. deren Zugriffswünsche, wenn nicht, doch am Namen.

sehr seltsam ...

@Reiner

ich nehme an, dass Du die Programme nicht direkt auf C:\ oder F:\ liegen hast sondern in Unterverzeichnissen.
Gebe uns alles an sonst gibt es viel zu viele Möglichkeiten warum das Programm nicht läuft.

Das hin und herkopieren eines Programms transportiert nicht automatisch die Rechte mit.
z.B. je nach verwendetem Kopierbefehl greifen die vererbbaren Rechte und die können den Start eines EXE verhindern.

Verschieben statt kopieren bewirkt z. B. oftmals, das die rechte aus dem alten Verzeichnis mitgenommen werden, statt die des neuen Verzeichnisses zu übernehmen.

Ich habe aber nicht das Gefühl, daß das hier das Problem ist.

Jan

Das kommt jetzt auch auf C beim Ausführen...
//
FATAL ERROR LOG
Not recoverable Error!
SYS Thread-ID: 904
Module: EH
Error Codes: EH: 900 Sub: 0(0) OS: 0 XPP: 0
Call Stack of Thread 1 (904):
Call Stack of GUI Thread (1144):
File: C:\Rechnung_01\Rech01.EXE
TimeStamp: 20180130 10:55
End of FATAL ERROR LOG.
..sagt mir Quereinsteiger nix ...

Vermutlich fehlen dem Programm jetzt Daten, die es dringend bräuchte. Du erzeugst einen Fehler im Fehlersystem. Das kann zum Beispiel passieren, wenn man die Tabelle mit den Lizenzangaben zur Software nicht öffnen kann und dann in der Errorsys den Lizenznamen berücksichtigen will, der ja nicht bekannt, sondern die Fehlerursache ist.

also : jetzt habe ich den Rechner neu gestartet - irgendwas passierte wohl im Speicher.
Es arbeitet jetzt normal - aber es war schon merkwürdig ...
Ich verfolge es mal mit ein paar Tests ! Weiss jemand was das FatalLog mir sagen will ?
Rainer

Normalerweise erzeugt das Fehlersystem von Xbase++ eine XppError.LOG - dort werden dann Infos über den Fehler protokolliert ...

Wenn es aber innerhalb dieser Fehlerbehandlung einen Fehler gibt, oder aus sonstigen Gründen das Programm ohne eine solche abstürzt (unbekannte Fehlerursache),
dann wird eine XppFatal.log generiert. Steht dort was von stackoverflow, dann ist es meist ein Fehler in der Fehlerbehandlung der zu einer Endlosschleife führt.
Ansonsten sind alle Fremd-DLL Aufrufe die z.B. Speicher reservieren oder sonstiges ändern solche Kandidaten.

Aber wissen tut man nur - es hätte nicht vorkommen sollen

Vermutlich wird mit dem Compilerschalter /l für das Unterdrücken von Zeilennummern kompiliert, sonst könnte man für Thread 1 (ID 904), bei dem es sich vermutlich um den EXE-Thread höchstselbst handelt, eine Zeilennummer sehen. Auf jeden Fall tritt der Fehler im Errorhandler (EH) auf, wird aber vermutlich durch einen Laufzeitfehler im PRG erzeugt. Der Fehler ist so oll, dass das Fehlersystem nicht weiterweiß.

medmaster hat geschrieben: ↑Di, 30. Jan 2018 10:58 Das kommt jetzt auch auf C beim Ausführen...
//
FATAL ERROR LOG
Not recoverable Error!
SYS Thread-ID: 904
Module: EH
Error Codes: EH: 900 Sub: 0(0) OS: 0 XPP: 0
Call Stack of Thread 1 (904):
Call Stack of GUI Thread (1144):
File: C:\Rechnung_01\Rech01.EXE
TimeStamp: 20180130 10:55
End of FATAL ERROR LOG.

wenn ich den Titel nicht gelesen hätte würde ich sagen das es PDR 6904 ist wegen der EH Meldung.

ich würde es mal mit einem "anderen" User / Rechten versuchen.

Nach weiteren Versuchen : was habe ich aus dem Verwirrspiel von Meldungen gelernt :
Die Zuweisung eines nicht existierenden Verzeichnisnamens zu einer Variablen führt zu diesem
Verwirrspiel an Fehlermeldungen .. offensichtlich interpretiert das Betriebssystem diesen
Fehler als "Fehlen von Rechten" , der dadurch entstehende Speicherfehler kann nur durch
Neustarten behoben werden.
Danke für alle Überlegungen !
Gruß Rainer

@Reiner

medmaster hat geschrieben: ↑Do, 01. Feb 2018 12:10Die Zuweisung eines nicht existierenden Verzeichnisnamens zu einer Variablen führt zu diesem Verwirrspiel an Fehlermeldungen

Interessante Schlussfolgerung - ich glaube Du hast den Fehler noch nicht richtig lokalisiert.
Die Zuweisung eines Wertes zu einer Variablen interessiert das Betriebssystem bezüglich Benutzerrechten gar nicht.
Bsp. cDir := "c:\test\"
Allerdings sieht das anders aus wenn Du bei der Zuweisung des Wertes auch auf das nicht vorhandene Verzeichnis zugreifen willst.
Bsp. lCreate := CreateDir( "c:\test\" )
aber auch in meinem Beispiel "sollte" das Programm nicht abstürzen.

Hallo Roland !

Die Zuweisung eines Wertes zu einer Variablen interessiert das Betriebssystem bezüglich Benutzerrechten gar nicht.

Das würde ich nicht behaupten.
Ich hatte mal im Windows-Suchpfad (SET PATH) ein nicht (mehr) vorhandenes Verzeichnis.
Das hatte schon Auswirkungen; die Suche nach der Fehlerursache war schon zeitraubend.

Hallo Hans-Peter

HaPe hat geschrieben: ↑Do, 01. Feb 2018 12:46Ich hatte mal im Windows-Suchpfad (SET PATH) ein nicht (mehr) vorhandenes Verzeichnis.

Das kann ich mir durchaus vorstellen. Nichts desto trotz muss dann Dein Prog irgend etwas auf der Betriebssystem-Ebene tun damit da was passiert. Eine reine Wertzuweisung hat mit dem Pfad nichts zu tun. Es ist eher zu vermuten, dass der Fehler vorher passiert aber beim Absturz die Zeile falsch angegeben wird. Hatte man ja schon öfters.

Hier wäre schon was denkbar - ist aber auch nicht blos eine einfache Wertzuweisung:
cPath := Environment( "PATH" )

es ist richtig : die Zuweisung machts nicht - wahrscheinlich das default to ... auf ein Verzeichnis das nicht existiert.
Jedenfalls stürzte das Programm bereits dort ab.
....................................

Martin Altmann hat geschrieben: ↑Di, 30. Jan 2018 5:49 Moin Rainer,
wie heißt es denn? Irgendwas mit Setup oder Install o.ä. im Namen?

Viele Grüße,
Martin

Hallo Martin,

den Fall habe ich ("UpdateSimaFibuUpsized.exe"), ich will aber keine Administratorrechte für das Programm.
Es kommen die Meldungen:

Warnung: Der Name der .EXE-Datei enthält "setup" oder ein ähnliches Element. Der Klientprozeß läuft möglicherweise mit erhöhten Benutzerrechten!
Fehler beim Starten des Clientprozesses (Code: 273, Fehler beim Erzeugen des Debug-Klientprozesses: Error Code 273, Ausgeführte Datei: C:\GIT\SIMA-POSTGRES\UpdateSimaFibuUpsized\run\UpdateSimaFibuUpsized.exe).

Das Verhalten finde ich, milde ausgedruckt, seltsam...
Kennst Du einen Weg, es zu unterbinden, oder bin ich zum Umbenennen gezwungen?

Nebenfrage: Die EXE wird in einem Unterverzeichnis "run" erzeugt, anstatt wie gewohnt im Projekverzeichnis.
Weißt Du zufällig, ob man das irgendwo umstellen kann?

Vielen Dank!

Moin David,
Du solltest es umbenennen (ist am einfachsten).
Was Deine Nebenfrage anbelangt: ist - glaube ich - eine Einstellung im Projectfile (und somit in den Optionen der Workbench).

Viele Grüße,
Martin

Dankeschön Martin!

Ja, das mit dem Verzeichnis "run" ging ganz einfach direkt in der XPJ-Datei zu ändern (habe ich nicht in den Workbench-Einstellungen gefunden).

Tcha, dann werde ich wohl alles umbenennen müssen.
Was auf immer der Workbench-Programmierer dabei geraucht hat, hätte ich auch in meinen jüngeren Jahren gern etwas davon gehabt...

David,
die Probleme mit den Adminrechten bezogen auf den Dateinamen hat nichts mit der Workbench zu tun - das ist ein „Sicherheitsfeature“ von Windows!

Viele Grüße,
Martin

Man wird alt wie eine Kuh und lernt immer was dazu...

OK, ist bei Microsoft!

Eigentlich sollte ich mich bei den Workbench-Programmierern nicht nur entschuldigen sondern auch bedanken, dass sie diesen Fall melden, also hiermit tue ich das!