shlwapi.dll
-
Hi Pieplz! Ich hab da so'n Problem. Folgendes: Ich habe die shlwapi.lib statisch eingebunden und habe an einer Stelle den folgenden Code:
BOOL CMidiFile::LoadFromResource(LPCTSTR res_name, LPCTSTR str_id) { // str_id is a string id. Choose one per song. LPTSTR fn; DWORD buf_len = GetTempPath(0, NULL); fn = new TCHAR[buf_len + lstrlen(str_id) + 1]; GetTempPath(buf_len, fn); lstrcpy(fn + lstrlen(fn), str_id); if( !PathFileExists(fn) ) { ...
Es gibt da jemanden, bei dem dieser Code eine Exception (in der shlwapi.dll) ausloest. Bei mir (und bei anderen auch) klappt alles ganz wunderbar. Kann sich jemand von euch vorstellen, was das Problem sein koennte?
-
In der Doku steht nichts davon, dass Du einen NULL Zeiger übergeben darfts.
An welcher Stelle schmiert das deen ab? Ich meine genau...
-
Na, bei PathFileExists(fn) natürlich. Ist ja die einzige Funktion aus der shlwapi.dll, die hier benutzt wird, und die Access Violation findet ja in dieser DLL statt. Das mit dem NULL-Zeiger ist nicht das Problem. In einer früheren Version war der String konstant (es gab also keine Abfrage auf die Länge), und es gab auch eine Access Violation. Allerdings in einem anderen Speicherbereich. Näheres steht auch in diesem Thread: http://www.c-plusplus.net/forum/viewtopic-var-t-is-177553.html. Speziell der Link im vierten Beitrag zeigt die Access-Violation-Meldung.
-
schick ihm doch mal ne exe wo du nur PathFileExists mit nem festen pfad aufrufst und sonst nichts
-
Wenn das mal keine schlechte Idee ist... thx
-
Vielleicht liegt es auch an dem String, der von GetTempPath() zurückgegeben wird. Meiner sieht so aus:
C:\DOKUME1\WEBFRI1\LOKALE~1\Temp\
Ich meine, wie er die Ordnernamen darstellt. Vielleicht kommen Optimizers Einstellungen damit nicht zurecht...
-
Hm...also vllt liegt es daran, dass er Vista hat (sieht zum mindestens auf dem Screenshot so aus)...vllt vergleicht ihr mal die Versionen der DLL's (
Rechtsklick auf die DLL, dann auf das Register 'Version' klicken
).
Hab Dein Programm auch mal getestet und bei muss sagen: Echt gut gemacht! Allerdings hat sich das Programm beim klicken auf 'Ja' im Dialog, ob man nochmal spielen möchte (nachdem man das Spiel verloren/beendet hat, siehe auch der Screenshot von Optimizer) komplett aufgehangen. Es ging nix mehr. Musste dann mit dem Task-Manager das Spiel aus dem Speicher kratzen...wobei
das Spiel lief weiter, ich könnte nur keine Eingaben mehr machen bzw. das Spiel beenden (also auf 'natürlichem Wege'). Kann Dir leider keine weiteren Infos geben, weil ich selbst keine habe...alles etwas diffus
.
-
CodeFinder schrieb:
Hm...also vllt liegt es daran, dass er Vista hat (sieht zum mindestens auf dem Screenshot so aus)...vllt vergleicht ihr mal die Versionen der DLL's (
Rechtsklick auf die DLL, dann auf das Register 'Version' klicken
).
Was wäre denn, wenn die DLLs verschiedene Versionen hätten? Sollte doch alles abwärtskompatibel sein...
CodeFinder schrieb:
Hab Dein Programm auch mal getestet und bei muss sagen: Echt gut gemacht!
Danke.
CodeFinder schrieb:
Allerdings hat sich das Programm beim klicken auf 'Ja' im Dialog, ob man nochmal spielen möchte (nachdem man das Spiel verloren/beendet hat, siehe auch der Screenshot von Optimizer) komplett aufgehangen. Es ging nix mehr.
Danke für's Testen. Leider tun sich scheinbar immer wieder neue Probleme auf. Bei mir funzt es gut. Was meinst du denn mit "es ging nix mehr"? Meinst du damit, du konntest einfach nicht mehr mit dem Spiel interagieren? "Nur" das?
-
WebFritzi schrieb:
Was wäre denn, wenn die DLLs verschiedene Versionen hätten? Sollte doch alles abwärtskompatibel sein...
Joar...*sollte*
. Hatte auch mal ein Problem mit GDI-Funktionen, das war auch sehr seltsam.
WebFritzi schrieb:
Meinst du damit, du konntest einfach nicht mehr mit dem Spiel interagieren? "Nur" das?
Ähm jo. Also das Programm lief, die Steine fielen, die Musik spielte, aber ich konnte nix mehr machen... . Außerdem wurden die Tastatureinstellungen nicht zurückgesetzt.
-
CodeFinder schrieb:
das Programm lief, die Steine fielen, die Musik spielte, aber ich konnte nix mehr machen...
LOL, scheiße.
Ich werd mal sehen, was da der Fehler sein könnte.
-
Seehr merkwürdig...habs grad nochmal versucht...da gings
. Hm naja glaube sowas gehört zum Programmieren dazu
. Immer etwas mysteriös *g*.
-
Hörst du denn das gemeine Lachen, wenn du verloren hast und die MessageBox kommt? Und fängt die Mukke wieder von neuem an zu plärren, wenn du auf "Ja" klickst?
-
Jupp
. Alles einwandfrei!
-
Komisch. Na, vielleicht komme ich der Sache später noch auf die Spur. Erstmal danke für's Ausprobieren, CodeFinder.
-
Jupp, kein Problem
.
-
Nimm doch statt "PathFileExists ()" "GetFileAttributes ()". So arbeitet "PathFileExists ()" intern.
Dann brauchst Du die "SHLWAPI.DLL" nicht mehr.
-
Hmmm, ich schau's mir mal an. Woher willst du eigentlich wissen, wie PathFileExists() intern arbeitet?
-
Ich habe nachgeguckt.
Prüf mal was passiert wenn "DWORD buf_len = GetTempPath(0, NULL);" null zurückgibt.
-
merker schrieb:
Ich habe nachgeguckt.
Hö ja, und wo bitte?
merker schrieb:
Prüf mal was passiert wenn "DWORD buf_len = GetTempPath(0, NULL);" null zurückgibt.
Das kann ich nicht, da GetTempPath() stets die Länge des temporären Verzeichnisses zurückgibt, und die ist meist nicht null.
-
WebFritzi schrieb:
Hö ja, und wo bitte?
Steht so im Arbeitsspeicher.
Ich benutze einen "API-Hook-Detektor" auf User-Ebene, der kontrolliert, ob der Code bei der Einsprungadresse einer API-Funktion der gleiche ist wie in der DLL.
Dazu muss man den Code im Arbeitsspeicher mit dem Code der DLL vergleichen. Und SHLWAPI.PathFileExistsA ruft KERNEL32.GetFileAttributesA auf.Dein Programm läuft bei mir problemlos. Aber damit ist wohl nicht geholfen.
Wenn "DWORD buf_len = GetTempPath(0, NULL);" null zurückgibt, lassen sich die Exceptions von Optimizer und CodeFinder simulieren (-> BufferOverflow).
Prüf auch mal folgendes Szenario :
-> Der User startet das Programm zum ersten Mal.
-> Der User hat aber kein TEMP(TMP)-Verzeichnis definiert.
-> GetTempPath () liefert dann das "Current Directory".
-> Dort gibt es aber kein Schreibrecht.