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
PsLookupProcessByProcessId has been in a pageable code section at least back to XP (I'm assuming earlier but that's what I had handy to look at). It also has code paths that acquire wait locks under certain circumstances. So, the fact that this code hasn't ever crashed for you is either lucky or unlucky (depending on how you look at it ). Do you run with Driver Verifier enabled?
Holding a spinlock around this call is strange, not sure what state you'd need to protect. But in any case your code needs fixed.
Hi Scott, Thank you for your detailed reply! I inherited this code about a week ago. It was written 7 years ago and hasn’t been modified since. The first thing I did was run it under driver verifier and I got various bug checks, one of which is this one.
By the way, we collect bugcheck metrics (bugcheck code, bugcheck args, and crashing call stack) due to another driver we’ve been deploying for several years. The metrics are available for 30 days and I searched them for this driver I inherited. Turns out we have one instance of this specific bugcheck for this driver in the wild.
Thanks again for the internals of that function, I appreciate it!
). Do you run with Driver Verifier enabled?