CTL_CODE Funktion in Delphi

[peanut]

Hallo,

hat jemand zufälligerweise ein DDK installiert und kann mir kurz den Wert IOCTL_PROCVIEW_GET_PROCINFO berechnen:

#define FILE_DEVICE_UNKNOWN 0x00000022
#define IOCTL_PROCVIEW_GET_PROCINFO CTL_CODE(FILE_DEVICE_UNKNOWN, 0x0800, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)

ich habe zwar ne Delphi CTL_CODE-Variante im Internet gefunden

Delphi-Quellcode:

function CTL_CODE(DeviceType, _Function, Method, Access: Cardinal): Cardinal;
begin
  Result := (DeviceType shl 16) or (Access Shl 14) or (_Function shl 2) or (Method);
end;

aber anscheinend ist die nicht richtig oder ich vermurkse sonst noch etwas bei der Kommunikation mit dem Treiber...

Noch eine Frage: Ist BOOLEAN in C++ äquivalent zu Boolean in Delphi?

Danke im Voraus!!!

Viele Grüße

peanut.

[Der_Unwissende]

Zitat von peanut:

Noch eine Frage: Ist BOOLEAN in C++ äquivalent zu Boolean in Delphi?

Hi,
ich denke dass ist nicht der Fall. Ich kann mich da natürlich auch irren, aber Boolean in Delphi ist imho nur 1 Byte groß. In C++ verwendet man hingegen einen 4 Byte Wert (LongBool in Delphi). Das hat Perfomancegründe.
Was du sonst unter äquivalent verstehst ist halt so eine Sache. Selbst für C gilt schon, dass die Wert 1,2,3,4,... und -1,-2,.. alle äquivalent sind, was den Wahrheitswert angeht. Es wird nur 0 und nicht 0 unterschieden, ein direkter Vergleich ob zwei Werte gleich sind ist also eine nicht sinnvolle Aussage (wenn es um Wahrheitswerte geht), ob beide ungleich null sind wäre hingegen eine sinnvolle Aussage.

Gruß Der Unwissende

[OregonGhost]

In C++ gibt es nur den Typ bool. Ich weiß nicht, inwieweit der Ähnlichkeiten mit dem Delphi-Boolean hat. BOOLEAN hingegen ist eine Definition der Windows-API und sie müsste kompatibel zu Delphis LongBool sein.

[Christian Seehase]

Moin Peanut,

also ich erhalte da $0022E000 als Ergebnis.
Die Werte kannst Du übrigens aus der WinIoCtl.h aus dem PSDK erhalten.

Die Funktion sieht auch gut aus.

Woher hast Du eigentlich IOCTL_PROCVIEW_GET_PROCINFO ?
Das kann ich auch im DDK (Windows 2003) nicht entdecken.

[peanut]

Hallo,

