Say you’re iterating across the list of processes to close down their handles at the same time process A is duplicating a handle owned by process B. You go through A, go through all of its handles, find all the invalid ones and force them into some sort of zombie state (you can’t just close them because you don’t want them reopened until the app realizes they’re dead) and then move on to B after A dup’s B’s handle.
And even once you’ve closed all of the handles you’re still not there. Because closing the handle just triggers a cleanup, and you need an actual close so you know there aren’t any IRPs in flight at the time you unload the module. So now you have to wait for all of those handles to enter the closed state.
I’m sure it’s possible, but thinking about how to coordinate all the parts is already giving me a headache. Process rundown is complex enough and that’s one process running at a time all threads in the process have been terminated (so we know the state can’t be perturbed). Trying to do this to a live process seems difficult.
Balance that against the gain, which is that a kernel module can unload. What’s the big win? How much is it worth slowing down other aspects of the system (making handle dereference more expensive, making process list access more expensive, etc…) in order to allow this? I wouldn’t put much into it myself.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Wednesday, March 26, 2008 12:14 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] CreateFile() handle problem
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, March 26, 2008 3:18 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] CreateFile() handle problem> Problematic but possible. OS could, for example, search
handle tables. Well, I see. You mean also pointer >
references. In this model only handles could be allowed.There is no problem with maintaining “referee’s” list -
instead of simply incrementing reference on an object, the
system could add caller’s EPROCESS to the list of processes
that have an outstanding reference to an object in either
pointer or reference form. The question is how the OS has
to inform the processes that a given object is about to get
deleted. The only possible option is APC, so that the target
process has to register a callback with the OS. At this point
we have a logical question arises:What is the reason to inform the process that a given object
got invalidated via a callback if it is going to find it out
when it tries to access it anyway???
Eh? I never said processes should be informed by OS about object
deletion. It is a problem you invented and finally found it is no
problem 
What I said was OS itself would close handles, invalidate entries in
handle table which’d be finally freed when handle owner closes them.
You’re right current implementation is correct and works. What I see as
a problem is the dependence of kernel modules on user mode apps
behaviour. Driver can’t commit suicide until all apps close all handles.
What I described would allow to make a cut and leave apps alone with
their handles. Which are useless in any case. It’d solve problem with
device change notification which is cumbersome at least.
Anyway, it is academic discussion. I only wanted to show Don current
design isn’t the only possible.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other 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
Sorry, I couldn’t resist. I just do battle with COM in UMDF driver