Was hat M$ beim letzten Update geändert? - Kein Dateizugriff?

Haengt es denn immer an dieser einen Bilddatei? @MarkP
Hast Du die schon einfach mal gegen eine andere ausgetauscht?

BFF
 
BFF schrieb:
Haengt es denn immer an dieser einen Bilddatei? @MarkP
Hast Du die schon einfach mal gegen eine andere ausgetauscht?

BFF

DAS ist eine gute Frage, ich weiss nicht mal wie ich die nu beantworten soll.
Ohne mein Programm zu überarbeiten müssen die Dateinamen erhalten bleiben und auch die Dateigrösse muss passen, weil sonst mein Programm streikt, ergo, wenn ich eine andere Datei gleicher Grösse nehme und der denselben Namen gebe, dann geht das auch nicht, aber ich weiss halt nicht, ob das am Dateinamen liegt, oder an der Dateigrösse, oder woran sonst.
Genauer kann ich es in ein paar Tagen sagen, wenn ich beim Überarbeiten an der Stelle bin wo die Grafiken geladen werden.
 
Interessant wäre das auch mal in ProcessMonitor nachzuverfolgen.
 
Ich bin der Lösung einen kleinen Schritt näher gekommen, wirklich nur einen kleinen Schritt, aber vielleicht reicht das ja um hier wen zu finden, der damit etwas anfangen kann.
Ich habe ALLE Grafiken die das Programm laden soll durch neue Grafiken gleicher Grösse und mit gleichem Dateinamen ersetzt, also auch die 9 die er laden kann, aber das hat auch nichts genutzt.
Dann habe ich im Code die Nr. 4 beim Laden übersprungen und mir die Augen gerieben, denn aus mir unverständlichem Grund hat das Programm die alten Grafiken geladen, also die, die eigentlich gar nicht mehr da sein dürften.
Erste Idee, klar, irgendein Cache, also Temp-Verzeichnis geleert, Datenträgerbereinigung durchgezogen, dann wieder probiert und er läd IMMER NOCH die alten Grafiken.
PC neu gestartet, nochmal Datenträgerbereinigung, hilft nicht, er läd immer wieder die alten Grafiken.

Meine Idee dazu ist nun, dass Windows die Grafiken aus dem Unterordner/source irgendwoanders hin kopiert hat und sie nun von dort läd, es dort aber die Nr. 4 nicht gibt, weil beim Kopieren ein Fehler passiert ist oder so.
Ich weiss aber nicht wo das sein soll und eine Suche auf der gesamten Festplatte findet keine zweite Kopie der Dateien.

Edit: Hat sich erledigt, war auch ne Sackgasse, nach zweitem PC-Neustart läd er nu die neuen Dateien, war also wohl doch irgendein Cache, aber die Nr.4 läd er immer noch nicht.
 
Zuletzt bearbeitet:
MarkP schrieb:
dass Windows die Grafiken aus dem Unterordner/source irgendwoanders hin kopiert hat und sie nun von dort läd, es dort aber die Nr. 4 nicht gibt, weil beim Kopieren ein Fehler passiert ist oder so.

Das ist nicht Windows. Das ist Dein Programm.
Du solltest doch eigentlich wissen was Dein Programm macht und wohin es beim "Entpacken" der Bilder aus dem Programm diese legt. Du kannst doch bestimmt in C++ festlegen wohin das gemacht wird. Dann hast Du die Kontrolle darueber und kannst besser nachverfolgen wer da eventuell reingraetscht wenn Du diesen Ordner ueberwachst.

Wenn es immer nur die Nummer 4 ist, schau den Code peinlichst genau an, bau einen timeOut ein und/oder aendere die Reihenfolge.
 
Ja ich weiss, habs ja auch gemerkt.
Am Code kann ja im Prinzip nichts falsch sein, sonst hätte das nicht 15 Jahre lange problemlos funktioniert.
Das ist auch kein irgendwie komplizierter Code, da steht ganz simpel:

HBITMAP MyBitmap1 = (HBITMAP)LoadImage(0,"./source/graphics1.bmp",IMAGE_BITMAP,0,0,LR_LOADFROMFILE);
if(!MyBitmap1){return 1;}
HBITMAP MyBitmap2 = (HBITMAP)LoadImage(0,"./source/graphics2.bmp",IMAGE_BITMAP,0,0,LR_LOADFROMFILE);
if(!MyBitmap2){return 1;}
usw.
return 0;

Kommt die Funktion mit einer 1 zurück, dann gibt er die Fehlermeldung aus.

Wie das aussieht wenn ich die Reihenfolge ändere muss ich noch rausfinden, so weit bin ich beim Überarbeiten noch nicht.
 
Mach doch mal zum Test zwischen jedem Laden einen TimeOut mit 1 Sekunde.

