could some one explain in details about force unlock?

[pli]

Hi, experts,

I heard that at eraser 6.x compared with eraser 5.x, there is capability to force unlock on files. Could someone shed some lights on detailed steps here? I did take a look at source code and not sure if I understand how code is to let other process which locks the file to release the lock. It would help that someone could outline the steps here.

Thanks very much.

[Joel]

1. List all open handles on the system using the NT API
2. Resolve the name for each open handle
3. Match the handle to the file being blocked
4. Close the handle out-of-process

[pli]

Thanks a lot Joel for this. I could understand the code now. It is very similar to some source code I got from here: http://forum.sysinternals.com/howto-enu ... 18892.html. I guess the tricky part is that name resolution call could hang which I saw that you used a separate thread to solve it.

From my experience of running of that source code in C++ for getting locked handles, I found out that it won't listed the file handles of the EXE itself and dll it loaded. For example if a exe is running while I want to erase that exe, I would think that eraser won't resolve this type of file lock. I guess that close handle out of process won't work for this type of lock. The only way to do this would be killing that process. Maybe Eraser 6.x could identify this type of lock and do a kill to resolve the file lock in future enhancement. Just my thoughts.

[Joel]

Thanks a lot Joel for this. I could understand the code now. It is very similar to some source code I got from here: http://forum.sysinternals.com/howto-enu ... 18892.html. I guess the tricky part is that name resolution call could hang which I saw that you used a separate thread to solve it.

Yes, that was the inspiration. I took the general idea and re-implemented it in C++/CLI.

From my experience of running of that source code in C++ for getting locked handles, I found out that it won't listed the file handles of the EXE itself and dll it loaded. For example if a exe is running while I want to erase that exe, I would think that eraser won't resolve this type of file lock.

I think it is in a separate type we're not enumerating. The name resolution thread will only run if the handle type is one of a select few. File handles are different from processes because processes are memory-mapped files and not real file handles per se (naturally, the kernel handle type would be different.)

I guess that close handle out of process won't work for this type of lock. The only way to do this would be killing that process. Maybe Eraser 6.x could identify this type of lock and do a kill to resolve the file lock in future enhancement. Just my thoughts.

You sound like you know your code, how about a patch?

[pli]

thanks a lot, Joel.

I think it is in a separate type we're not enumerating. The name resolution thread will only run if the handle type is one of a select few. File handles are different from processes because processes are memory-mapped files and not real file handles per se (naturally, the kernel handle type would be different.)

I saw that in your code, however based on my testing with code from http://forum.sysinternals.com/howto-enu ... 18892.html, we won't get those exe and dll module handle there, here is my testing C program to echo out all the handle name from sqlitespy.exe:

Code: Select all

[0x10] File: \Device\HarddiskVolume1\Windows
[0x1c] File: \Device\HarddiskVolume1\temp\eraser_test\backup\userview
[0x20] File: \Device\HarddiskVolume1\Windows\winsxs\x86_microsoft.windows.common
-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2
[0xd8] File: \Device\HarddiskVolume1\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b
3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57
[0xf0] File: \Device\KsecDD
[0x100] File: \Device\HarddiskVolume1\Windows\winsxs\x86_microsoft.windows.c..-c
ontrols.resources_6595b64144ccf1df_6.0.7600.16385_en-us_581cd2bf5825dde9
[0x104] File: \Device\HarddiskVolume1\Windows\winsxs\x86_microsoft.windows.c..-c
ontrols.resources_6595b64144ccf1df_6.0.7600.16385_en-us_581cd2bf5825dde9\comctl3
2.dll.mui
[0x108] File: \Device\HarddiskVolume1\Windows\Fonts\StaticCache.dat
[0x118] File: \Device\HarddiskVolume1\temp\eraser_test\backup\userview\SQLiteSpy
.db3


You sound like you know your code, how about a patch?

Sure, would like to. I am just wondering how I could contribute since C# is not really fit for my skill sets. The best way I could do is that I could give your some of C++ code. Or maybe you could write some interface for CLI based on your needs, I could implement the C++ code for you. The code won't be too complex. I think that complex part is how to plug into the Eraser framework which is a little daunting to me.

[Joel]

That is indeed very strange. I'm sure there should be some internal structure we're missing. It's times like this I wish I've got some of those NT Undocumented books (by Russinovich et. al)

[pli]

It is rather cool what these undocumented API could do. . I did have temptation to read that book as well, however it is rare that I need to resort to undocumented API, so I never really go down the path.

[Joel]

We try not to, but when there's reason to, and when the undocumented API is relatively well accepted... why not?

Okay, I'm pushing it here.