I've inherited old driver code that calls PsLookupProcessByProcessId at IRQL DISPATCH and sometimes BSODs with IRQL_NOT_LESS_OR_EQUAL. The online msdn doc for that function states that it must be called at IRQL <= APC_LEVEL which explains the BSOD. I asked a fellow dev who has knowledge of this driver and he claims that WDK version 8.1 has a doc that states that function can be called at IRQL <= DISPATCH. And he claims they have never experienced a BSOD due to that function.
Note: I did upgrade the WDK version from 10.0.17134.0 to 10.0.26100.0 and changed the TargetVersion from Windows7 to Windows10 before I ran the driver.
He posits that the lack of historical BSOD's in that function may be due to the WDK version used. But that doesn't make sense to me because the implementation of that function is in NtosKrnl.exe which would make the WDK version irrelevant.
Could it simply be that the old WDK doc he's looking at for PsLookupProcessByProcessId is wrong about its IRQL restrictions? Or could it be that my fellow dev is right and somehow the WDK version is indeed preventing the BSOD?
One thing to remember is that not every call to an API at an invalid IRQL will result in a crash. As you have seen, many calls that are invalid will work just fine
Unless a given API is implemented as a macro, or uses a macro to call significantly different versions of the API, compile time differences like versions of the header files have little difference. You can find out if that is the case very simply by looking at those headers
Documentation is also updated overtime. Sometimes the changes are for the worse, but usually not. Rarely are the 'rules' for calling an API actually changed, but often they are clarified or become more strictly enforced.
In this particular case, the example shows use at passive - and it seems hard to imagine why it would need to be called at an elevated IRQL. Probably that's not well tested if nothing else.
Thanks MBond2, I’ll check the header files. The reason PsLookupProcessByProcessId is called at DISPATCH IRQL is because it’s called while holding a SpinLock. You mentioned an example, to which example are you referring? Thank you