{"id":251,"date":"2008-02-27T14:50:34","date_gmt":"2008-02-27T14:50:34","guid":{"rendered":"https:\/\/driverentry.com.br\/en\/2008\/02\/27\/kewaitformultipleobjects-pero-no-mucho\/"},"modified":"2026-07-27T20:44:45","modified_gmt":"2026-07-27T20:44:45","slug":"kewaitformultipleobjects-pero-no-mucho","status":"publish","type":"post","link":"https:\/\/driverentry.com.br\/en\/2008\/02\/27\/kewaitformultipleobjects-pero-no-mucho\/","title":{"rendered":"KeWaitForMultipleObjects, pero no mucho!"},"content":{"rendered":"
\"\"<\/a><\/div>\n

A while ago, my friend Slug published a post<\/a> about his adventures in Kernel looking for the reason for a blue screen. The problem was caused by an incorrect call to the KeWaitForMultipleObjects()<\/a> function in an attempt to wait for 4 objects. Yeah Wanderley, that’s a result of inheriting a code from everyone. Just because the function has the word “multiple” in its name, it does not mean we can wait for that absurd amount of four objects. In this post I am giving you a simple example of how to use this feature.<\/p>\n

Where does the limit live?<\/h3>\n

The KeWaitForMultipleObjects()<\/em> function uses an array of elements of KWAIT_BLOCK <\/strong>type which contains the data referring to the multiple waiting objects being performed. In many cases, this amount of multiple waiting objects is no more than three. In order to avoid ever having to build an array of KWAIT_BLOCK<\/strong> structures to perform a multiple waiting, the structure that represents a thread in kernel mode, the KTHREAD<\/strong>, contains an array of four elements of this structure embedded in it, as it is shown below.<\/p>\n

\n
kd> dt nt!_KTHREAD<\/pre>\n
   +0x000 Header           : _DISPATCHER_HEADER<\/pre>\n
   +0x010 MutantListHead   : _LIST_ENTRY<\/pre>\n
   +0x018 InitialStack     : Ptr32 Void<\/pre>\n
   +0x01c StackLimit       : Ptr32 Void<\/pre>\n
   +0x020 Teb              : Ptr32 Void<\/pre>\n
   +0x024 TlsArray         : Ptr32 Void<\/pre>\n
   +0x028 KernelStack      : Ptr32 Void<\/pre>\n
   +0x02c DebugActive      : UChar<\/pre>\n
   +0x02d State            : UChar<\/pre>\n
   +0x02e Alerted          : [2] UChar<\/pre>\n
   +0x030 Iopl             : UChar<\/pre>\n
   +0x031 NpxState         : UChar<\/pre>\n
   +0x032 Saturation       : Char<\/pre>\n
   +0x033 Priority         : Char<\/pre>\n
   +0x034 ApcState         : _KAPC_STATE<\/pre>\n
   +0x04c ContextSwitches  : Uint4B<\/pre>\n
   +0x050 IdleSwapBlock    : UChar<\/pre>\n
   +0x051 Spare0           : [3] UChar<\/pre>\n
   +0x054 WaitStatus       : Int4B<\/pre>\n
   +0x058 WaitIrql         : UChar<\/pre>\n
   +0x059 WaitMode         : Char<\/pre>\n
   +0x05a WaitNext         : UChar<\/pre>\n
   +0x05b WaitReason       : UChar<\/pre>\n
   +0x05c WaitBlockList    : Ptr32 _KWAIT_BLOCK<\/pre>\n
   +0x060 WaitListEntry    : _LIST_ENTRY<\/pre>\n
   +0x060 SwapListEntry    : _SINGLE_LIST_ENTRY<\/pre>\n
   +0x068 WaitTime         : Uint4B<\/pre>\n
   +0x06c BasePriority     : Char<\/pre>\n
   +0x06d DecrementCount   : UChar<\/pre>\n
   +0x06e PriorityDecrement : Char<\/pre>\n
   +0x06f Quantum          : Char<\/pre>\n
   +0x070 WaitBlock        : [4] _KWAIT_BLOCK<\/pre>\n
   +0x0d0 LegoData         : Ptr32 Void<\/pre>\n
   +0x0d4 KernelApcDisable : Uint4B<\/pre>\n
   +0x0d8 UserAffinity     : Uint4B<\/pre>\n
   +0x0dc SystemAffinityActive : UChar<\/pre>\n
   +0x0dd PowerState       : UChar<\/pre>\n
   +0x0de NpxIrql          : UChar<\/pre>\n
   +0x0df InitialNode      : UChar<\/pre>\n
   +0x0e0 ServiceTable     : Ptr32 Void<\/pre>\n
   +0x0e4 Queue            : Ptr32 _KQUEUE<\/pre>\n
   +0x0e8 ApcQueueLock     : Uint4B<\/pre>\n
   +0x0f0 Timer            : _KTIMER<\/pre>\n
   +0x118 QueueListEntry   : _LIST_ENTRY<\/pre>\n
   +0x120 SoftAffinity     : Uint4B<\/pre>\n
   +0x124 Affinity         : Uint4B<\/pre>\n
   +0x128 Preempted        : UChar<\/pre>\n
   +0x129 ProcessReadyQueue : UChar<\/pre>\n
   +0x12a KernelStackResident : UChar<\/pre>\n
   +0x12b NextProcessor    : UChar<\/pre>\n
   +0x12c CallbackStack    : Ptr32 Void<\/pre>\n
   +0x130 Win32Thread      : Ptr32 Void<\/pre>\n
   +0x134 TrapFrame        : Ptr32 _KTRAP_FRAME<\/pre>\n
   +0x138 ApcStatePointer  : [2] Ptr32 _KAPC_STATE<\/pre>\n
   +0x140 PreviousMode     : Char<\/pre>\n
   +0x141 EnableStackSwap  : UChar<\/pre>\n
   +0x142 LargeStack       : UChar<\/pre>\n
   +0x143 ResourceIndex    : UChar<\/pre>\n
   +0x144 KernelTime       : Uint4B<\/pre>\n
   +0x148 UserTime         : Uint4B<\/pre>\n
   +0x14c SavedApcState    : _KAPC_STATE<\/pre>\n
   +0x164 Alertable        : UChar<\/pre>\n
   +0x165 ApcStateIndex    : UChar<\/pre>\n
   +0x166 ApcQueueable     : UChar<\/pre>\n
   +0x167 AutoAlignment    : UChar<\/pre>\n
   +0x168 StackBase        : Ptr32 Void<\/pre>\n
   +0x16c SuspendApc       : _KAPC<\/pre>\n
   +0x19c SuspendSemaphore : _KSEMAPHORE<\/pre>\n
   +0x1b0 ThreadListEntry  : _LIST_ENTRY<\/pre>\n
   +0x1b8 FreezeCount      : Char<\/pre>\n
   +0x1b9 SuspendCount     : Char<\/pre>\n
   +0x1ba IdealProcessor   : UChar<\/pre>\n
   +0x1bb DisableBoost     : UChar<\/pre>\n<\/div>\n
From these four elements, three of them are intended to be  used by KeWaitForMultipleObjects()<\/em>, while the fourth one is reserved to be used by the system to implement the waiting with a timeout.<\/p>\n
To wait for up to three objects, the code would be as it is shown below:<\/p>\n
\n
    \/\/-f--> PVOID array<\/span><\/pre>\n
    PVOID       pObjects[3<\/span>];<\/pre>\n
 <\/pre>\n
    \/\/-f--> We have to initialize a pointer array for <\/span><\/pre>\n
    \/\/      the objects which the waiting is based in.<\/span><\/pre>\n
    pObjects[0<\/span>] = &kEvent1;<\/pre>\n
    pObjects[1<\/span>] = &kEvent2;<\/pre>\n
    pObjects[2<\/span>] = &kEvent3;<\/pre>\n
 <\/pre>\n
    \/\/-f--> That's a simple call for a multiple waiting objects<\/span><\/pre>\n
    \/\/      of 3 ones.<\/span><\/pre>\n
    nts = KeWaitForMultipleObjects(3<\/span>,<\/pre>\n
                                   pObjects,<\/pre>\n
                                   WaitAll,<\/pre>\n
                                   Executive,<\/pre>\n
                                   KernelMode,<\/pre>\n
                                   FALSE,<\/pre>\n
                                   NULL,<\/pre>\n
                                   NULL);<\/pre>\n<\/div>\n
Does it mean we cannot wait for more than three objects each time?<\/strong> Well, let me explain it. When it is necessary to wait for more than three objects, we must allocate a large buffer, enough to hold an N-element array of the KWAIT_BLOCK<\/strong> structure, where N is less than or equal to 64. If there is more than that, we are going to have a nice MAXIMUM_WAIT_OBJECTS_EXCEEDED.<\/p>\n
\n
“If a buffer is supplied, the Count parameter may not exceed MAXIMUM_WAIT_OBJECTS. If no buffer is supplied, the Count parameter may not exceed THREAD_WAIT_OBJECTS.”<\/em><\/p>\n<\/blockquote>\n
\n
\/\/-f--> From wdm.h<\/span><\/pre>\n
 <\/pre>\n
#define<\/span> THREAD_WAIT_OBJECTS 3<\/span>       \/\/ Builtin usable wait blocks<\/span><\/pre>\n
 <\/pre>\n
#define<\/span> MAXIMUM_WAIT_OBJECTS 64<\/span>     \/\/ Maximum number of wait objects<\/span><\/pre>\n<\/div>\n
In that case, to be able to do a multiple 10-objects waiting, we’d have the code below:<\/p>\n
\n
   \/\/-f--> PVOID array<\/span><\/pre>\n
    PVOID           pObjects[10<\/span>];<\/pre>\n
 <\/pre>\n
    \/\/-f--> An additional array of KWAIT_BLOCKs<\/span><\/pre>\n
    PKWAIT_BLOCK    pWaitBlocks = NULL;<\/pre>\n
 <\/pre>\n
    \/\/-f--> We have to initialize a pointer array for<\/span><\/pre>\n
    \/\/      the objects which the waiting is based in.<\/span><\/pre>\n
    pObjects[0<\/span>] = &kEvent1;<\/pre>\n
    pObjects[1<\/span>] = &kEvent2;<\/pre>\n
    pObjects[2<\/span>] = &kEvent3;<\/pre>\n
    pObjects[3<\/span>] = &kEvent4;<\/pre>\n
    pObjects[4<\/span>] = &kEvent5;<\/pre>\n
 <\/pre>\n
    \/\/-f--> You may not believe it but I do know how to use loops and arrays.<\/span><\/pre>\n
    \/\/      I need to show you that the objects don't necessarily<\/span><\/pre>\n
    \/\/      need to be in an array; however, the pointers related<\/span><\/pre>\n
    \/\/      to them do.<\/span><\/pre>\n
    pObjects[5<\/span>] = &kEvent6;<\/pre>\n
    pObjects[6<\/span>] = &kEvent7;<\/pre>\n
    pObjects[7<\/span>] = &kEvent8;<\/pre>\n
    pObjects[8<\/span>] = &kEvent9;<\/pre>\n
    pObjects[9<\/span>] = &kEvent10;<\/pre>\n
 <\/pre>\n
    \/\/-f--> We cannot initialize the KWAIT_BLOCKS array structures  <\/span><\/pre>\n
    \/\/      embedded into the KTHREAD structure; we must allocate our own array.<\/span><\/pre>\n
    pWaitBlocks = (PKWAIT_BLOCK) ExAllocatePool(NonPagedPool,<\/pre>\n
                                                sizeof<\/span>(KWAIT_BLOCK) * 10<\/span>);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Doing another test doesn't hurt anybody; however, try not<\/span><\/pre>\n
    \/\/      to test a driver to see how many people die.<\/span><\/pre>\n
    ASSERT(pWaitBlocks != NULL);<\/pre>\n
 <\/pre>\n
    \/\/-f--> A simple call to a multiple waiting for<\/span><\/pre>\n
    \/\/      10 objects without a bugcheck.<\/span><\/pre>\n
    nts = KeWaitForMultipleObjects(10<\/span>,<\/pre>\n
                                   pObjects,<\/pre>\n
                                   WaitAll,<\/pre>\n
                                   Executive,<\/pre>\n
                                   KernelMode,<\/pre>\n
                                   FALSE,<\/pre>\n
                                   NULL,<\/pre>\n
                                   pWaitBlocks);<\/pre>\n
 <\/pre>\n
    \/\/-f--> Having memory leak is not polite.<\/span><\/pre>\n
    ExFreePool(pWaitBlocks);<\/pre>\n<\/div>\n
In summary, that’s all.
\n Good bye!<\/p>\n","protected":false},"excerpt":{"rendered":"
A while ago, my friend Slug published a post about his adventures in Kernel looking for the reason for a blue screen. The problem was caused by an incorrect call to the KeWaitForMultipleObjects() function in an attempt to wait for 4 objects. Yeah Wanderley, that’s a result of inheriting a code from everyone. Just because […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"pagelayer_contact_templates":[],"_pagelayer_content":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-251","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/251","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/comments?post=251"}],"version-history":[{"count":2,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/251\/revisions"}],"predecessor-version":[{"id":297,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/posts\/251\/revisions\/297"}],"wp:attachment":[{"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/media?parent=251"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/categories?post=251"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/driverentry.com.br\/en\/wp-json\/wp\/v2\/tags?post=251"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}