I’ve come across some code …
if (refDeviceObject) {
KeEnterCriticalRegion();
ObDereferenceObject( refDeviceObject );
refDeviceObject = NULL;
KeLeaveCriticalRegion();
}
I had a good think and of course double checked the documentation, but I could not work out why the ObDereferenceObject call was put inside those KeEnterCriticalRegion()/KeLeaveCriticalRegion() calls. And yes, refDeviceObject is a local variable and no, it’s not used after that in the function.
Insightful and informative answers, or indeed wild and amusing speculation (or nostalgic off-topic posts about “orange LEOs”), all welcome.
I suspect its purpose is to disallow APCs, and that may be due to some
situation where handling an APC might lead to a deadlock situation. The
documentation suggests that ObDereferenceObjectDeferDelete should be used
to avoid deadlock, but since that is only available in Vista+, this may be
a “legacy idiom” required for pre-Vista systems. That’s my best guess,
and it is only a guess. In the case of a real answer, more information
will be provided.
joe
I’ve come across some code …
if (refDeviceObject) {
KeEnterCriticalRegion();
ObDereferenceObject( refDeviceObject );
refDeviceObject = NULL;
KeLeaveCriticalRegion();
}
I had a good think and of course double checked the documentation, but I
could not work out why the ObDereferenceObject call was put inside those
KeEnterCriticalRegion()/KeLeaveCriticalRegion() calls. And yes,
refDeviceObject is a local variable and no, it’s not used after that in
the function.
Insightful and informative answers, or indeed wild and amusing speculation
(or nostalgic off-topic posts about “orange LEOs”), all welcome.
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Interesting thought - the code’s targeted at Vista & above but I hadn’t heard of ObDereferenceObjectDeferDelete so perhaps the writer hadn’t either. I can’t see (famous last words - as if these things are always obvious!) any deadlock potential in the code but perhaps the writer knows something I don’t, eh?
I hadn’t heard of it either, but one of the problems we continually have
with Microsoft docs is that we never get a list of all the new stuff, nor
do we find advice such as “if you used to do XYZ, you can now do W that
does all of it right”. I’m not sure I ever saw anything about Cancel Safe
Queues until I went to a Driver Developer Conference; they were there, but
I couldn’t find any examples of how to use them.
Idioms persist for decades after they are made obsolete. Look at how many
people still use sprintf to copy a string, or the dead strcpy/strcat
functions.
Having read the docs for KeEnterCriticalSection, I suspect very much that
it is one of those “undocumented” factoids, that handling an APC can lead
to deadlock. Of course, this would not be mentioned in the
ObDereferenceObject code (I have a long list of analogous failures in the
MFC and WIN32 API documentation)
joe
Interesting thought - the code’s targeted at Vista & above but I hadn’t
heard of ObDereferenceObjectDeferDelete so perhaps the writer hadn’t
either. I can’t see (famous last words - as if these things are always
obvious!) any deadlock potential in the code but perhaps the writer knows
something I don’t, eh?
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
There is no benefit to blocking kernel APC delivery around a call to ObDereferenceObject. It sounds like someone was being overly paranoid and did not really understand the nature of kernel APCs.
Tony
OSR
Might it be something that someone would do if there was a pair of drivers and they had belatedly become aware of a wrinkle in one that would be rendered harmless by doing (what we’re talking about ) in the other one? One of my colleagues wondered if that might be the case.