um die Situation zu klären: Ich verwende einen Treiber von Ivo Ivanov (CodeProject: http://www.codeproject.com/threads/procmon.asp). Dieser sollte einem beim Erstellen und Beenden eines Prozesses über einen Event bescheid geben.

Ich möchte dann mittels

DeviceIoControl() und GetOverlappedResult()

die von ihm definierte Datenstruktur

typedef struct _CallbackInfo
{
HANDLE hParentId;
HANDLE hProcessId;
BOOLEAN bCreate; // (*)
}CALLBACK_INFO, *PCALLBACK_INFO;

auslesen. Leider scheitert bei mir folgender Aufruf

DeviceIoControl(m_hDriver, IOCTL_PROCVIEW_GET_PROCINFO, nil, 0, @CallbackInfo^, SizeOf(TCallbackInfo), dwBytesReturned, @ov) Ich denke, dass es vielleicht an meiner TCallbackInfo-Datenstruktur liegt:

Delphi-Quellcode:

 TCallbackInfo = record
    ParentId : THANDLE;
    ProcessId: THANDLE;
    bCreate  : LongBool;
 end;
 PCallbackInfo = ^TCallbackInfo;

Nun wollte ich wissen, welches Delphi-Boolean nun dem BOOLEAN Typ aus C++ entspricht, siehe (*), denn THandle = HANDLE => das kann demnach nicht falsch sein. Auch das Initialisieren des Treibers und Warten bis ein Event gefeuert wird funktioniert, nur der Aufruf mittels DeviceIoControl scheitert.

Zitat:

Christian Seehase schrieb:

also ich erhalte da $0022E000 als Ergebnis.
...
Woher hast Du eigentlich IOCTL_PROCVIEW_GET_PROCINFO ?
Das kann ich auch im DDK (Windows 2003) nicht entdecken.

Danke, auch ich erhalte $0022E000 als Ergebnis, daran kann es also nicht liegen, dass ich Probleme beim Lesen vom Treiber habe...

Was die CTL_CODE Funktion betrifft. Ivo hat mit IOCTL_PROCVIEW_GET_PROCINFO wohl einen eigenen IoControlCode eingeführt, keine Ahung wieso? Definiert hatte er ihn aber wie folgt:

#define FILE_DEVICE_UNKNOWN 0x00000022
#define IOCTL_UNKNOWN_BASE FILE_DEVICE_UNKNOWN
#define IOCTL_NTPROCDRV_GET_PROCINFO CTL_CODE(IOCTL_UNKNOWN_BASE, 0x0800, METHOD_BUFFERED, FILE_READ_ACCESS | FILE_WRITE_ACCESS)

somit müsste doch IOCTL_NTPROCDRV_GET_PROCINFO auch ein FILE_DEVICE_UNKNOWN sein oder???

Viele Grüße

peanut.

[Christian Seehase]

Moin Peanut,

in der Winnt.h ist BOOLEAN als BYTE deklariert, dürfte also im Wesentlichen dem Delphi-Boolean entsprechen.
Probier auch mal die Struktur als Packed zu deklarieren.

Klingt alles interessant.
Vielleicht komme ich morgen mal dazu mir den Artikel durchzulesen, und die Sourcen anzusehen.

[Robert Marquardt]

BOOLEAN ist als Byte deklariert, waehrend BOOL als DWORD deklariert ist. Die Entsprechung ist daher ByteBool fuer BOOLEAN bzw LongBool fuer BOOL.
Records in DDK-C-Headern sind gerne auf 1-Byte-Grenze gepackt.
Das CTL_CODE Makro sollte man nicht in eine Funktion ueberfuehren, denn dann hat man keine Konstante die der Compiler direkt handhaben kann.

[peanut]

Hallo!

Vielen Dank für die Informationen. Ich habe die Datenstruktur nun als packed deklariert und den Booleanwert geändert. Statt des CTL_CODE Makros habe ich direkt eine Konstante mit dem entsprechenden Wert definiert.

UND...... es hat funktioniert!!!

Nochmals DANKE! Wenn Interesse besteht, kann ich den Sourcecode hier rein posten. Es ist interessant, wenn man weiß, welcher Prozess wann gestartet und beendet wird.

Viele Grüße

peanut.

[Olli]

Zitat von peanut:

Es ist interessant, wenn man weiß, welcher Prozess wann gestartet und beendet wird.

Interessant ja, aber der Mechanismus ist eigentlich für "andere Kundschaft" gedacht als für den Enduser. Wenn man bedenkt, daß es nur 8 Slots gibt, um als Treiber eine Callback zu registrieren, versteht man das sicher

[peanut]

Zitat:

Interessant ja, aber der Mechanismus ist eigentlich für "andere Kundschaft" gedacht als für den Enduser. Wenn man bedenkt, daß es nur 8 Slots gibt ...

Werden wirklich alle 8 Slots gebraucht? Ich könnte mir da nur einen Virenscanner, IDS und vielleicht noch ne Firewall mit Application-Gateway als "üblich Verdächtige" vorstellen, dann ist aber noch immer 1 Platz für meine kleine Überwachungsanwendung frei.

Nachdem ich in letzter Zeit von einem Fettnäpfchen ins nächste tappe: Kann mir jemand ein Buch empfehlen, das einem einen guten Überblick über die tiefere System-API gibt inkl. Verweise was sich gehört und was man aus Effizienz- oder anderen Gründen lieber sein lässt. DANKE