XProfan-Programme starten nicht...

Liegt es an XProfan?
Bei mir wurde nicht neu kompiliert - immer die selbe Datei. Auf dem gleichen Rechner lief sie mal, mal lief sie nicht - je nachdem, wann sie heruntergeladen wurde. (...und vielleicht auch wo sie abgespeichert wurde?)

Auf was ich hinaus will:
Bei einem Speicherüberlauf muss es nicht unbedingt immer zu Abstürzen kommen. Manchmal ist das, was passiert, scheinbar rein zufällig und hängt davon ab, wie Speicher weiter belegt wird.
Die Adresse des gleichen Strings ist zum Beispiel nicht immer bei einem gestarteten Programm zur gleichen Zeit der Programmausführung an der selben Stelle zu finden. Kommen mehrere Faktoren zusammen, crasht es. Kommen sie nicht zusammen, crasht es nicht.

Ich vermute hier ganz stark ein solches Problem im Interpreter - und zwar im Interpreter der compilierten EXE - also der PRFRUN32.exe.

Bei jeder Kompilierung änder sich die Prüfsumme der EXE - damit auch die Wahrscheinlichkeit eines Absturzes auf dem jeweiligen Rechner. Es kann also sein, dass es nach einer Neukompilierung eher auf anderen Rechnern crasht.

Du musst nicht mehr nach einem ADS suchen. Nach der Rückmeldung von H.Brill hat sich die Sache erledigt.
Die ZIP lässt sich auch mit 7Zip öffnen (gerade getestet). Download defekt? Noch einmal probieren.

Da kommen wir sowieso nicht weiter. Das scheint ein Problem der Sprache zu sein, da bin ich mir ziemlich sicher.

Solange man Programme schreibt, die nicht zwingend immer und überall laufen müssen, ist das wohl auch nicht ganz so schlimm. Ich hatte den Effekt bei einem von 200 Rechnern.
Ich bin erst mal froh, dass andere auch auf das Problem gestoßen sind - das erleichtert mir manche Entscheidung. Diesbezüglich nochmals besten Dank euch beide (H.Brill und Horst) für die Beiträge hier!
Dass war sehr informativ. Ohne die zwei Postings hier, hätte ich was ganz anderes vermutet.

Weil ganz andere Voraussetzunge im Speicher vorhanden sind, als auf anderen Rechnern.
Das jemand 6 richtige im Lotto hat, ist sehr unwahrscheinlich. Trotzdem trifft es manchmal jemanden. Welche Zahlen da rollen, hängt von vielen Faktoren ab.
Wenn du mal überprüfst, auf welcher Adresse ein String beim Ausführen eines Programms landet, wirst du feststellen, dass es einige Adressen gibt, wo die Wahrscheinlichkeit größer ist, dass er dort landet. Auf einer anderen Maschine liegt aber die Wahrscheinlichkeit bei anderen Adressen höher.
Kompilierst du ein XProfan Programm neu, ändert sich ebenfalls wieder die Wahrscheinlichkeit, auf welcher virtuellen Adresse der String landet.

Wie gesagt: Alles was du hier geschrieben hast, war sehr hilfreich. Und H.Brill hat noch den Rest dazugegeben.

Ab Vista ändert sich die Wahrscheinlichkeit, wo Speicher belegt wird, nach jedem Reboot - die Ladeadressen für System-DLLs sind nicht mehr so fix, wie unter XP.
Bei den meisten Rechnern (einschließlich meines Rechners) reichte ein Reboot aus, um das Programm letzendlich zum Laufen zu bekommen. Danach hatte ich nie wieder Probleme dieser Art.
Manche Leute bekommen aber mehrfach sechs Richtige beim Lotto - auch das gibt es. Zusätzlich in einer EXE ausgeführter Code (ob von Virenscanner oder von Malware ist egal) erhöht wiederum die Wahrscheinlichkeit, dass irgendwo etwas schief läuft. Gesinkte Würfel würfel fast jedes Mal eine 6.

Früher hat man mal gelernt, daß jede Anwendung in ihrem
eigenen Adressraum läuft und daß Windows diesen auch dann
verwaltet. Da könnte doch normalerweise nichts schiefgehen,
es sei denn, dem PC geht mangels RAM die Puste aus und Windows
versucht, auszulagern.

Oder ist dem nicht mehr so ?

Vielleicht ist auch ein Speicherleck in der Profrun32, das Roland
noch nicht entdeckt hat und das sich halt nur bei bestimmten
Konstellationen bemerkbar macht. Keiner ist ja vollkommen,
das merken wir ja bei unserer Programmiererei auch. Da gibt es
ja auch Feinheiten, die nicht auffallen, da das Programm ja ordnungs-
gemäß läuft. Ich denke da mal an das DIM von Bereichen, die auch
laut Roland mit DIPOSE wieder freigegeben werden sollten. Wenn
man davon reichlich Gebrauch macht, können ja auch Memoryleaks
entstehen, die sich bemerkbar machen.

Zitat von H.Brill

Früher hat man mal gelernt, daß jede Anwendung in ihrem
eigenen Adressraum läuft und daß Windows diesen auch dann
verwaltet. Da könnte doch normalerweise nichts schiefgehen,

