LockedList plug-in

If you are using IsFileLocked on your main application executable then you should use the AddModule function instead. AddCustom+IsFileLocked is really an alternative to AddFile (for open file handles). AddModule is specifically for exe/dll/ocx.

Stu

Ok thanks for your advise. I will consider that.

Hi Stu,
after changing to AddModule() I remembered again, why I decided to use AddCustom() back then.
When I use AddModule the title of the application is unpredictable, it just gets a random name and also the icons are sometimes stored separately. Here is the output of the locked list with different versions of CINEMA 4D and 3ds Max:

1 [52212] - Console - CINEMA 4D 64 Bit.exe
2 [55492] - MAXScript Debugger - 3dsmax.exe
3 [54784] - V-Ray messages - 3dsmax.exe
4 [55396] - NVOGLDC invisible - CINEMA 4D 64 Bit.exe
5 [55588] - NVOpenGLFbo - CINEMA 4D 64 Bit.exe
6 [55860] - MAXON Online Updater - CINEMA 4D 64 Bit.exe
7 [55444] - Warning Loading Plug-in DLL - 3dsmax.exe
8 [55040] - MAXScript Debugger - 3dsmax.exe

Is there any possibitly to pass an explicit title or icon to AddModule or is there an alternative which I could use instead of IsFileLocked when using AddCustom?

Would it be preferable to use the file description instead (i.e. under Properties -> Details)? I believe this is what Task Manager uses in later versions of Windows.

Stu

I think the optimal solution would be the title of the main window, because the description is the same for different versions of the application. But the description would be a satisfying solution 🙂

New version:

3.0.0.2 - 5th August 2014
* Added CloseProcess function.
* Improved application window caption lookup to find "main" windows (no owner).

Stu

Why is this ? : http://nsis.sourceforge.net/File:LockedList.zip

Warning: This file type may contain malicious code. By executing it, your system may be compromised.

This is a joke?

I don't get that, it's fine for me. Maybe it's your antivirus?

Originally Posted by stass View Post

This is a joke?

What is giving you that message? Your antivirus software or Internet Explorer? I have reuploaded with no upx compression - please try downloading again.

Stu

This post is on page http://nsis.sourceforge.net/File:LockedList.zip
Page open the Opera browser. Antivirus is disabled !
Screenshot : http://www.mediafire.com/?waxa911a5pt74tr

Originally Posted by stass View Post

This post is on page http://nsis.sourceforge.net/File:LockedList.zip
Page open the Opera browser. Antivirus is disabled !
Screenshot : http://www.mediafire.com/?waxa911a5pt74tr

Oh right... It says that for all files on the NSIS Wiki. It's a general warning and not specific to my plug-in.

Stu

Wow, many thanks dude! Will test it in the next days. 👍👍

little diference with LockedList:😁ialog behavior

I have found that at latest version "3.0.0.2 RC2" the behavior is a little different from "3.0.0.1"...

Occurs when you have the dialog as first dialog, when the process is found the dialog is not called, but on RC2 the dialog appears anyway, then leaves because there is no process running with the given name.

Here´s a piece of used code.

 LockedList::AddModule \cmd.exe
  LockedList::FindProcess "cmd.exe"
  Pop $R0
  ${If} $R0 != ''
  LockedList::Dialog /autonext \
          ....
  ${EndIf} 

Many thanks!

New version:

3.0.0.3 - 7th August 2014
* FindProcess did not always push "no" (/yesno) or an empty string onto the stack when no processes were running.

shadowpoa your code can be improved:

Function ...



  !insertmacro MUI_HEADER_TEXT ... ...



  LockedList::FindProcess /yesno cmd.exe

  Pop $R0

  ${If} $R0 == no

    Abort

  ${EndIf}



  LockedList::AddModule \cmd.exe

  LockedList:😁ialog

  Pop $R0



FunctionEnd

Using /yesno is more suitable here as otherwise, if the process is running, you will end up leaving two strings on the stack (which could have side-effects with other code.) I have also called Abort to skip the custom page (rather than jump over the plug-in calls).

Stu

Just wanted to let you know, that the application name lookup now works perfect!

Originally Posted by Satara View Post

Just wanted to let you know, that the application name lookup now works perfect!

Excellent, thanks! 🙂

Stu

