While a Zw* function is running, can it be interrupted, and control transferred to another process/driver/anything that then calls the same Zw function? What about functions that only work IRQL 0?

Well, ZwOpenFile seems to work at IRQL==PASSIVE_LEVEL so yes, it is possible.

About IRQL 0, according to http://www.ext2fsd.com/documents/irql.htm , that is precisely PASSIVE_LEVEL so again functions working only at that level are expecting to be preempted. It is important to note that if it requires IRQL strictly equal to PASSIVE_LEVEL then that means that you can execute it on that level or else unexpected behavior can occur (like very "pleasant" BSODs ). Others, like KeAcquireSpinLock, are allowed to be called at IRQL<=DISPATCH_LEVEL. This DISPATCH_LEVEL prevents other threads to be scheduled on the running core but I think there are still chances of concurrency in kernel mode on multi-core systems and perhaps even by hardware interrupts handlers. Please, refresh my mind by reading the link I gave you above

does this mean that when I use global variables in my SSDT hook, I need to raise IRQL? I have linked list code in my SSDT hook, but its crashing (I already got simple SSDT hook work, it's the linked list code causing problems, verify in debugger) Sould I raise IRQL while in SSDT hook for my linked list code (I know I have restore IRQL when call original function, else crash could occur becase function expects IRQL 0)?

also, KeRaiseIrql not working in driver, tried import KeRaiseIrql from ntoskrnl.exe but on load error dialog pops up "KeRaiseIrql cannot be found in driver ntoskrnl.exe" under win2k (not tested other windows)

Is SSDT the System Service Dispatch Table? I suppose that some system calls (and in fact all of them?) runs at IRQL=PASSIVE_LEVEL so raising the IRQL could not be a very good idea if the data you are planning to handle is allocated from the paged pool. You must use other means for synchronizing the access to data structures. Check http://msdn.microsoft.com/en-us/library/ms810047.aspx . Try to not use those mechanisms that raise the IRQL and remember to check at which IRQL your hook runs because you should not lower it neither.



It is exported by HAL.DLL, but as I've said before, this probably is not your best choice (unless you love random IRQL_NOT_LESS_OR_EQUAL BSODs and others).

Make sure you have #include "ntddk.h" in your source. And also be sure to call KeLowerIrql() to help avoid those BSODs LocalDelAssembly rightly mentions.