4. shlwapi.dll

shlwapi.dll

  • C

    Jupp 🙂 . Alles einwandfrei!

    0
  • W

    Komisch. Na, vielleicht komme ich der Sache später noch auf die Spur. Erstmal danke für's Ausprobieren, CodeFinder.

    0
  • C

    Jupp, kein Problem 👍 .

    0
  • ?

    Nimm doch statt "PathFileExists ()" "GetFileAttributes ()". So arbeitet "PathFileExists ()" intern.
    Dann brauchst Du die "SHLWAPI.DLL" nicht mehr.

    0
  • W

    Hmmm, ich schau's mir mal an. Woher willst du eigentlich wissen, wie PathFileExists() intern arbeitet? 😕

    0
  • ?

    Ich habe nachgeguckt.

    Prüf mal was passiert wenn "DWORD buf_len = GetTempPath(0, NULL);" null zurückgibt.

    0
  • W

    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.

    0
  • ?

    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.

    0
  • W

    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? 😕

    0
  • ?

    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.

    0
Anmelden zum Antworten