Undurchsichtige Strukturen des Windows-Kernels
In diesem Artikel werden undurchsichtige Strukturen des Windows-Kernels aufgelistet und beschrieben. Für viele dieser Strukturen sollten Treiber nicht auf Member zugreifen oder diese ändern, sondern stattdessen vom System bereitgestellte Routinen verwenden, um auf die Informationen zuzugreifen. 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, mit 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 können die ObReferenceObjectByHandle-Routine verwenden, um einen Zeiger auf das Prozessobjekt abzurufen, das dem angegebenen Handle zugeordnet ist. Die globale Variable PsInitialSystemProcess verweist auf das Prozessobjekt für den Systemprozess.
Ein Process-Objekt ist ein Objekt-Manager-Objekt. Treiber sollten Objekt-Manager-Routinen wie ObReferenceObject und ObDereferenceObject verwenden, um die Verweisanzahl des Objekts beizubehalten.
Header: Wdm.h. Einschließen: 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, mit dem ausgeführt werden soll. Treiber können die PsGetCurrentThread-Routine verwenden, um einen Zeiger auf das Threadobjekt für den aktuellen Thread abzurufen, und können die ObReferenceObjectByHandle-Routine verwenden, um einen Zeiger auf das Threadobjekt abzurufen, das dem angegebenen Handle zugeordnet ist.
Ein Threadobjekt ist ein Objekt-Manager-Objekt. Treiber sollten Objekt-Manager-Routinen wie ObReferenceObject und ObDereferenceObject verwenden, um die Verweisanzahl des Objekts beizubehalten.
Header: Wdm.h. Einschließen: Wdm.h, Ntddk.h, Ntifs.h.
EX_RUNDOWN_REF
Die EX_RUNDOWN_REF-Struktur ist eine undurchsichtige Systemstruktur, die Informationen über die status des Rundownschutzes 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 Rundownschutzroutinen verwenden alle einen Zeiger auf eine EX_RUNDOWN_REF-Struktur als ersten Parameter.
Weitere Informationen finden Sie unter Run-Down Protection. Header: Wdm.h. Schließen Sie Wdm.h ein.
EX_TIMER
Die EX_TIMER-Struktur ist eine undurchsichtige Struktur, die das Betriebssystem verwendet, um ein EX_TIMER Timerobjekt darzustellen.
typedef struct _EX_TIMER *PEX_TIMER;
Alle Elemente dieser Struktur sind für Treiber undurchsichtig.
Die folgenden Ex Xxx-Timerroutinen erfordern einen Zeiger auf eine systemseitig zugeordnete EX_TIMER Struktur als Eingabeparameter:
Das Betriebssystem erstellt EX_TIMER-basierte Timerobjekte. 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 verantwortlich, indem Er ExDeleteTimer aufruft.
Weitere Informationen finden Sie unter Ex Xxx-Timerroutinen und EX_TIMER-Objekte.
Header: Wdm.h. Einschließen: 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 Mutexes finden Sie unter Fast Mutexes und Guarded Mutexes.
Header: Wdm.h. Einschließen: Wdm.h, Ntddk.h, Ntifs.h.
IO_CSQ
Die IO_CSQ-Struktur ist eine undurchsichtige Struktur, die zum Angeben der abbruchsicheren IRP-Warteschlangenroutinen des Treibers verwendet wird. Legen Sie die Member dieser Struktur nicht direkt fest. Verwenden Sie IoCsqInitialize oder IoCsqInitializeEx , um diese Struktur zu initialisieren.
Eine Übersicht über die Verwendung abbruchsicherer IRP-Warteschlangen finden Sie unter Cancel-Safe IRP-Warteschlangen.
Verfügbar unter Microsoft Windows XP und höheren Versionen des Windows-Betriebssystems.
Header: Wdm.h. Einschließen: Wdm.h, Ntddk.h, Ntifs.h.
IO_CSQ_IRP_CONTEXT
Die IO_CSQ_IRP_CONTEXT-Struktur ist eine undurchsichtige Datenstruktur, die zum Angeben des IRP-Kontexts für ein IRP in der abbruchsicheren IRP-Warteschlange des Treibers verwendet wird. Die Routinen IoCsqInsertIrp, IoCsqInsertIrpEx und IoCsqRemoveIrp verwenden diese Struktur als Schlüssel, um bestimmte IRPs in der Warteschlange zu identifizieren.
Eine Übersicht über die Verwendung abbruchsicherer IRP-Warteschlangen finden Sie unter Cancel-Safe IRP-Warteschlangen.
Verfügbar unter Microsoft Windows XP und höheren Versionen des Windows-Betriebssystems.
Header: Wdm.h. Einschließen: Wdm.h, Ntddk.h, Ntifs.h.
IO_WORKITEM
Die IO_WORKITEM-Struktur ist eine undurchsichtige Struktur, die ein Arbeitselement für einen System workerthread beschreibt.
Ein Treiber kann ein Arbeitselement zuordnen, indem er IoAllocateWorkItem aufruft. Alternativ kann ein Treiber einen eigenen Puffer zuordnen und dann IoInitializeWorkItem aufrufen, um diesen Puffer als Arbeitselement zu initialisieren.
Alle Arbeitselemente, die IoAllocateWorkItem ordnet, müssen von IoFreeWorkItem freigegeben werden. Jeder von IoInitializeWorkItem initialisierte Arbeitsspeicher muss von IoUninitializeWorkItem nicht initialisiert werden, bevor er freigegeben werden kann.
Weitere Informationen zu Arbeitselementen finden Sie unter System Worker Threads.
Header: Wdm.h. Einschließen: Wdm.h, Ntddk.h, Ntifs.h.
KBUGCHECK_CALLBACK_RECORD
Die KBUGCHECK_CALLBACK_RECORD-Struktur ist eine undurchsichtige Struktur, die von den Routinen KeRegisterBugCheckCallback und KeDeregisterBugCheckCallback verwendet wird.
Die KBUGCHECK_CALLBACK_RECORD-Struktur wird von den Routinen KeRegisterBugCheckReasonCallback und KeDeregisterBugCheckReasonCallback für die Buchhaltung verwendet.
Die Struktur muss im residenten Arbeitsspeicher zugeordnet werden, z. B. im nicht ausgestellten Pool. Verwenden Sie die KeInitializeCallbackRecord-Routine , um die Struktur vor der Verwendung zu initialisieren.
Header: Ntddk.h. Include: Ntddk.h.
KBUGCHECK_REASON_CALLBACK_RECORD
Die KBUGCHECK_REASON_CALLBACK_RECORD-Struktur ist eine undurchsichtige Struktur, die von den Routinen KeRegisterBugCheckReasonCallback und KeDeregisterBugCheckReasonCallback verwendet wird.
Die KBUGCHECK_REASON_CALLBACK_RECORD-Struktur wird von den Routinen KeRegisterBugCheckReasonCallback und KeDeregisterBugCheckReasonCallback für die Buchhaltung verwendet.
Die Struktur muss im residenten Arbeitsspeicher zugeordnet werden, z. B. im nicht ausgestellten Pool. Verwenden Sie die KeInitializeCallbackRecord-Routine , um die Struktur vor der Verwendung zu initialisieren.
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 Member dieser Struktur nicht direkt fest. Siehe DPC-Objekte und DPCs.
Header: Wdm.h. Einschließen: 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.
Header: Wdm.h. Einschließen: Wdm.h, Ntddk.h, Ntifs.h.
KGUARDED_MUTEX
Die KGUARDED_MUTEX-Struktur ist eine undurchsichtige Struktur, die einen bewachten Mutex darstellt.
Verwenden Sie KeInitializeGuardedMutex , um eine KGUARDED_MUTEX-Struktur als geschützten Mutex zu initialisieren.
Bewachte Mutexes müssen aus einem nicht ausgelagerten Pool zugeordnet werden.
Weitere Informationen zu bewachten Mutexes finden Sie unter Fast Mutexes und Guarded Mutexes.
Header: Wdm.h. Einschließen: 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 Interrupt-Drehsperre für den Interrupt. Der Treiber verwendet diesen Zeiger auch beim Aufheben der Registrierung einer InterruptService-Routine .
Header: Wdm.h. Einschließen: Wdm.h, Ntddk.h, Ntifs.h.
KLOCK_QUEUE_HANDLE
Die KLOCK_QUEUE_HANDLE-Struktur ist eine undurchsichtige Struktur, die eine Spinsperre in der Warteschlange beschreibt. Der Treiber weist die KLOCK_QUEUE_HANDLE-Struktur zu und übergibt sie an KeAcquireInStackQueuedSpinLock und KeAcquireInStackQueuedSpinLockAtDpcLevel , um die Spinsperre in der Warteschlange abzurufen. Diese Routinen initialisieren die Struktur, um die Spinsperre in der Warteschlange darzustellen. Der Treiber übergibt die Struktur an KeReleaseInStackQueuedSpinLock und KeReleaseInStackQueuedSpinLockFromDpcLevel , wenn die Spinsperre freigegeben wird.
Weitere Informationen finden Sie unter Spin-Sperren in Warteschlange.
Header: Wdm.h. Einschließen: Wdm.h, Ntddk.h, Ntifs.h.
KTIMER
Die KTIMER-Struktur ist eine undurchsichtige Struktur, die ein Timerobjekt darstellt. Legen Sie die Member dieser Struktur nicht direkt fest. Weitere Informationen finden Sie unter Timer-Objekte und DPCs.
Header: Wdm.h. Einschließen: Wdm.h, Ntddk.h, Ntifs.h.
LOOKASIDE_LIST_EX
Die LOOKASIDE_LIST_EX-Struktur beschreibt eine Suchliste.
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 von Systemzuordnungsroutinen zu reduzieren, was die Leistung verbessert. Die Puffer haben eine einheitliche Größe und werden als Einträge in der Suchliste gespeichert.
Treiber sollten die LOOKASIDE_LIST_EX-Struktur als undurchsichtig behandeln. Treiber, die auf Strukturmitglieder zugreifen oder Abhängigkeiten von den Speicherorten dieser Member aufweisen, 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.
Wird ab Windows Vista unterstützt.
Header: Wdm.h. Einschließen: Wdm.h, Ntddk.h, Ntifs.h.
NPAGED_LOOKASIDE_LIST
Die NPAGED_LOOKASIDE_LIST-Struktur ist eine undurchsichtige Struktur, die eine Suchliste von Puffern mit fester Größe beschreibt, die aus einem nicht ausgestellten Pool zugewiesen wurden. Das System erstellt neue Einträge und zerstört nach Bedarf nicht verwendete Einträge in der Liste. Bei Puffern mit fester Größe ist die Verwendung einer Suchliste schneller als die direkte Zuweisung von Arbeitsspeicher.
Verwenden Sie ExInitializeNPagedLookasideList , um die Suchliste zu initialisieren. Verwenden Sie ExAllocateFromNPagedLookasideList , um einen Puffer aus der Liste zuzuweisen, und ExFreeToNPagedLookasideList , um einen Puffer in die Liste zurückzugeben.
Treiber müssen alle von ihnen erstellten Suchlisten immer explizit freigeben, bevor sie entladen werden. Es handelt sich um einen schwerwiegenden Programmierfehler. Verwenden Sie ExDeleteNPagedLookasideList , um die Liste frei zu geben.
Treiber können auch Suchlisten für einen ausgelagerten Pool verwenden. Ab Windows 2000 beschreibt eine PAGED_LOOKASIDE_LIST-Struktur eine Suchliste, die ausgelagerte Puffer enthält. Ab Windows Vista kann eine LOOKASIDE_LIST_EX-Struktur eine Suchliste beschreiben, die entweder ausgelagerte oder nicht ausgelagerte Puffer enthält. Weitere Informationen finden Sie unter Verwenden von Lookaside Listen.
Auf 64-Bit-Plattformen muss diese Struktur 16 Byte ausgerichtet sein.
Wird ab Windows 2000 unterstützt.
Header: Wdm.h. Einschließen: 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.
Header: Wdm.h. Einschließen: Wdm.h, Ntddk.h, Ntifs.h.
PAGED_LOOKASIDE_LIST
Die PAGED_LOOKASIDE_LIST-Struktur ist eine undurchsichtige Struktur, die eine Lookaside-Liste von Puffern mit fester Größe beschreibt, die aus einem ausgelagerten Pool zugewiesen werden. Das System erstellt neue Einträge und zerstört nach Bedarf nicht verwendete Einträge in der Liste. Bei Puffern mit fester Größe ist die Verwendung einer Suchliste schneller als die direkte Zuweisung von Arbeitsspeicher.
Verwenden Sie ExInitializePagedLookasideList , um die Suchliste zu initialisieren. Verwenden Sie ExAllocateFromPagedLookasideList , um einen Puffer aus der Liste zuzuweisen, und ExFreeToPagedLookasideList , um einen Puffer zur Liste zurückzugeben.
Treiber müssen alle von ihnen erstellten Suchlisten immer explizit freigeben, bevor sie entladen werden. Es handelt sich um einen schwerwiegenden Programmierfehler. Verwenden Sie ExDeletePagedLookasideList , um die Liste frei zu machen.
Treiber können auch Suchlisten für Nicht-Auslagerpools verwenden. Ab Windows 2000 beschreibt eine NPAGED_LOOKASIDE_LIST-Struktur eine Suchliste, die nicht auslagerte Puffer enthält. Ab Windows Vista kann eine LOOKASIDE_LIST_EX-Struktur eine Suchliste beschreiben, die entweder ausgelagerte oder nicht ausgelagerte Puffer enthält. Weitere Informationen finden Sie unter Verwenden von Lookaside Listen.
Auf 64-Bit-Plattformen muss diese Struktur 16 Byte ausgerichtet sein.
Wird ab Windows 2000 unterstützt.
Header: Wdm.h. Einschließen: 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 aufweisen oder direkt auf Memberwerte zugreifen, bleiben möglicherweise nicht mit zukünftigen Versionen des Windows-Betriebssystems kompatibel.
Die RTL_BITMAP-Struktur dient als Header für eine universelle, eindimensionale Bitmap von beliebiger Länge. Ein Treiber kann eine solche Bitmap als wirtschaftliche Möglichkeit verwenden, um eine Reihe wiederverwendbarer Elemente nachzuverfolgen. Beispielsweise kann ein Dateisystem Bitmaps verwenden, um nachzuverfolgen, welche Cluster und Sektoren auf einer Festplatte bereits zum Speichern von Dateidaten zugewiesen wurden.
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 Vier-Byte-Grenze im Arbeitsspeicher beginnen und ein Vielfaches von vier Bytes 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 der Bitmap in Bits enthält. RtlInitializeBitMap ändert den Inhalt dieses Puffers nicht.
Wenn der Aufrufer den Speicher für die RTL_BITMAP Struktur und Bitmap im Auslagerungsspeicher zuweist, muss der Aufrufer unter IRQL <= APC_LEVEL ausgeführt werden, wenn er einen Zeiger auf diese Struktur als Parameter an eine der im Abschnitt Verwandte Artikel aufgeführten RtlXxx-Routinen übergibt. Wenn der Aufrufer den Speicher aus nicht ausgelagertem Arbeitsspeicher (oder entsprechend aus gesperrtem Auslagerungsspeicher) ordnet, kann der Aufrufer bei jedem IRQL ausgeführt werden, wenn er die RtlXxx-Routine aufruft.
Unterstützt in Windows 2000 und höheren Versionen von Windows.
Header: Wdm.h. Einschließen: Wdm.h, Ntddk.h, Ntifs.h.
RTL_RUN_ONCE
Die RTL_RUN_ONCE-Struktur ist eine undurchsichtige Struktur, die die Informationen für eine einmalige Initialisierung speichert.
Treiber müssen diese Struktur initialisieren, indem sie die RtlRunOnceInitialize-Routine aufrufen, bevor sie an andere RtlRunOnceXxx-Routinen übergeben wird.
Verfügbar unter Windows Vista und höheren Versionen des Windows-Betriebssystems.
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 Elemente dieser Struktur ändern oder versuchen, direkt darauf zuzugreifen, um Sicherheitsentscheidungen zu treffen. Um Sicherheitsprobleme bei der Autorisierung zu vermeiden, übergeben Sie stattdessen diese undurchsichtige Struktur in Aufrufen von SeAccessCheck oder SePrivilegeCheck.
Header: Wdm.h. Einschließen: Wdm.h, Ntddk.h, Ntifs.h.
SLIST_HEADER
Eine SLIST_HEADER-Struktur ist eine undurchsichtige Struktur, die als Header für eine sequenzierte, singly verknüpfte Liste dient. Weitere Informationen finden Sie unter Singly und Doubly Linked Listen.
Auf 64-Bit-Plattformen müssen SLIST_HEADER Strukturen um 16 Byte ausgerichtet sein.
Header: Wdm.h. Einschließen: 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 Member sind undurchsichtig.
Die Routinen KeSaveExtendedProcessorState und KeRestoreExtendedProcessorState verwenden diese Struktur.
Unterstützt in Windows 7 und höheren Versionen des Windows-Betriebssystems.
Header: Wdm.h. Einschließen: Wdm.h, Ntddk.h, Ntifs.h.
Verwandte Artikel
ExAllocateFromNPagedLookasideList
ExAllocateFromPagedLookasideList
ExInitializePagedLookasideList
ExInitializeNPagedLookasideList
KeAcquireInStackQueuedSpinLock
KeAcquireInStackQueuedSpinLockAtDpcLevel
KeRestoreExtendedProcessorState
KeDeregisterBugCheckReasonCallback
KeRegisterBugCheckReasonCallback
KeReleaseInStackQueuedSpinLock
KeReleaseInStackQueuedSpinLockFromDpcLevel
PsGetProcessCreateTimeQuadPart
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für