12 replies to this topic

[CaptainClucks]

This was made with the intention to mimic the well known unlocker.exe.

Credits to Yashied, monoceres, wraithdu, Manko, Trancexx, JScript, Larry, SmOke_N, mrRevoked, Melba23 & guinness.

Spoiler

Yashied for his winapiex udf which I took a function from that enumerates handles and an update to a function he made that I use that seems to have enabled operation on 64bit systems now.
monoceres and wraithdu for information and code I took from them in a previous thread they created where they were working on something very similar.
Manko for a post where he was doing something similar where as I got information for the named pipe handling area of the script.
guinness for helping me out when beginning this by pointing out particular functions that were needed to get object handle information.
Also thanks to JScript, Larry, SmOke_N and mrRevoked for _ProcessGetPath.
Trancexx for the code that I use to determin what Icon to use for the list view items (on 32bit systems only, probably something I did wrong).
Melba23 for the functions I use to re-size the gui, I think they come from him.

 Unlocker Source.rar   11.01K   578 downloads - [152] Previous Downloads

Alternately, download the exe from my site here, but sometimes my site is offline (a lot).
Some say taking and closing handles from a process can produce unwanted side effects in the targeted process, use with caution.

History

Spoiler

4/7/2012 - fixed an error I made when re-uploading that would cause the script to not unlock files.
4/7/2012 - Fixed other errors, removed rediming of arrays which seemed to have made this very noticeably faster and also commented out the micro sleep calls So now the list is populated very fast in comparison to before but will use more CPU.
4/18/12 - Added support for unlocking dlls using code by Smoke_N and removed useless additions.
5/26/12 - Added an update to support operation on 64bit systems thanks to Yashied

Edited by ApudAngelorum, 26 May 2012 - 06:36 PM.

[guinness]

I keep getting the an error message saying 'Error Code: 1 Extended 13.' I'm using the latest version on Windows 7 x64.

Edit: Credits to me? What did I do?

Edited by guinness, 06 April 2012 - 07:01 PM.

[TheSaint]

Thanks for sharing!

[BrewManNH]

I'm getting the same error:

---------------------------
Error Code: 1 Extended: 13
---------------------------
The application has encounterd an error and will now close, sorry for the inconviniance.
---------------------------
OK
---------------------------

Also, don't limit the FileSelectFolder to the homedrive, because that's not allowing me to change drives to any other drive. My homedrive is set to a network share with only a few folders on it, none of which should be locked.

BTW, inconvenience is spelled wrong in that error message.

[CaptainClucks]

I keep getting the an error message saying 'Error Code: 1 Extended 13.' I'm using the latest version on Windows 7 x64.

Edit: Credits to me? What did I do?

Well... I guess this would be a good time to post this...



But in all seriousness, I haven't tested this on any x64 bit systems and your post might prove it doesn't work on them, but aside from that I've tested this on windows xp sp3 x86 and windows 7 x86.

And the error you're getting means that the File and Process object handle types were not found, which is File = 28 and process = 5 on windows xp and windows 7 I believe.

And why not credits to you? Remember this thread? If it weren't for your help there this probably wouldn't be here.

I'm getting the same error:

Also, don't limit the FileSelectFolder to the homedrive, because that's not allowing me to change drives to any other drive. My homedrive is set to a network share with only a few folders on it, none of which should be locked.

BTW, inconvenience is spelled wrong in that error message.

Thanks for pointing that out, I hadn't noticed and too bad scite doesn't spell check like my browser

Ieme fix that..

Thanks for sharing!

You're welcome!

Edited by ApudAngelorum, 06 April 2012 - 08:34 PM.

[guinness]

Just a question, but the functions you used from WinAPIEx.au3 did you alter them in anyway, because the UDF has been tested on x64 thoroughly.

[CaptainClucks]

Just a question, but the functions you used from WinAPIEx.au3 did you alter them in anyway, because the UDF has been tested on x64 thoroughly.

If you notice, I only took the one function from that UDF and it's ZwQuerySystemInformation, and since you got to error level 13 returned in the extended macro, then this means the function taken from winapiex works flawlessly, I don't have an x64 bit machine handy but maybe you could try commenting out this line~

