Undurchsichtige Strukturen des Windows-Kernels
In diesem Artikel werden undurchsichtige Windows-Kernelstrukturen aufgeführt und beschrieben. Für viele dieser Strukturen sollten Treiber nicht auf Mitglieder zugreifen oder ändern, sondern stattdessen vom System bereitgestellte Routinen für den Zugriff auf die Informationen verwenden. Details finden Sie in den einzelnen Strukturen.
EPROCESS
Die EPROCESS-Struktur ist eine undurchsichtige Struktur, die als Prozessobjekt für einen Prozess dient.
Einige Routinen, z. B. PsGetProcessCreateTimeQuadPart, verwenden EPROCESS, um den Prozess zu identifizieren, auf dem ausgeführt werden soll. Treiber können die PsGetCurrentProcess-Routine verwenden, um einen Zeiger auf das Prozessobjekt für den aktuellen Prozess abzurufen, und die ObReferenceObjectByHandle-Routine verwenden, um einen Zeiger auf das Prozessobjekt abzurufen, das dem angegebenen Handle zugeordnet ist. Die globale PsInitialSystemProcess-Variable verweist auf das Prozessobjekt für den Systemprozess.
Ein Prozessobjekt ist ein Object Manager-Objekt. Treiber sollten Objekt-Manager-Routinen wie ObReferenceObject und ObDereferenceObject verwenden, um die Referenzanzahl des Objekts beizubehalten.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
ETHREAD
Die ETHREAD-Struktur ist eine undurchsichtige Struktur, die als Threadobjekt für einen Thread dient.
Einige Routinen, z. B. PsIsSystemThread, verwenden ETHREAD, um den Thread zu identifizieren, auf dem der Thread ausgeführt werden soll. Treiber können die PsGetCurrentThread-Routine verwenden, um einen Zeiger auf das Threadobjekt für den aktuellen Thread abzurufen, und die ObReferenceObjectByHandle-Routine verwenden, um einen Zeiger auf das Threadobjekt abzurufen, das dem angegebenen Handle zugeordnet ist.
Ein Threadobjekt ist ein Object Manager-Objekt. Treiber sollten Objekt-Manager-Routinen wie ObReferenceObject und ObDereferenceObject verwenden, um die Referenzanzahl des Objekts beizubehalten.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
EX_RUNDOWN_REF
Die EX_RUNDOWN_REF-Struktur ist eine undurchsichtige Systemstruktur, die Informationen zum Status des Abwärtsschutzes für ein zugeordnetes freigegebenes Objekt enthält.
typedef struct _EX_RUNDOWN_REF {
... // opaque
} EX_RUNDOWN_REF, *PEX_RUNDOWN_REF;
Die unten auf dieser Seite aufgeführten Run-down-Schutzroutinen weisen einen Zeiger auf eine EX_RUNDOWN_REF Struktur als ersten Parameter auf.
Weitere Informationen finden Sie unter Run-Down Protection. Kopfzeile: Wdm.h. Einschließen von Wdm.h.
EX_TIMER
Die EX_TIMER-Struktur ist eine undurchsichtige Struktur, die vom Betriebssystem verwendet wird, um ein EX_TIMER Timerobjekt darzustellen.
typedef struct _EX_TIMER *PEX_TIMER;
Alle Member dieser Struktur sind für Treiber undurchsichtig.
Die folgenden ExXxxTimer-Routinen erfordern einen Zeiger auf eine vom System zugewiesene EX_TIMER Struktur als Eingabeparameter:
Das Betriebssystem erstellt EX_TIMER-basierte Zeitgeberobjekte. Um ein solches Timerobjekt abzurufen, ruft Ihr Treiber die ExAllocateTimer-Routine auf. Wenn dieses Objekt nicht mehr benötigt wird, ist der Treiber für das Löschen des Objekts durch Aufrufen von ExDeleteTimer verantwortlich.
Weitere Informationen finden Sie unter ExXxxTimer Routines und EX_TIMER Objects.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
FAST_MUTEX
Eine FAST_MUTEX Struktur ist eine undurchsichtige Datenstruktur, die einen schnellen Mutex darstellt. Die ExInitializeFastMutex-Routine initialisiert diese Struktur.
Weitere Informationen zu schnellen Mutexen finden Sie unter Fast Mutexes und Guarded Mutexes.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
IO_CSQ
Die IO_CSQ-Struktur ist eine undurchsichtige Struktur, die verwendet wird, um die abbruchsicheren IRP-Warteschlangenroutinen des Treibers anzugeben. Legen Sie die Elemente dieser Struktur nicht direkt fest. Verwenden Sie IoCsqInitialize oder IoCsqInitializeEx, um diese Struktur zu initialisieren.
Eine Übersicht über die Verwendung von abbruchsicheren IRP-Warteschlangen finden Sie unter Cancel-Safe IRP Queues.
Verfügbar unter Microsoft Windows XP und höheren Versionen des Windows-Betriebssystems.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
IO_CSQ_IRP_CONTEXT
Die IO_CSQ_IRP_CONTEXT-Struktur ist eine undurchsichtige Datenstruktur, die verwendet wird, um den IRP-Kontext für ein IRP in der abbruchsicheren IRP-Warteschlange des Treibers anzugeben. Die IoCsqInsertIrp-, IoCsqInsertIrpEx- und IoCsqRemoveIrp-Routinen verwenden diese Struktur als Schlüssel, um bestimmte IRPs in der Warteschlange zu identifizieren.
Eine Übersicht über die Verwendung von abbruchsicheren IRP-Warteschlangen finden Sie unter Cancel-Safe IRP Queues.
Verfügbar unter Microsoft Windows XP und höheren Versionen des Windows-Betriebssystems.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
IO_WORKITEM
Die IO_WORKITEM Struktur ist eine undurchsichtige Struktur, die eine Arbeitsaufgabe für einen Systemarbeitsthread beschreibt.
Ein Treiber kann eine Arbeitsaufgabe zuordnen, indem IoAllocateWorkItem aufgerufen wird. Alternativ kann ein Treiber einen eigenen Puffer zuweisen und dann IoInitializeWorkItem aufrufen, um diesen Puffer als Arbeitsaufgabe zu initialisieren.
Jede Arbeitsaufgabe, die IoAllocateWorkItem zuweist, muss von IoFreeWorkItem freigegeben werden. Jeder von IoInitializeWorkItem initialisierte Speicher muss von IoUninitializeWorkItem nicht initialisiert werden, bevor es freigegeben werden kann.
Weitere Informationen zu Arbeitsaufgaben finden Sie unter "System Worker Threads".
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
KBUGCHECK_CALLBACK_RECORD
Die KBUGCHECK_CALLBACK_RECORD Struktur ist eine undurchsichtige Struktur, die von den KeRegisterBugCheckCallback- und KeDeregisterBugCheckCallback-Routinen verwendet wird.
Die KBUGCHECK_CALLBACK_RECORD Struktur wird von den KeRegisterBugCheckReasonCallback- und KeDeregisterBugCheckReasonCallback-Routinen für die Buchführung verwendet.
Die Struktur muss im residenten Speicher zugewiesen werden, z. B. im nicht seitengebundenen Pool. Verwenden Sie die KeInitializeCallbackRecord-Routine , um die Struktur zu initialisieren, bevor Sie sie verwenden.
Header: Ntddk.h. Include: Ntddk.h.
KBUGCHECK_REASON_CALLBACK_RECORD
Die KBUGCHECK_REASON_CALLBACK_RECORD Struktur ist eine undurchsichtige Struktur, die von den KeRegisterBugCheckReasonCallback- und KeDeregisterBugCheckReasonCallback-Routinen verwendet wird.
Die KBUGCHECK_REASON_CALLBACK_RECORD Struktur wird von den KeRegisterBugCheckReasonCallback- und KeDeregisterBugCheckReasonCallback-Routinen für die Buchführung verwendet.
Die Struktur muss im residenten Speicher zugewiesen werden, z. B. im nicht seitengebundenen Pool. Verwenden Sie die KeInitializeCallbackRecord-Routine , um die Struktur zu initialisieren, bevor Sie sie verwenden.
Verfügbar unter Microsoft Windows XP mit Service Pack 1 (SP1), Windows Server 2003 und höheren Versionen des Windows-Betriebssystems.
Header: Ntddk.h. Include: Ntddk.h.
KDPC
Die KDPC-Struktur ist eine undurchsichtige Struktur, die ein DPC-Objekt darstellt. Legen Sie die Elemente dieser Struktur nicht direkt fest. Siehe DPC-Objekte und DPCs.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
KFLOATING_SAVE
Die KFLOATING_SAVE-Struktur ist eine undurchsichtige Struktur, die den Gleitkommazustand beschreibt, den die KeSaveFloatingPointState-Routine gespeichert hat.
Verwenden Sie KeRestoreFloatingPointState , um den Gleitkommazustand wiederherzustellen.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
KGUARDED_MUTEX
Die KGUARDED_MUTEX-Struktur ist eine undurchsichtige Struktur, die einen geschützten Mutex darstellt.
Verwenden Sie KeInitializeGuardedMutex , um eine KGUARDED_MUTEX Struktur als geschützten Mutex zu initialisieren.
Geschützte Mutexes müssen aus nicht ausgelagerten Pool zugewiesen werden.
Weitere Informationen zu geschützten Mutexen finden Sie unter Fast Mutexes und Guarded Mutexes.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
KINTERRUPT
Eine KINTERRUPT-Struktur ist eine undurchsichtige Struktur, die einen Interrupt für das System darstellt.
IoConnectInterruptEx stellt einen Zeiger auf die KINTERRUPT-Struktur für den Interrupt bereit, wenn der Treiber eine InterruptService - oder InterruptMessageService-Routine registriert. Der Treiber verwendet diesen Zeiger beim Abrufen oder Freigeben der Unterbrechungsdrehsperre für den Interrupt. Der Treiber verwendet diesen Zeiger auch, wenn die Registrierung einer InterruptService-Routine aufgehoben wird.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
KLOCK_QUEUE_HANDLE
Die KLOCK_QUEUE_HANDLE Struktur ist eine undurchsichtige Struktur, die eine in die Warteschlange eingereihte Drehsperre beschreibt. Der Treiber weist die KLOCK_QUEUE_HANDLE Struktur zu und übergibt sie an KeAcquireInStackQueuedSpinLock und KeAcquireInStackQueuedSpinLockAtDpcLevel, um die in die Warteschlange eingereihte Drehsperre abzurufen. Diese Routinen initialisieren die Struktur, um die in die Warteschlange eingereihte Drehsperre darzustellen. Der Treiber übergibt die Struktur an KeReleaseInStackQueuedSpinLock und KeReleaseInStackQueuedSpinLockFromDpcLevel, wenn die Drehsperre losgelassen wird.
Weitere Informationen finden Sie unter "Warteschlanged Spin Locks".
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
KTIMER
Die KTIMER-Struktur ist eine undurchsichtige Struktur, die ein Timerobjekt darstellt. Legen Sie die Elemente dieser Struktur nicht direkt fest. Weitere Informationen finden Sie unter TimerObjekte und DPCs.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
LOOKASIDE_LIST_EX
Die LOOKASIDE_LIST_EX Struktur beschreibt eine Nachschlageliste.
typedef struct _LOOKASIDE_LIST_EX {
... // opaque
} LOOKASIDE_LIST_EX, *PLOOKASIDE_LIST_EX;
Eine Lookaside-Liste ist ein Pool von Puffern mit fester Größe, die der Treiber lokal verwalten kann, um die Anzahl der Aufrufe an Systemzuordnungsroutinen zu verringern, wodurch die Leistung verbessert wird. Die Puffer weisen eine einheitliche Größe auf und werden als Einträge in der Lookaside-Liste gespeichert.
Treiber sollten die LOOKASIDE_LIST_EX Struktur als undurchsichtig behandeln. Treiber, die auf Strukturmitglieder zugreifen oder abhängigkeiten von den Speicherorten dieser Member sind, bleiben möglicherweise nicht portabel und interoperabel mit anderen Treibern.
Der Abschnitt "Verwandte Artikel " enthält eine Liste der Routinen, die diese Struktur verwenden.
Weitere Informationen zu Lookaside-Listen finden Sie unter Verwenden von Lookaside-Listen.
Auf 64-Bit-Plattformen muss diese Struktur 16 Byte ausgerichtet sein.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
NPAGED_LOOKASIDE_LIST
Die NPAGED_LOOKASIDE_LIST-Struktur ist eine undurchsichtige Struktur, die eine Nachschlageliste mit Puffern mit fester Größe beschreibt, die aus nicht ausgelagertem Pool zugeordnet sind. Das System erstellt neue Einträge und zerstört bei Bedarf nicht verwendete Einträge in der Liste. Bei Puffern mit fester Größe ist die Verwendung einer Lookaside-Liste schneller als das direkte Zuordnen des Arbeitsspeichers.
Verwenden Sie ExInitializeNPagedLookasideList, um die Lookaside-Liste zu initialisieren. Verwenden Sie ExAllocateFromNPagedLookasideList, um einen Puffer aus der Liste zuzuweisen, und ExFreeToNPagedLookasideList, um einen Puffer an die Liste zurückzugeben.
Treiber müssen immer explizit alle Lookaside-Listen freigeben, die sie vor dem Entladen erstellen. Es ist ein schwerwiegender Programmierfehler, andernfalls zu tun. Verwenden Sie ExDeleteNPagedLookasideList , um die Liste frei zu geben.
Treiber können auch Lookaside-Listen für seitenseitigen Pool verwenden. Eine PAGED_LOOKASIDE_LIST Struktur beschreibt eine Lookaside-Liste, die seitenseitige Puffer enthält. Eine LOOKASIDE_LIST_EX Struktur kann eine Nachschlageliste beschreiben, die seitenseitige oder nicht seitenseitige Puffer enthält. Weitere Informationen finden Sie unter Verwenden von Lookaside-Listen.
Auf 64-Bit-Plattformen muss diese Struktur 16 Byte ausgerichtet sein.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
Object_Type
OBJECT_TYPE ist eine undurchsichtige Struktur, die den Objekttyp eines Handles angibt. Weitere Informationen finden Sie unter ObReferenceObjectByHandle.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
PAGED_LOOKASIDE_LIST
Die PAGED_LOOKASIDE_LIST-Struktur ist eine undurchsichtige Struktur, die eine Nachschlageliste mit Puffern mit fester Größe beschreibt, die aus einem ausgelagerten Pool zugewiesen wurden. Das System erstellt neue Einträge und zerstört bei Bedarf nicht verwendete Einträge in der Liste. Bei Puffern mit fester Größe ist die Verwendung einer Lookaside-Liste schneller als das direkte Zuordnen des Arbeitsspeichers.
Verwenden Sie ExInitializePagedLookasideList, um die Lookaside-Liste zu initialisieren. Verwenden Sie ExAllocateFromPagedLookasideList, um einen Puffer aus der Liste zuzuweisen, und ExFreeToPagedLookasideList, um einen Puffer an die Liste zurückzugeben.
Treiber müssen immer explizit alle Lookaside-Listen freigeben, die sie vor dem Entladen erstellen. Es ist ein schwerwiegender Programmierfehler, andernfalls zu tun. Verwenden Sie ExDeletePagedLookasideList , um die Liste frei zu geben.
Treiber können auch Lookaside-Listen für nicht seitenseitigen Pool verwenden. Eine NPAGED_LOOKASIDE_LIST Struktur beschreibt eine Nachschlageliste, die nicht ausgelagerte Puffer enthält. Eine LOOKASIDE_LIST_EX Struktur kann eine Nachschlageliste beschreiben, die seitenseitige oder nicht seitenseitige Puffer enthält. Weitere Informationen finden Sie unter Verwenden von Lookaside-Listen.
Auf 64-Bit-Plattformen muss diese Struktur 16 Byte ausgerichtet sein.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
RTL_BITMAP
Die RTL_BITMAP Struktur ist eine undurchsichtige Struktur, die eine Bitmap beschreibt.
typedef struct _RTL_BITMAP {
// opaque
} RTL_BITMAP, *PRTL_BITMAP;
Greifen Sie nicht direkt auf die Member dieser Struktur zu. Treiber, die Abhängigkeiten von Memberspeicherorten haben oder direkt auf Memberwerte zugreifen, bleiben möglicherweise nicht mit zukünftigen Versionen des Windows-Betriebssystems kompatibel.
Die RTL_BITMAP-Struktur dient als Kopfzeile für eine allgemeine, eindimensionale Bitmap mit beliebiger Länge. Ein Treiber kann eine solche Bitmap als wirtschaftliche Möglichkeit verwenden, um eine Reihe wiederverwendbarer Elemente nachzuverfolgen. Ein Dateisystem kann z. B. Bitmaps verwenden, um nachzuverfolgen, welche Cluster und Sektoren auf einer Festplatte bereits dateidaten enthalten sind.
Eine Liste der RtlXxx-Routinen, die RTL_BITMAP Strukturen verwenden, finden Sie im Abschnitt "Verwandte Artikel". Der Aufrufer dieser RtlXxx-Routinen ist für die Zuordnung des Speichers für die RTL_BITMAP Struktur und für den Puffer verantwortlich, der die Bitmap enthält. Dieser Puffer muss mit einer Grenze von 4 Byte im Arbeitsspeicher beginnen und muss ein Vielfaches von 4 Byte länge sein. Die Bitmap beginnt am Anfang des Puffers, kann jedoch eine beliebige Anzahl von Bits enthalten, die in den zugeordneten Puffer passen.
Rufen Sie vor dem Bereitstellen einer RTL_BITMAP-Struktur als Parameter für eine RtlXxx-Routine die RtlInitializeBitMap-Routine auf, um die Struktur zu initialisieren. Die Eingabeparameter für diese Routine sind ein Zeiger auf einen Puffer, der die Bitmap und die Größe in Bits der Bitmap enthält. RtlInitializeBitMap ändert den Inhalt dieses Puffers nicht.
Wenn der Aufrufer den Speicher für die RTL_BITMAP Struktur und Bitmap im seitenseitigen Speicher zuweist, muss der Aufrufer unter IRQL <= APC_LEVEL ausgeführt werden, wenn ein Zeiger an diese Struktur als Parameter an eine der rtlXxx-Routinen übergeben wird, die im Abschnitt "Verwandte Artikel" aufgeführt sind. Wenn der Aufrufer den Speicher aus nicht ausgelagertem Speicher (oder entsprechend aus gesperrtem ausgelagertem Speicher) zuweist, kann der Aufrufer bei jedem IRQL ausgeführt werden, wenn er die RtlXxx-Routine aufruft.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
RTL_RUN_ONCE
Die RTL_RUN_ONCE Struktur ist eine undurchsichtige Struktur, in der die Informationen für eine einmalige Initialisierung gespeichert werden.
Treiber müssen diese Struktur initialisieren, indem die RtlRunOnceInitialize-Routine aufgerufen wird, bevor sie an andere RtlRunOnceXxx-Routinen übergeben wird.
Header: Ntddk.h. Include: Ntddk.h.
SECURITY_SUBJECT_CONTEXT
Die SECURITY_SUBJECT_CONTEXT-Struktur ist eine undurchsichtige Struktur, die den Sicherheitskontext darstellt, in dem ein bestimmter Vorgang stattfindet. Treiber dürfen keine Änderungen vornehmen oder versuchen, direkt auf Mitglieder dieser Struktur zuzugreifen, um Sicherheitsentscheidungen zu treffen. Um Sicherheitsprobleme bei der Autorisierung zu vermeiden, übergeben Sie diese undurchsichtige Struktur in Aufrufen von SeAccessCheck oder SePrivilegeCheck.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
SLIST_HEADER
Eine SLIST_HEADER Struktur ist eine undurchsichtige Struktur, die als Kopfzeile für eine sequenzierte verknüpfte Liste dient. Weitere Informationen finden Sie unter "Singly" und "Doubly Linked Lists".
Auf 64-Bit-Plattformen müssen SLIST_HEADER Strukturen 16 Byte ausgerichtet sein.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
XSTATE_SAVE
Die XSTATE_SAVE-Struktur ist eine undurchsichtige Struktur, die die informationen zum erweiterten Prozessorzustand beschreibt, die ein Kernelmodustreiber speichert und wiederhergestellt.
typedef struct _XSTATE_SAVE {
... // opaque
} XSTATE_SAVE, *PXSTATE_SAVE;
Alle Mitglieder sind undurchsichtig.
Die Routinen KeSaveExtendedProcessorState und KeRestoreExtendedProcessorState verwenden diese Struktur.
Kopfzeile: Wdm.h. Include: Wdm.h, Ntddk.h, Ntifs.h.
Verwandte Artikel
ExAllocateFromNPagedLookasideList
ExAllocateFromPagedLookasideList
ExInitializePagedLookasideList
ExInitializeNPagedLookasideList
KeAcquireInStackQueuedSpinLock
KeAcquireInStackQueuedSpinLockAtDpcLevel
KeRestoreExtendedProcessorState
KeDeregisterBugCheckReasonCallback
KeRegisterBugCheckReasonCallback
KeReleaseInStackQueuedSpinLock
KeReleaseInStackQueuedSpinLockFromDpcLevel
PsGetProcessCreateTimeQuadPart