Prozesse oder Anwendungen ermitteln, die eine Datei benutzen

[daPimP]

Zitat:

Für UserMode-Prozesse sind nur die anderen Felder interessant (insbes. ProcessId/Handle).

Wie gesagt, diese Dinge sind klar. Mir fehlt jetzt noch der Schritt,
aus dem Handle 1234 des Prozesses ABC den Namen des Handles herauszubekommen.

In einer Liste so in etwa:

Code:

Type       Handle  Name

File       1234    C:\Windows\system32
File       321     \Device\KsecDD
Key        3232    HKLM\Software\...
Semaphore  1123    \BaseNamedObjects\shell.{...}
Event      123 
....

Idee? :gruebel:

[CCRDude]

NtQueryObject mit ObjectNameInformation :)

[daPimP]

Für alle die Mitlesen, hier noch ein paar Links.

Delphi Praxis

und

dateifreigabe

Zusammenfassung:
Info des Autors von Unlocker:

Zitat:

You need to first find all locks opened by a system using undocumented functions such as ZwQueryObject and NtQueryObject.

Then to get informations you need you write a device driver since some informations are only accessible at the device driver level. There is no device driver specific function, it is just that you need to run in a driver to have maximum access to the system.

von Nico zum Thema Treiber:

Zitat:

Der Treiber ist deswegen notwendig, weil die Abfrage des Namens eines Dateiobjektes (Dateien, Verzeichnisse, Pipes, MailSlots, ...) bei synchronisierten Objekten solange benötigt bis die aktuelle Operation abgeschlossen ist (und das kann ewig dauern). Da zum Beispiel der Service Control Manager (SCM) Pipes verwendet um mit Service-DLLs zu kommunizieren, gibt es eine Menge solcher Objekte. Zudem gibt es aus dem Benutzermodus keinen sicheren Weg um Dateien von Pipes und/oder MailSlots zu untercheiden. Der Treiber löst das erste Problem üblicherweise dadurch, dass er den IRP zur Abfrage des Objekts selbst erzeugt. Das zweite Problem kann ebenso im Treiber (mit Hilfe des IFS-Kits) gelöst werden (MailSlots oder Pipes sind an Flags erkennbar).

Kurz, für eine saubere Lösung kommt man nicht um einen Treiber herum.

und

Ironie des Schicksals, nachdem ich immer wieder ein kleines Stück der Lösung näher gerutscht war
und es nun auch geschafft hatte (Danke CCRDude), gibts das schon relativ kompakt im Netz.
Nicht so toll wie meine Lösung :zwinker: , aber dafür OHNE Treiber.

für die Copy&Paste 'ler der Delphi Source.
experts exchange

[toms]

Zitat:

Zitat von daPimP

für die Copy&Paste 'ler der Delphi Source.
experts exchange

Und für alle, die kein experts-exchange login haben: Habe den Code als Attachment angehängt.

[NicoDE]

Randbemerkung: "SysErrorMessage(GetLastError())" ist nicht korrekt, richtig wäre "SysErrorMessage(RtlNtStatusToDosError(Status) )" gewesen.

Zitat:

Zitat von daPimP

aber dafür OHNE Treiber.

Viel Spaß beim Testen auf Live-Systemen...

[daPimP]

@Nicode: Ja da hast du verdammt recht. Aber als Basis ist das durchaus nutzvoller Quellcode.
Bei meinen Proben war die Chance, das das Programm nicht hängt 1:10. :cheers: Mahlzeit.

[Luckie]

@toms: Wie benutzt man den Code? Also wie würde ein Beispielaufruf aussehen?

[QuickAndDirty]

Zitat:

Zitat von NicoDE

Randbemerkung: "SysErrorMessage(GetLastError())" ist nicht korrekt, richtig wäre "SysErrorMessage(RtlNtStatusToDosError(Status) )" gewesen.

Zitat:

Zitat von daPimP

aber dafür OHNE Treiber.

Viel Spaß beim Testen auf Live-Systemen...

Meinst es würde helfen, wenn OpLocks abgeschaltet sind?