Originally Posted by Afrow UK View Post

New version:shadowpoa your code can be improved:

Function ...



  !insertmacro MUI_HEADER_TEXT ... ...



  LockedList::FindProcess /yesno cmd.exe

  Pop $R0

  ${If} $R0 == no

    Abort

  ${EndIf}



  LockedList::AddModule \cmd.exe

  LockedList:😁ialog

  Pop $R0



FunctionEnd

Using /yesno is more suitable here as otherwise, if the process is running, you will end up leaving two strings on the stack (which could have side-effects with other code.) I have also called Abort to skip the custom page (rather than jump over the plug-in calls).

Stu

Wow! I did not think of that!

Thanks so much for the 64-bit support and continued updates 🙂 That makes it much more useful

It is known that My.dll used (busy) process - explorer.exe

Why, if :

LockedList::AddModule "My.dll"
LockedList:: Dialog

LockedList shows nothing ? explorer.exe as if ignored plugin ...

And the second question : is it possible to make the plugin restart the explorer.exe ?
It is very necessary and useful feature !
From experience we know that 99% of ShelDll often busy or it is locked explorer.exe.

Are you using the 64-bit support (LockedList64.dll)?

Attached a script which will restart Windows Explorer (based on http://stackoverflow.com/questions/5...plorer-process).

Stu

Afrow UK
I, explorer.exe is not displayed on x32 ( LockedList.dll ) Tested on Windows XP SP3x32 Rus
and Windows 7 SP1x32 Rus .

Thanks for RestartExplorer !

LockedList64.dll not working on Unicode builds

I have an Unicode setup including LockedList.dll (unicode) and LockedList64.dll (there's only one).
Detection of x64 processes doesn't work; setup compiles and run, but no process is detected.

After some debug I landed to line 2751 of file LockedList.cpp:

if (pcds->dwData == 1 && pcds->cbData == sizeof(FILE_INFORMATION64) && g_pEnumSystemProcesses64Options) {

...

} 

Debugger show these values:
pcds->dwData = 1
pcds->cbData = 808
sizeof(FILE_INFORMATION64) = 1584
...and the if block is never executed.

The 808 length come from the x64 DLL, and it's wrong because the x86 version is compiled with Unicode so its TCHARs are longer.

struct FILE_INFORMATION64 {

  DWORD  ProcessId;

  TCHAR  FullPath[MAX_PATH];

  TCHAR  ProcessDescription[MAX_PATH];

  HWND__* POINTER_64 ProcessHWND;

  TCHAR  ProcessFullPath[MAX_PATH];

  UINT   FileNumber;

  UINT   TotalFiles; 

};

#endif 

Just recompiling the x64 version with Unicode enabled fixed the bug on my side, and x64 processes are now enumerated correctly.

I think you need to provide both the dll in both ANSI/Unicode versions and fix the documentation.

Cheers
Claudio

I've attached here the x64 Unicode build of the plugin, in case someone needs it...

I have fixed the issue. LockedList64.dll was meant to be built with Unicode but I must have included the ANSI build in the Zip file. Also the ANSI LockedList.dll will now convert the FILE_INFORMATION64 contents to ANSI (so again, no need for two LockedList64 builds).

Stu

LockedList::AddFolder "$INSTDIR"
LockedList:😁ialog

It shows me several processes as expected (they are really lock some files).

Question:
Is it possible to excluded some processes (probably by name) from list?

Thanks in advance

Rename command fails although there's no lock

Hi,

I noticed a while ago that in case I am trying to rename a folder that is currently open in Windows Explorer, the operation sometimes fails. In order to try and figure out what is happening, I created a small script that uses the LockesList plugin (to see if anything is really locked):
code:

Name `LockedList Test`



OutFile LockedListTest.exe

RequestExecutionLevel admin



!define origFolder "C:\Program Files (x86)\Original"

!define newFolder "C:\Program Files (x86)\Original_Renamed"



Page Custom LockedListShow

Page instfiles



Function LockedListShow

  LockedList::AddFolder "${origFolder}"

  LockedList:ialog /autonext /searching  "Searching for locked files in ${origFolder}"

  Pop $R0

  MessageBox MB_OK "$R0"

FunctionEnd



Function renameFolder

	ClearErrors

	MessageBox MB_OK "Renaming ${origFolder} to ${newFolder}"

	Rename "${origFolder}" "${newFolder}"

	IfErrors 0 done

		MessageBox MB_OK "Failed to rename"

done:

	ClearErrors

FunctionEnd



Section

	Call renameFolder

SectionEnd

I also have the following folder structure:
\OriginalI then execute LockedList.exe in different scenarios.

1. All Windows Explorer windows closed
2. Windows Explorer open with folder "Original" displayed
3. Notepad open with Test.txt
4. Windows Explorer open with folder Original\config displayed

Here are the results:
Case 1: LockedList returns "next" as no locks found, folder is renamed
Case 2: LockedList returns "next" as no locks found, folder is renamed
Case 3: LockedList displays Notepad.exe as a lock. I close it and it then returns "next". Rename failes (as folder Original\config displayed in Windows Explorer - since I opened the txt file)
Case 4: LockedList returns "next" as no locks found, rename failes.

Now I found this a bit "weird". Rename works ok if only the folder to be renamed is displayed in Windows Explorer but fails as soon as any subfolders thereof are displayed. Also, LockedList finds no locks and manual renaming also works.

Any idea why this might happen? Is this a problem with the plugin maybe (that it doesn't detect these locks)? Or with NSIS, since every other rename works when it reports that the files are locked?

Thanks,
Mircea

I know this plug-in hasn't really been looked at for a while, but anyone gotten it working finding x64 processes on Windows 10?

From what I can tell, it is not detecting my 64bit DLL's

It detects the 64bit EXE and I can get it detect 32bit DLLs using AddModule

I have the code:
${If} ${RunningX64}
File /oname=$PLUGINSDIR\LockedList64.dll `${NSISDIR}\Plugins\LockedList64.dll`
${EndIf}

And I have the (latest) LockedList64.dll that supposedly fixed the ansi-unicode issue.

EDIT:
An addendum

It is *related* to 64 bit but not what I thought. Not sure what I think yet.

Looking for a windows module "bcrypt.dll" LockedList finds *all* applications using it, AS LONG as they are using :
C:\Windows\SysWOW64\bcrypt.dll

if they are using:
C:\windows\System32\bcrypt.dll

it does not detect the file as locked and does not detect any EXE's using it.

(I am searching for "\bcrypt.dll")

The problem program we have is a 64 bit Win32 program locking one of our 64 bit files.

LockedList does not detect a SINGLE file that program has locked (but can detect the program is running) - odd.

Addendum 2:
Hilarious side note:

LockedList::AddModule "C:\windows\System32\bcrypt.dll"
finds all program using : C:\Windows\SysWOW64\bcrypt.dll

LockedList::AddModule "C:\Windows\SysWOW64\bcrypt.dll"
finds no programs at all locking that file

I am using Process Explorer to determine what DLL's the programs have locked

The 32-bit layer translates system32 to syswow64. You can use a backdoor to get the real folder: $windir\sysnative\bcrypt.dll (Only works in 32-bit programs running on 64-bit Vista or higher)

silent install & locked list plug-in

Is there a way to tell the locked list plug-in to just force clear (kill) any blocking processes and continue with the silent install? i.e. when the "/S" option is used or perhaps adding a switch with the /S that a user can invoke to indicate that.

Multiple Acrobat files show as one

Afrow, a very impressive piece of programing. I have a problem trying to close two pdf files.

Two pdf files are open that need to be closed before continuing, with different titles (ExampleA and ExampleB). Example B was the last one viewed so the title in the locked list window shows only Example B, not Example A even though both are open.

When testing your lock list, only one instance of Acrobat shows, and it shows only the title for ExampleB. If I close ExampleB but leave Example A open, the list does not update, it still shows ExampleB as being locked.

If I have an unrelated pdf fie also open, SomethingElse, if that is the last Acrobat file looked at then that title is the one displayed on the locked list. The two pdf files that are actually locked don't show at all in this case. If I close the two locked files then SomethingElse remains stubbornly in the Locked List window, even though it has nothing to do with the locked files that I am interested in.

I've tried AddFiles, AddFolder and AddCaption with no success.

Is it possible to:

(a) show two separate lines showing the two separate pdf files and
(b) have the correct title for each and
(c) ignore unrelated pdfs that might also be open

in the locked list window?