Fehlermeldung eines Bildverkleinerungs-Programmes

[Alfiator]

Deswegen hab ich ja auch gefragt..

 

[Alfiator]

Da biste ja völlig falsch...

 

[Frank-2]

Nachdem ich das nun einmal als Admin gestartet und getestet hatte (ohne drag&drop) geht die gelöste Variante über C als Ausgabeziel auch nicht mehr. Jetzt steht der ganze Thread wieder am Anfang und als ungelöst.

 

[Alfiator]

Kommt wieder die selbe Fehlermeldung?

 

[Frank-2]

Ja, die selbe. Oh Wunder eben ausprobiert: jetzt funktioniert plötzlich Verwenden des Quellordners als Ziel mit Überschreiben der alten Datei reibungslos, so wie es sein sollte - quasi alles i.O. Am Ende aber eine MicroSoftfehlermeldung: Fehlermodulname: StackHash_d97b

 

[Alfiator]

Rein aus Interesse mal ein Bild der Fehlermeldung..

 

[Frank-2]

Das dürfte weiterhelfen bei der Problemlösung. Bild 3 Meldung nach Online Fehlersuche.

 

[Alfiator]

 

[automatthias]

Ist Dein Windows7 eine 64bit-Version?
Hast Du schon mal den Kompatibilitätsmodus versucht?

 

[Alfiator]

Manchmal bietet Windows das sogar von selber an, aber das wäre auch noch eine Möglichkeit...

 

[Frank-2]

Das ändert nix. Ausprobiert.

 

[Alfiator]

Tja, sieht so aus, das man manchmal in den sauren Apfel beißen muss...

 

[Frank-2]

Komisch ist aber auch, dass es, wie hier, 5 umwandelt und dann erst der Fehler kommt.

 

[Alfiator]

Die Fehlermeldung ist schon irgendwie seltsam; vor allem, das sich das Verhalten nach Neustart ändert....

 

[Frank-2]

Das Programm arbeitet ansich ja schon. Als Zwischenspeicher wird die umgewandelte Datei als ##TMPCompress## bereits geschrieben. Der eigentliche Fehler tritt dann auf, diese mit dem Namen der Originaldatei zu versehen (und somit die alte Datei verschwinden zu lassen). Nach der Fehlermeldung kann man diese Compress-Datei auch als Bild nutzen, muß dann aber den Namen kopieren, die alte Datei löschen und dort einfügen.

 

[automatthias]

Ich habe mal ein wenig analysiert. Die o.g. Fehlermeldung stammt nicht aus dem Programm selber, sondern muss aus irgend eine Windowslibrary kommen (was man auch an der hölzernen Sprache merkt).
Meine Vermutung: MS hat zwischen XP und W7 Änderungen an der API (WIndows Programmierschnittstelle) durchgeführt. So was kenne ich aus der Zeit, als ich noch selber Windows-Systemprogrammierung betrieben habe. Da wurde dann schon mal bei einer Funktion ein Parameter hinzugefügt oder weggenommen odgl.
Mit entsprechend eingeschränkter Kompatibilität.
Ich interpretiere die Fehlermeldung so, dass die Datei nicht umbenannt werden kann, weil sie noch als "geöffnet" markiert ist. Unter Windows XP war die Datei entweder automatisch "geschlossen", oder es war ein Bug und wurde ignoriert, und unter W7 wird das anders behandelt. Oder es gab Änderungen in der Dateisystemverarbeitung (NTFS), die da ein anderes Verhalten hervorrufen. Das könnte man testen, indem man das Programm auf einem FAT Dateisystem laufen lässt.
Schließlich könnte es auch ein Zeitverhalten sein. Es sieht so aus, als ob immer derselbe Name für die temporäre Datei verwendet wird. In dem Fall könnte es sein, dass in einer Multi-Threaded-Umgebung schon die nächste Datei bearbeitet werden soll, während die erste noch nicht fertig ist. Das könnte erklären, warum es manchmal funktioniert.

@Frank-2 : wie sehen bei dir die Einstellungen in diesem Fenster aus:

 

[Frank-2]

Gute Analyse!

 

[automatthias]

Dann versuch mal, eine Vorspann im Namen einzusetzen, damit Quelle und Ziel NICHT gleich sind, oder verwende das Ausgabeverzeichnis, aber NICHT dasselbe Zielverzeichnis wie die Quelle

 

[Frank-2]

Dann habe ich ja den ganzen Aufwand mit der Umbenennung hinterher. Das macht dann mehr Arbeit als immer wieder neu zu starten um weiterumzuwandeln.

 

[automatthias]

Dann nimm wenigstens ein anderes Ausgabeverzeichnis, nicht Quelle und Ziel im selben Verzeichnis