Delaying Thread Execution

This method was proposed by eEye and involved using nt!KeDelayExecutionThread as a way of blocking the calling thread without adversely impacting performance[2]. Alternatively, if nt!KeDelayExecutionThread failed or returned, eEye implemented their payload in such a way as to cause it to spin while calling nt!KeYieldExecution each iteration. The approach that eEye suggests is perfectly fine, assuming the following minimum conditions are true:

1. Non-critical kernel thread
2. No exclusive locks (such as spin locks) are held by a calling frame

If any one of these conditions is not true, the act of spinning or otherwise blocking the thread from continuing normal execution could lead to a deadlock. If the setting is right, though, this method is perfectly acceptable. If the approach described by eEye is used, it will require the resolution of nt!KeDelayExecutionThread at a minimum, but could also require the resolution of nt!KeYieldExecution depending on how robust the recovery method is intended to be. The fact that this requires symbol resolution means that the payload will jump significantly in size if it does not already involve the resolution of symbols.