Maxim, thanks for your reply and apologies for asking the question earlier without researching properly. You were correct it just decrements the count of KernelApcDisable.
Just to clarify, for any future reference:
KeEnterCriticalRegion just decrements the value of _KTHREAD.KernelApcDisable. KeLeaveCriticalRegion increments the value of _KTHREAD.KernelApcDisable. If there are APC’s waiting to be delivered and KernelApcDisable == 0 and SpecialApcDisable == 0, the APC’s are infact delivered.
So in effect this works as mentioned in the MS documentation,
“The KeEnterCriticalRegion routine temporarily disables the delivery of normal kernel APCs; special kernel-mode APCs are still delivered.”
So going back to the original question of BSOD, this looks like a bug in our implementation, as we had stored the ClientPort in two places:
Thread I:
FltCloseClientPort(global.Filter, &global.ClientPort);
Thread II:
FltSendMessage(global.Filter, &sendMessage.ClientPort, …);
FltSendMessage, FltCloseClientPort synchronize internally using _FLT_FILTER.PortLock. FltCloseClientPort sets the second param to NULL after acquiring the lock and then invokes ZwClose(ClientPort). This ensures that even if FltSendMessage is invoked simultaneously, it still does not invoke ObRefenceObjectByHandle. I guess this is what is mentioned in the MS documentation
“To ensure that any messages sent by FltSendMessage are synchronized properly when the communication client port is being closed, FltCloseClientPort sets this variable to NULL.”
The fix should be simple i.e. invoke FltSendMessage(global.Filter, &global.ClientPort, …). Please let me know if I have misunderstood anything and many thanks for the help.