Hi,
I usually do not do low level development, but now I need to close a handle which is located in BaseNamedObjects. I only know the name of the handle. Is there a dll which provides an easy to use function like say ClearHandle(string handleName)?
Regards,
Torsten
Well there are not handles in the BaseNamedObjects directory, only objects
or symbolic links to objects. You can’t delete these if you do not own
them, because an object represents a data structure in memory that is
expected to be there until all references are released. Even a symlink is
expected to be there by the component that created it.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
> Hi,
>
> I usually do not do low level development, but now I need to close a
> handle which is located in BaseNamedObjects. I only know the name of the
> handle. Is there a dll which provides an easy to use function like say
> ClearHandle(string handleName)?
>
> Regards,
> Torsten
>
Let me try to be more precise:
There is a reference from the application to a win32 mutex. I can use Sysinternals’ Process Explorer “Handle View” to find this reference by its name, right click it and close it. What I would like to do is exactly the same thing, just programmatically.
Process X cannot close a handle that has been opened by a process Y - as simple as that. In order to do it, you have to discover which process has opened it, and do it in context of the owner process…
Anton Bassov
I know the name of the process which has opened it and I want to close it from within that process. I do not have access to the handle itself though.
> I know the name of the process which has opened it and I want to close it from
within that process. I do not have access to the handle itself though.
The problem can be solved without any kernel games.
Inject a code into the target process (a la Jeffry Richter, by CreateRemoteThread)
and do what you want.
Of course, you must have enough rights.
CloseHandle is especially easy to inject btw, I rememeber even a sample code
on the web some place… here we are:
http://www.codeproject.com/threads/taskex.asp
-------------- Original message --------------
From: xxxxx@topiks.de
I know the name of the process which has opened it and I want to close it from
within that process. I do not have access to the handle itself though.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thanks Alex, this would be a solution. I found http://www.codeproject.com/system/Task_Manager_Extension.asp
But it does not provide a simple function I could call, but “just” the code from which I could start programming my own solution. I would have thought that maybe the functionality would be common enough to find it ready made in some dll.
You do realize that all of these are “Use at your own risk solutions”. So
I hope this is not for a commercial product, and if it is that you are
going to be nice enough to have a dialog that says “Since you are not
willing or able to cause the release of the desired handle through the
application, so by authorizing this you are allowing us to dink with the
application in ways that can cause it to malfunction and whatever potential
consequences that can have”
You might consider a customer of mine who discovered “Process Exploer” and
its capabilities, and became enamored enough he used it everywhere with the
result he wiped out his corporate server and the last backup.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
> Thanks Alex, this would be a solution. I found
> http://www.codeproject.com/system/Task_Manager_Extension.asp
> But it does not provide a simple function I could call, but “just” the
> code from which I could start programming my own solution. I would have
> thought that maybe the functionality would be common enough to find it
> ready made in some dll.
>
>
Keep in mind that you’re taking your life into your own hands by playing such dangerous games. By the time the injection thread runs, that handle may have already been closed and might be a handle to a different object. Or maybe between when you close the handle and when the target next uses that handle value, the handle value has been recycled and now refers to another option. In the worst case it might even be a “compatible” object of the same type, in which case you could be looking at all sorts of bad problems, like file corruption.
–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
wrote in message news:xxxxx@ntdev…
> I know the name of the process which has opened it and I want to close it from
> within that process. I do not have access to the handle itself though.
The problem can be solved without any kernel games.
Inject a code into the target process (a la Jeffry Richter, by CreateRemoteThread)
and do what you want.
Of course, you must have enough rights.
CloseHandle is especially easy to inject btw, I rememeber even a sample code
on the web some place… here we are:
http://www.codeproject.com/threads/taskex.asp
-------------- Original message --------------
From: xxxxx@topiks.de
> I know the name of the process which has opened it and I want to close it from
> within that process. I do not have access to the handle itself though.
>
> —
> 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
Actually, you can do this without thread injection via clever use of
DuplicateHandle. However, doing so without the cooperation of the target
process is of course extremely dangerous as the process will continue to try
and use the stale handle value.
–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
wrote in message news:xxxxx@ntdev…
> Process X cannot close a handle that has been opened by a process Y - as
> simple as that. In order to do it, you have to discover which process has
> opened it, and do it in context of the owner process…
>
> Anton Bassov
>
> You do realize that all of these are “Use at your own risk solutions”.
I second that, and I should have mentioned it myself.
Use such “sleasy penetrations” for r&d (or when you 100% sure you
know what you are doing).
> But it does not provide a simple function I could call
I remember that about 3-4 years ago I googled out a piece of code
exactly for your purpose, it may be still out there.
It is not a kernel topic anyway, but before list slaves start shooting:
you may also want to look at the article in MSDN by Christophe
Nasarre
http://msdn.microsoft.com/msdnmag/issues/02/06/debug/
[I extended his code and, if you want, I can send you my whole solution, sln, vcproj etc., with 1 bug fixed - I emailed mr. Nasarre but it was too late - which includes remotized handle closing. A good user-mode helper. IMHO, to code remotized Closehandle from scratch will be faster, but you decide.]
-------------- Original message --------------
From: “Don Burn”
> You do realize that all of these are “Use at your own risk solutions”. So
> I hope this is not for a commercial product, and if it is that you are
> going to be nice enough to have a dialog that says “Since you are not
> willing or able to cause the release of the desired handle through the
> application, so by authorizing this you are allowing us to dink with the
> application in ways that can cause it to malfunction and whatever potential
> consequences that can have”
>
> You might consider a customer of mine who discovered “Process Exploer” and
> its capabilities, and became enamored enough he used it everywhere with the
> result he wiped out his corporate server and the last backup.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> wrote in message news:xxxxx@ntdev…
> > Thanks Alex, this would be a solution. I found
> > http://www.codeproject.com/system/Task_Manager_Extension.asp
> > But it does not provide a simple function I could call, but “just” the
> > code from which I could start programming my own solution. I would have
> > thought that maybe the functionality would be common enough to find it
> > ready made in some dll.
> >
> >
>
>
>
> —
> 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
> ----------
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Skywing[SMTP:xxxxx@valhallalegends.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, August 22, 2007 6:12 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to clear handle known by nameActually, you can do this without thread injection via clever use of
DuplicateHandle.
Nice. I’m surprised something like this is possible. Does it really work between processes?
However, doing so without the cooperation of the target
process is of course extremely dangerous as the process will continue to try
and use the stale handle value.
Not so bad if target process uses correct error handling 
Can be very bad if it doesn’t or if it is a file handle and there are unsaved data in memory. Which isn’t the case if I understand correctly.
To OP: this functionality isn’t common enough. It is last resort solution, instead. Actually, it is more hack than solution. How would you like if somebody else randomly closes your handles in unexpected moments? Do you check every API return code and handle all errors appropriately? I do but many people call my code paranoid because they believe there are cases when an API can’t fail. Closing handle from other app would break their assumptions.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
Yes, if you use DUPLICATE_CLOSE_SOURCE, the source handle is ZwClose’d while
attached to the source process. Then you only need to close the (new)
handle in your process after the system call returns, using CloseHandle
(locally).
It is, however, still bad to do this even if the process handles errors.
Say you close a handle to a file object that is periodically written to with
WriteFile. Now, before the next WriteFile call with the stale handle value,
another thread in the same process calls CreateFile and receives the (same,
but now unused) handle value for a *different* file. No error handling will
catch the resulting problem, which is that data gets written to the wrong
file (data corruption).
The assumption that there is some margin of safety only holds true if handle
values are never recycled, which is definitely not the case. Although this
may not happen every time (it is after all a race), there is no way to
protect against it if you are ripping handle values out from under a process
without first telling it to stop using that handle value.
–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
> ----------
> From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> on behalf of Skywing[SMTP:xxxxx@valhallalegends.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Wednesday, August 22, 2007 6:12 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] How to clear handle known by name
>
> Actually, you can do this without thread injection via clever use of
> DuplicateHandle.
>
Nice. I’m surprised something like this is possible. Does it really work
between processes?
> However, doing so without the cooperation of the target
> process is of course extremely dangerous as the process will continue to
> try
> and use the stale handle value.
>
Not so bad if target process uses correct error handling Can be very bad
if it doesn’t or if it is a file handle and there are unsaved data in
memory. Which isn’t the case if I understand correctly.
To OP: this functionality isn’t common enough. It is last resort solution,
instead. Actually, it is more hack than solution. How would you like if
somebody else randomly closes your handles in unexpected moments? Do you
check every API return code and handle all errors appropriately? I do but
many people call my code paranoid because they believe there are cases when
an API can’t fail. Closing handle from other app would break their
assumptions.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
You’re right about handles recycling. I’m not quite sure how serious problem is; it depends on handle allocation algorithm. If it always uses the first free slot in handle table (as one would expect), it is serious problem.
Indeed, for file handles it is always very dangerous technique. For mutextes, as OP wants, handle recycling could cause a deadlock or internal data corruption. As I said, the last resort and for one I’d agree with Don it shouldn’t be used in a commercial product. It seems as terminating target process can be safer.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Skywing[SMTP:xxxxx@valhallalegends.com]
Reply To: Windows System Software Devs Interest List
Sent: Wednesday, August 22, 2007 9:55 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to clear handle known by nameYes, if you use DUPLICATE_CLOSE_SOURCE, the source handle is ZwClose’d while
attached to the source process. Then you only need to close the (new)
handle in your process after the system call returns, using CloseHandle
(locally).It is, however, still bad to do this even if the process handles errors.
Say you close a handle to a file object that is periodically written to with
WriteFile. Now, before the next WriteFile call with the stale handle value,
another thread in the same process calls CreateFile and receives the (same,
but now unused) handle value for a *different* file. No error handling will
catch the resulting problem, which is that data gets written to the wrong
file (data corruption).The assumption that there is some margin of safety only holds true if handle
values are never recycled, which is definitely not the case. Although this
may not happen every time (it is after all a race), there is no way to
protect against it if you are ripping handle values out from under a process
without first telling it to stop using that handle value.–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net
“Michal Vodicka” wrote in message
> news:xxxxx@ntdev…
> > ----------
> > From:
> > xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> > on behalf of Skywing[SMTP:xxxxx@valhallalegends.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Wednesday, August 22, 2007 6:12 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] How to clear handle known by name
> >
> > Actually, you can do this without thread injection via clever use of
> > DuplicateHandle.
> >
> Nice. I’m surprised something like this is possible. Does it really work
> between processes?
>
> > However, doing so without the cooperation of the target
> > process is of course extremely dangerous as the process will continue to
> > try
> > and use the stale handle value.
> >
> Not so bad if target process uses correct error handling
> if it doesn’t or if it is a file handle and there are unsaved data in
> memory. Which isn’t the case if I understand correctly.
>
> To OP: this functionality isn’t common enough. It is last resort solution,
> instead. Actually, it is more hack than solution. How would you like if
> somebody else randomly closes your handles in unexpected moments? Do you
> check every API return code and handle all errors appropriately? I do but
> many people call my code paranoid because they believe there are cases when
> an API can’t fail. Closing handle from other app would break their
> assumptions.
>
> 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
>
> it depends on handle allocation algorithm. If it always uses the first free slot
in handle table (as one would expect)
IMHO, this is the case.
Yes, if you use DUPLICATE_CLOSE_SOURCE, the source handle is ZwClose’d while
attached to the source process. Then you only need to close the (new)
handle in your process after the system call returns, using CloseHandle
(locally).
Elegant, thanks, Skywing.
I had a lot remoting stuff at hand ready, so for me it was simpler to add
a couple of lines in the DLL being injected, but if remoted closure is all that’s
needed, I would prefer duplication.
-------------- Original message --------------
From: “Michal Vodicka”
> You’re right about handles recycling. I’m not quite sure how serious problem is;
> it depends on handle allocation algorithm. If it always uses the first free slot
> in handle table (as one would expect), it is serious problem.
>
> Indeed, for file handles it is always very dangerous technique. For mutextes, as
> OP wants, handle recycling could cause a deadlock or internal data corruption.
> As I said, the last resort and for one I’d agree with Don it shouldn’t be used
> in a commercial product. It seems as terminating target process can be safer.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
> > ----------
> > From:
> xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on
> behalf of Skywing[SMTP:xxxxx@valhallalegends.com]
> > Reply To: Windows System Software Devs Interest List
> > Sent: Wednesday, August 22, 2007 9:55 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] How to clear handle known by name
> >
> > Yes, if you use DUPLICATE_CLOSE_SOURCE, the source handle is ZwClose’d while
> > attached to the source process. Then you only need to close the (new)
> > handle in your process after the system call returns, using CloseHandle
> > (locally).
> >
> > It is, however, still bad to do this even if the process handles errors.
> > Say you close a handle to a file object that is periodically written to with
> > WriteFile. Now, before the next WriteFile call with the stale handle value,
> > another thread in the same process calls CreateFile and receives the (same,
> > but now unused) handle value for a different file. No error handling will
> > catch the resulting problem, which is that data gets written to the wrong
> > file (data corruption).
> >
> > The assumption that there is some margin of safety only holds true if handle
> > values are never recycled, which is definitely not the case. Although this
> > may not happen every time (it is after all a race), there is no way to
> > protect against it if you are ripping handle values out from under a process
> > without first telling it to stop using that handle value.
> >
> > –
> > Ken Johnson (Skywing)
> > Windows SDK MVP
> > http://www.nynaeve.net
> > “Michal Vodicka” wrote in message
> > news:xxxxx@ntdev…
> > > ----------
> > > From:
> > > xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com]
> > > on behalf of Skywing[SMTP:xxxxx@valhallalegends.com]
> > > Reply To: Windows System Software Devs Interest List
> > > Sent: Wednesday, August 22, 2007 6:12 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re:[ntdev] How to clear handle known by name
> > >
> > > Actually, you can do this without thread injection via clever use of
> > > DuplicateHandle.
> > >
> > Nice. I’m surprised something like this is possible. Does it really work
> > between processes?
> >
> > > However, doing so without the cooperation of the target
> > > process is of course extremely dangerous as the process will continue to
> > > try
> > > and use the stale handle value.
> > >
> > Not so bad if target process uses correct error handling Can be very bad
> > if it doesn’t or if it is a file handle and there are unsaved data in
> > memory. Which isn’t the case if I understand correctly.
> >
> > To OP: this functionality isn’t common enough. It is last resort solution,
> > instead. Actually, it is more hack than solution. How would you like if
> > somebody else randomly closes your handles in unexpected moments? Do you
> > check every API return code and handle all errors appropriately? I do but
> > many people call my code paranoid because they believe there are cases when
> > an API can’t fail. Closing handle from other app would break their
> > assumptions.
> >
> > 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
> >
>
> —
> 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
Thanks a lot to all of you. I apologize for being a bit off topic for this list.
I am aware, that this is dangerous and yes, it is a hack for letting me progress with r&d work until the vendor of a component I use has fixed the issue with the handle.
@Alex Shvedov: I would be very grateful for your solution.
Best regards,
Torsten Pietrek