shlwapi.dll
-
merker schrieb:
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.Aha. Wieder was dazugelernt.
merker schrieb:
Wenn "DWORD buf_len = GetTempPath(0, NULL);" null zurückgibt, lassen sich die Exceptions von Optimizer und CodeFinder simulieren (-> BufferOverflow).
Ich hatte vorher aber einen konstanten anstatt einem dynamischen Array, wo ich die Funktion GetTempPath() nur einmal aufgerufen habe, und auch da gab es eine Access-Violation. Das kann also nicht der Fehler sein...
merker schrieb:
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.Warum sollte ich das testen?
-
WebFritzi schrieb:
Warum sollte ich das testen?
Damit u.a. fehlende Rechte als Fehlerursache ausgeschlossen werden können.
WebFritzi schrieb:
...auch da gab es eine Access-Violation. Das kann also nicht der Fehler sein...
***achtung vermutung folgt***
Offenbar benimmt sich SHLWAPI.DLL in manchen Installationen genauso "mimosenhaft" wie COMCTL32.DLL.
Allerdings gibt es dort die Funktion InitCommonControls ().
Probier so eine Funktion mal zu simulieren :
Ruf nur PathFileExists () irgendwo im Programm auf noch bevor der User auf "game->new" klickt und alles auslöst was mit diesem Klick verbunden ist.