> Hi this post is seperated into two questions:
It is possbile with help of documented functions to track CloseHandle
calls on file object. I need to know which process id is closing a handle
to a specific file object?
What good could this do? See my earlier response to a similar message.
Bottom line: knowing the process ID seems to be completely useless
information anyway, due to duplication and inheritance. Any concept about
this telling you about file object lifetime is misplaced. One CreateFile
call has potentially MANY CloseHandles, and only the last one, not
necessarily issued by the creating process, is the one which initiates the
sequence which eventually causes te file object to evaporate in a puff of
greasy blue smoke. Maybe a filesystem guy can tell us the implications of
pending cache writes on file object lifetime; I freely admit that I have
no idea.
The other questionis related to the callback registered by
SetCreateProcessNotfiyRoutine.
Sometimes the thread in the callback is marked as being terminated. If i
try to suspend the thread i am getting a ntsatus value of 0xc000004b -
STATUS_THREAD_TERMINATING.
As i said only sometimes so is there a way to determine when and why this
happens and can i somehow achieve to suspend in form of deleting this flag
for example?
The use of SuspendThread should be limited; for all practical purposes,
you can safely assume that any program that does this is erroneous. There
are some extremely rare and highly exotic situations in which this API can
be considered, but for everyday programming, it represents something far
below Worst Practice. If you are using it, rewrite your code!
(And don’t say “i’ve never seen it fail”. Don’t worry, it will, on some
mission-critical server in Elbonia; hundreds of pigs will die, and
shrink-wrapped EULA aside, they’ll try to sue you)
Thanks in advance.
Note that it IS common practice to create a thread with the
CREATE_SUSPENDED flag, and issue precisely ONE ResumeThread call, although
it is possible to make valid arguments that this technique violates good
programming practice. I can argue on either side of this case. But
unless you are doing something EXTREMELY off-the-reservation,
SuspendThread is Very Bad Juju. It is one of my indicators for code that
is intrinsically BAD (that’s Broken As Designed) and if I find it, before
I will even consider doing any debugging, I will have to rewrite the code
so it works. Sleep calls are another example of BAD code, and I have yet
to see one used correctly. They are like big flashing neon signs that say
“WARNING!!! CONCURRENT CODE WRITTEN BY TRULY CLUELESS PROGRAMMER HERE!!!”
In 20 years, I can count the valid usages I’ve found of Sleep() on the
thumbs of one hand (I ripped it out anyway, and replaced it with something
more robust. It wasn’t /wrong/, but its usage was a definitely
sub-optimal design)
joe
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