Es sei denn, es werden Teile eines noch genutzten Speicherbereichs mit anderen Daten überschrieben. Das kann auch durch DLLs geschehen, deren Code im Prozess ausgeführt wird (DLLs eines Virenscanners zum Beispiel). Das kann zum Beispiel durch einen Speicherüberlauf passieren. Ein Speicherüberlauf durch fehlerhaften Code muss nicht immer in jedem Fall zu einem Crash führen.

Weitere Gründe könnten sein:

• Fehlerhafter RAM.
• Fehler auf dem Datenträger.

Wird aufgrund eines Hardwaredefektes von XProfan ein Call auf eine Nulladresse ausgeführt, kommt es zum Hängen der Anwendung und die Prozessorauslastung steigt in einem Kern auf 100%.
Defekte im RAM müssten weitere Programmabstürze von anderen Anwendungen zur Folge haben. Die müsste man in der Ereignisanzeige finden.
Bei Problemen auf dem Datenträger müsste die Prüfsumme der EXE nicht mit der Prüfsumme der selben EXE (zum selben Zeitpunkt kompiliert) auf einem anderen Rechner übereinstimmen. Beides lässt sich prüfen.

Zitat von H.Brill

Früher hat man mal gelernt, daß jede Anwendung in ihrem
eigenen Adressraum läuft

Genaus deeswegen dürften weitere installierte Programme nicht dazu führen, das nur XProfan abstürzt - erst recht nicht dazu, dass die ganze Sache nach einer Neukompilierung läuft - es sei denn, es liegt ein Fehler in der XProfan EXE, im RAM oder im Code der XProfan EXE vor. Ich tippe auf Möglichkeit 3 und als Verursacher auf die Runtime.

Da war wieder so ein Fall: Integrierten Adware-Killer im Windows Defender aktivieren!

Hm, mir ist dergleichen noch nie passiert. Zumindest nicht bei XProfan-Programmen, bei anderen hatte ich schon solche Effekte. Aber ich werde mal genauer schauen was mein Code vor dem Start anstellt. Im Debugger wurde zumindest keine Schutzverletzung oder dergleichen angezeigt.

Seltsam finde ich, dass nach dem Neucompilieren mit der selben XProfan-Version sich das Verhalten ändert, da die dann entstehende EXE Byte für Byte identisch mit der ist, die zuvor nicht gestartet ist, also auch die integrierte Runtime.

Gruß
Roland

Was sagt nach der Neukompilierung denn die Prüfsumme? Bei mir ändert sich die, wenn ich das richtig sehe.
Was ist mit der Codierung des Quelltextes? Beim Start wird der doch decodiert?

Das Verhalten tritt extrem selten auf und liegt nicht am Quellcode. Ich hatte das auch beim Mediyes Test - da ist kaum Quellcode drin.

Wenn ein bestimmtes Programm mal läuft und dann mal wieder nicht, kann es auch ein Fehler im Programmcode des Programms sein, besonders, wenn mit Bereichen und Speicheradresse gearbeitet wird. Ein Byte an eine nicht reservierte Adresse geschrieben, kann in vielen Fällen gut gehen, wenn diese Adresse zufällig nicht von einem anderen Programm beansprucht wird, führt aber zu einer Schutzverletzung wenn dem nicht so ist.

Gruß Roland

Zitat von AHT

Was sagt nach der Neukompilierung denn die Prüfsumme? Bei mir ändert sich die, wenn ich das richtig sehe.
Was ist mit der Codierung des Quelltextes? Beim Start wird der doch decodiert

Ja, das ist richtig. Es gibt da tatsächlich diese wenigen Bytes in der EXE, die sich nach jedem Kompilieren unterscheiden können und natürlich die Prüfsumme verändern. Diese dürften aber keinerlei Einfluss auf die Programmausführung haben, da sie nur beim Programmstart für die Decodierung gebraucht werden, bevor die Runtime den nun decodierten Bytecode ausführt. Ich werde mir diese Decodierungs-Routine dann noch mal genauer ansehen.

Wenn man ein Programm aber mit $P- kompiliert, also ohne jede Verschlüsselung, sollte die Prüfsumme jedes Mal gleich sein. (Sollte ein Programm Units verwenden, wird das $P- allerdings ignoriert.)

Gruß
Roland

Zitat von RGH

Ein Byte an eine nicht reservierte Adresse geschrieben, kann in vielen Fällen gut gehen, wenn diese Adresse zufällig nicht von einem anderen Programm beansprucht wird,

Das steht oben schon von mir. Da der Fehler sich bei unterschiedlichen Programmen immer genau gleich äußert, gehe ich im Augenblick eher von einem Fehler in der Sprache aus, nicht von einem Fehler im Compilat durch einen Fehler auf der Platte zum Beispiel.
Wäre die EXE zufällig irgendwo defekt, würden XProfan Programme auch an anderen Stellen abstürzen.

Zitat von RGH

Wenn man ein Programm aber mit $P- kompiliert, also ohne jede Verschlüsselung, sollte die Prüfsumme jedes Mal gleich sein. (Sollte ein Programm Units verwenden, wird das $P- allerdings ignoriert.)

Davon gehe ich auch aus. Leider kann ich das nicht zum Testen nehmen, da der Fehler extrem selten auftritt und nach einem Reboot auch nicht mehr zwingend auftreten muss.