Und lass den Debugger mitlaufen.
 
Ja, sobald ich an der Stelle angekommen bin, werde ich natürlich so lange rumprobieren bis es geht.
Bleibt zu hoffen, dass ich im Verlauf davon dann rausfinde was eigentlich das Problem ist.
Ich melde mich dann, falls es beim Überarbeiten ohne Zwischenfälle geht vermutlich übermorgen.
 
So dala, ich habe das Programm überarbeitet und tatsächlich den Fehler gefunden, nur kann ich mit noch so viel Phantasie nicht erklären was da das Problem sein soll.
Wie gesagt, bis vor dem letzten Windows Update ging alles ohne Probleme und geht auch heute noch ohne Probleme.
Nach dem letzten Windows Update musste ich die Datei graphics4.bmp einmal in MS-Paint laden, via "speichern unter" an einem anderen Ort neu speichern und dann diese Kopie über die alte Datei drüber kopieren, danach geht alles wieder wie gehabt.

Und jetzt die Windows-Experten vor, denn es interessiert mich wirklich:
Wieso kann mein Programm nach dem letzten Update plötzlich eine von 10 Dateien nicht mehr laden, während MS-Paint auch nach dem Update alle 10 Dateien ohne Probleme laden kann und wieso kann mein Programm die völlig unveränderte Datei plötzlich wieder laden, nur weil sie neu gespeichert wurde?
Ich habe beide Dateien in einem Hex-Editor verglichen, die sind abgesehen vom Erstellungsdatum identisch.
 
Sind denn die Hashwerte identisch? Zugriffsrechte?
 
Also liegt die Datei nicht an der gleichen Stelle auf dem Datentraeger und hat u.U. kein "fehlerhaftes" Bit mehr.
Ich wuerde uebrigens die Hashwerte vergleichen und nicht unbedingt die Zeichen im Editor.

BFF
 
Das Programm benötigt kein spezielles Installationsverzeichnis.
Ich hatte vorher schon das ganze Programm mehrfach irgendwo anders hin kopiert, aber das hat nichts genutzt, erst die Kopie der Grafik brachte die Lösung.
"Fehlerhaftes Bit" ist mir auch nicht wirklich ersichtlich, denn wenn die alte Datei beschädigt ist, dann hätte mein Programm sie vorm letzten Windows Update auch schon nicht laden können.
Es ist aber tatsächlich so, dass ältere Versionen von Win10 auch die alte Datei heute noch problemlos laden können.
 
Zuletzt bearbeitet:
Dein Programm verwendet doch sicher irgendeine Windows-Bibliothek dafür, oder parst du die Datei selbst?
 
Defekte Bilder lassen sich im gewissen Rahmen sehr wohl laden.
Und das ein Update sowas nun "verhindert" halte ich auch fuer moeglich.
Die Frage ist halt, lag es wirklich daran.

Irgendwas an der Datei wird es gewesen sein, wenn es die Neue jetzt tut.
Ob das jemals abschliessen geklaert werden koennte weiss nur MS.
 
Die Funktion kommt von der User32.dll und die wurde am Patchday mitgepatch, siehe Post #2.
 
Na ok, am Ende bin ich einfach froh, dass es wieder läuft.
Die Überarbeitung vom Programm hat sich als unnötig rausgestellt, kann aber auch nicht schaden das Ganze auf aktuellem Stand zu haben.
In jedem Fall einen herzlichen Dank an alle für die rege Beteiligung.

Edit: Weils mir gerade erst aufgefallen ist, Beitrag #13 hatte die Lösung, aber die habe ich anscheinend glatt übersehen, zumindest hatte ich das bis heute nicht gemacht. (Ich schäm mich auch)
 
Zuletzt bearbeitet:
MarkP schrieb:
Edit: Weils mir gerade erst aufgefallen ist, Beitrag #13 hatte die Lösung, aber die habe ich anscheinend glatt übersehen, zumindest hatte ich das bis heute nicht gemacht. (Ich schäm mich auch)
Aha! Ok, wie wärs Du postest mal das alte und neue graphics4.bmp in einem Zip als Anhang? Dann kann man mal checken was jetzt genau los war ..
 
Aber gerne, vielleicht findest du ja was raus was mich oder wen Anders in der Zukunft vor solchen Überraschungen bewahrt.
 

Anhänge

Die Bildinformationen sind identisch, nur der Header ist anders. Die alte Datei verwendet den alten BITMAPCOREHEADER und die neue den neueren BITMAPINFOHEADER, aber mit den selben Informationen. Jetzt müsste man mal gucken, welchen Header die anderen Dateien, die immer noch funktionieren, verwenden.
 
  • Gefällt mir
Reaktionen: BFF
Zurück
Oben