[R00tKit]

hi can anyone explain this Quote ( i am beginner in windows internal)

windows internal:

One important restriction on code running at DPC/dispatch level or above is that it can’t wait
for an object if doing so would necessitate the scheduler to select another thread to execute,
which is an illegal operation because the scheduler synchronizes its data structures at DPC/
dispatch level and cannot therefore be invoked to perform a reschedule. Another restriction
is that only nonpaged memory can be accessed at IRQL DPC/dispatch level or higher.
This rule is actually a side-effect of the first restriction because attempting to access memory
that isn’t resident results in a page fault. When a page fault occurs, the memory manager
initiates a disk I/O and then needs to wait for the file system driver to read the page in from
disk. This wait would in turn require the scheduler to perform a context switch (perhaps to
the idle thread if no user thread is waiting to run), thus violating the rule that the scheduler
can’t be invoked (because the IRQL is still DPC/dispatch level or higher at the time of the disk
read).

Thank

[EP_X0FF]

Hello,

what exactly you don't understand?

Regards.

[R00tKit]

code running at DPC/dispatch level or above is that it can’t wait
for an object if doing

why can't?

[EP_X0FF]

Does this helps a bit?

http://www.reverse-engineering.info/Sys ... g_irql.pdf

[volcary]

code running at DPC/dispatch level or above is that it can’t wait
for an object if doing

why can't?

once doing wait for one object, the thread swap must will happen, if not in single processor , the system will hang,and the swap will cause a thread context switch, this context switch need DPC dispatcher.

[0xC0000022L]

I think the paper is nice, but it emphasizes a bit too much the connection with IRQs.

Important points:

• <= DISPATCH_LEVEL are software IRQLs
• > DISPATCH_LEVEL are hardware IRQLs (device IRQLs aka DIRQLs)
• All requests/interrupts from IRQLs lower than current are blocked until the current request is serviced
• At PASSIVE_LEVEL: all user code and much of the kernel code (incl. drivers)
• At APC_LEVEL: paging I/O
• At DISPATCH_LEVEL: DPC handling and scheduling, DPCs are a whole lot story of their own (DPC queue, ISR completion)
• Dispatcher is responsible to switch between threads etc, dispatcher is called whenever system returns to lower IRQL (lower than DISPATCH_LEVEL)
• Interruption and preemption need to be distinguished (this important point is handled to briefly in the paper, IMO)
  • Interruption happens when a request with a higher IRQL arrives
  • Preemption happens when another thread is scheduled instead of the running one by the dispatcher
• Code running at DISPATCH_LEVEL or above cannot:
  • be preempted, but it can be interrupted
  • wait on dispatcher objects, such as threads

Now, the last two top-level bullet points are what's relevant to answer the question. Waiting requires synchronization (dispatcher) objects and oversimplified one could say that the dispatcher cannot interrupt itself. Because the code at or above DISPATCH_LEVEL cannot be preempted, the code servicing page I/O cannot be run (thus the limitation to access only non-paged pool) - IIRC it also uses synchronization to some extent, which means it is an extension of the waiting restriction.

One more thing: IRQLs affect code running on each (logical) CPU separately.

One can only understand recursion if one understands recursion ;)

BTW: "Matt Wu" (author of the paper) rings a bell. Didn't he write one of the first ext2 FS drivers for Windows?