If DllStructGetData($tHandle, 1) <> @AutoItPID Then ContinueLoop; only search our process for now

What it's doing is making sure we're trying to look for the object handle types in our process only (I.e., File = 28 on win xp and file = 25 on vista), but I doubt it will work, there must be something else at play here..

For an object of type file, the value bObjectType in SYSTEM_HANDLE is 28 in Windows XP, Windows 2000, and Window 7; 25 in Windows Vista; and 26 in Windows 2000.

If you comment out that line then maybe it will work? give it a try.

Or else just populate the $FileObject array yourself with the valid object type values depending on your system, read the link above.
On windows vista this would probably be right.

$aObject[$Ready][0] = DllStructGetData($tHandle, 2);return it so we can use it to find them
$aObject[$Ready][1] = DllStructGetData($tString, 1)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

$aObject[$Ready][0] = 25
$aObject[$Ready][1] = "File"

Edited by ApudAngelorum, 06 April 2012 - 08:38 PM.

[guinness]

I tried commenting out but to no avail. I'll have a look over the next week or so. Thanks.

[wraithdu]

monoceres started a script like this a while back, and I did some work on it too. It proved tricky and ultimately incomplete. Maybe you can borrow something from it: http://www.autoitscript.com/forum/topic/83145-basic-file-unlocker/

[CaptainClucks]

monoceres started a script like this a while back, and I did some work on it too. It proved tricky and ultimately incomplete. Maybe you can borrow something from it: http://www.autoitscript.com/forum/topic/83145-basic-file-unlocker/

Thanks, I've actually already scavenged that post, hence the credits to monoceres, what I took from there that I needed was the part of the script that determines what drive label to use. If you downloaded the script, look closely and you'll recognize some of the code, I didn't change the variables.

 Local $struct = DllStructCreate("char[255];")
Local $Temp = DriveGetDrive("ALL")
Local $drivesinfo[UBound($Temp) - 1][2]
For $I = 0 To UBound($drivesinfo) - 1
  $drivesinfo[$I][0] = $Temp[$I + 1]
  DllCall($hKERNEL32, "dword", "QueryDosDevice", "str", $drivesinfo[$I][0], "ptr", DllStructGetPtr($struct), "dword", 255)
  $drivesinfo[$I][1] = DllStructGetData($struct, 1)
Next
;~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    DllCall($hNTDLL, "ulong", "NtQueryObject", "ptr", $hObject, "int", 1, "ptr", DllStructGetPtr($poti), "ulong", DllStructGetSize($poti), "ulong*", "")
    $devicestr = DllStructCreate("wchar[" & Ceiling(DllStructGetData($poti, "Length") / 2) & "];", DllStructGetData($poti, "buffer"))
    $devicestr = DllStructGetData($devicestr, 1)

Edit: wow, after taking a closer look I noticed that code is actually by you, let me fix my first post

Edited by ApudAngelorum, 06 April 2012 - 09:20 PM.

[CaptainClucks]

I tried commenting out but to no avail. I'll have a look over the next week or so. Thanks.

Ok, so I hit up a friend with a 64bit system and I tried debugging the script for a few minutes and found out that it is in fact the function that I previously said executed flawlessly, it turns out that even in its original form (straight out of the winapiex UDF) it does not return the desired information.

The function in question is _WinAPI_EnumProcessHandles() which should return file handles in an array and is basically the heart of this script...

MSDN mentions nothing about incompatibility on any system so I'm guessing this is a bug in the function?

Anyway, with a little help from the community running 64bit OSs, this could turn out to be a pretty handy tool, I use it a lot to unlock directories locked by scite and other apps, but as for debugging this for 64bit systems, I just don't have the resources or the know how to do it.

Edited by ApudAngelorum, 06 April 2012 - 11:30 PM.

[CaptainClucks]

Added support for 64bit systems as it seems thanks to yashied for an update he made to a function from his winapiex udf that I use that is critical to everything in the script.

[wazer]

i really liked unlocker back in the days on XP, but then i moved to windows 7/8, since then unlocker has never really worked well,

Now i saw this topic, yours dont work as i expected, i run it, select the folder then it gets stuck at 3/6, at last the windows ask if you want to end it since its not responding anymore.

So is there an update coming for windows 8?