LockedList plug-in

Does the current LockedList version (19 April 2015) supports the NSIS 2.51 version and Windows 2003 Server x64?

I have a problem when using LockedList which are let out after the version from 12 July 2012.
In the LockedList version from 12 July 2012 - everything is fine.

How to reproduce:
- compile the example of LockedListFolder.nsi
- start the received installer on Windows 2003 Server x64
- go to the page with locked files
- progress remains on 0%, and the CPU is used for 100%. It is possible to wait infinitely, but this process never comes to an end.

When using the same installer on the Windows XP (kernel is the same as on 2003 Server) - everything is fine.
We are also tested on all Windows after XP (x86 and x64) - everything is fine.

I have a trouble with LockedList plugin in XP x64 (Professional). As well as AfzaL (27th May 2016 11:58) - processor 100%, plugin progress 0% and complete, but hourglass and freeze. Sorry for my english. Can developer help? I can send all information, what may help.

With some expirement founded, where trouble in source code. Under WinXP 64-bit (and probably 64-bit Win2003) while-loop in function "static SYSTEM_HANDLE_INFORMATION* GetSystemHandleInformation()" not breaking. NtQuerySystemInformation, which used in this function return in variable "size" always value is 0. 🙁

This articles help me very much!





Tommorow, I'll do some tests and post the solution here, but need to recompile LockedList plugin from "Contrib" dir (or maybe developer can release new version).

P.S. Thanks for this very good plugin!

Ok. Mayby my solution is not beautiful, but it works.

In source function GetSystemHandleInformation() this:

  NtQuerySystemInformation(SystemHandleInformation, pSysHandleInformation, sizeof(SYSTEM_HANDLE_INFORMATION), &size)
  GlobalFree(pSysHandleInformation); 

need replace to something this:

  int iSHI = sizeof(SYSTEM_HANDLE_INFORMATION);
  while (NtQuerySystemInformation(SystemHandleInformation, pSysHandleInformation, iSHI, &size)
      == STATUS_INFO_LENGTH_MISMATCH)
  {
    iSHI = iSHI * 2;
    GlobalFree(pSysHandleInformation);
      pSysHandleInformation = (SYSTEM_HANDLE_INFORMATION*)GlobalAlloc(GPTR, iSHI);
  } 

I don't have more time for re-check this solution. Sorry, but maybe somebody help it.

Perhaps something more like this:

size = sizeof(SYSTEM_HANDLE_INFORMATION);
while (NtQuerySystemInformation(SystemHandleInformation, pSysHandleInformation, size, &size)
  == STATUS_INFO_LENGTH_MISMATCH)
{
  GlobalFree(pSysHandleInformation);
  pSysHandleInformation = (SYSTEM_HANDLE_INFORMATION*)GlobalAlloc(GPTR, size);
} 

The function returns the length you need, so there is no point expanding the buffer over and over until it succeeds.

The function returns the length you need, so there is no point expanding the buffer over and over until it succeeds.

Thanks! I'll try it on Monday and write the result.

JasonFriday13 (29th July 2017, 07:53)

Unfortunately your solution don't work (also plugin go to an infinite loop only in XP 64 bit and 2003 64-bit). I don't know why it happens. =(

Some of the NT info classes don't know the size, you just have to do something like: for (UINT s = 1024;; s *= 2) { p = alloc(s); if (!Ntxxx(..,p,s,..)) break; free(p); }

I'm somewhat confused on how this plugin is maintained. Is there an SVN or Git repo where the latest version can be pulled from? The version I could find had a problem when using an ANSI NSIS in combination with LockedList64.dll. It would detect the applications twice and the second instance would have a screwed up name.

The cause of this was the conversion of the unicode returned by LockedList64.dll to ANSI which didn't terminate the ANSI string. As a result there was rubbish at the end of the string and hence the name didn't match the one already found by the 32-bit search.

The culprit was this code:

WideCharToMultiByte(CP_ACP, WC_COMPOSITECHECK, pfile->FullPath, lstrlenW(pfile->FullPath), file.FullPath, sizeof(file.FullPath), NULL, NULL);
WideCharToMultiByte(CP_ACP, WC_COMPOSITECHECK, pfile->ProcessDescription, lstrlenW(pfile->ProcessDescription), file.ProcessDescription, sizeof(file.ProcessDescription), NULL, NULL);
WideCharToMultiByte(CP_ACP, WC_COMPOSITECHECK, pfile->ProcessFullPath, lstrlenW(pfile->ProcessFullPath), file.ProcessFullPath, sizeof(file.ProcessFullPath), NULL, NULL);

And I fixed it by replacing it with this:

WideCharToMultiByte(CP_ACP, WC_COMPOSITECHECK, pfile->FullPath, -1, file.FullPath, sizeof(file.FullPath), NULL, NULL);
WideCharToMultiByte(CP_ACP, WC_COMPOSITECHECK, pfile->ProcessDescription, -1, file.ProcessDescription, sizeof(file.ProcessDescription), NULL, NULL);
WideCharToMultiByte(CP_ACP, WC_COMPOSITECHECK, pfile->ProcessFullPath, -1, file.ProcessFullPath, sizeof(file.ProcessFullPath), NULL, NULL);
file.FullPath[sizeof(file.FullPath) - 1] = 0;
file.ProcessDescription[sizeof(file.ProcessDescription) - 1] = 0;
file.ProcessFullPath[sizeof(file.ProcessFullPath) - 1] = 0;

Possibly this got fixed before by someone else - and possibly other might want this fix too - hence my question where I could find the latest version and/or how to push a fix to it?

Thanks, K

Hi,

I have a issue. If "SomeFile.dat" is opened then this code hangs:

Function SilentSearchCallback
  
  Pop $R0
  Pop $R1
  Pop $R2
  ; do nothing
  Push true
  
FunctionEnd
...
  LockedList::AddFile \SomeFile.dat ; <- add only single file, no modules, no classes, no more
  GetFunctionAddress $R0 SilentSearchCallback
  LockedList::SilentSearch $R0 ; <- hangs here
  Pop $R0
... 

OS is Win7 x64. How to fix it?

I found issue cause. Kaspersky AV affects the speed of handle enumeration.

Originally Posted by MisterK View Post

I'm somewhat confused on how this plugin is maintained. Is there an SVN or Git repo where the latest version can be pulled from? The version I could find had a problem when using an ANSI NSIS in combination with LockedList64.dll. It would detect the applications twice and the second instance would have a screwed up name.

The cause of this was the conversion of the unicode returned by LockedList64.dll to ANSI which didn't terminate the ANSI string. As a result there was rubbish at the end of the string and hence the name didn't match the one already found by the 32-bit search.

The culprit was this code:


And I fixed it by replacing it with this:


Possibly this got fixed before by someone else - and possibly other might want this fix too - hence my question where I could find the latest version and/or how to push a fix to it?

Thanks, K

The first three lines of your fix are enough. Following to MSDN for WideCharToMultiByte:

If this parameter is -1, the function processes the entire input string, including the terminating null character. Therefore, the resulting character string has a terminating null character, and the length returned by the function includes this character.

I want to check whether a text file is locked, if yes, i want to get list of processes that have locked it.

LockedList::IsFileLocked is telling correctly that the .txt file is locked or not.
and so can this or any nsis plugin do the second?

If anyone interested, i've solved the above issue by using Handle.exe:

Originally Posted by gekutu@gmail.com View Post

The first three lines of your fix are enough. Following to MSDN for WideCharToMultiByte:

If this parameter is -1, the function processes the entire input string, including the terminating null character. Therefore, the resulting character string has a terminating null character, and the length returned by the function includes this character.

May well be, but it still doesn't answer my question how/where this plugin is maintained and hence where such fixes could be sent to as pull-requests or whatever ...

Originally Posted by MisterK View Post

May well be, but it still doesn't answer my question how/where this plugin is maintained and hence where such fixes could be sent to as pull-requests or whatever ...

I don't know if the original author is still around. You are allowed to post improved versions to the NSIS wiki.

I made a GitHub repo from the last version: https://github.com/DigitalMediaServer/LockedList

I think I've fixed the two last bugs discussed in this thread - the null termination of the ANSI strings: https://github.com/DigitalMediaServe...ce4426ecd73730

...and the hang on XP and 2003 64 bit: https://github.com/DigitalMediaServe...64bf573eb86d8e

The clues were already in this thread, the endless loop was because NtQuerySystemInformation returned size 0 (I took the trouble of installing a XP 64 VM so the fix has been verified). The following loop that doubled the size never finished because 0 * 2 = 0.

I have no intention of "maintaining" the plugin as such - but I didn't want to use it with the known bugs. I figured that by having that GitHub repo, there is a place where people can submit fixes if they find problems, and I can build the updated DLLs so that they are downloadable from "releases".

I'm not sure what to do with the version number though - it's tempting to just bump the version to 3.0.0.5 - but I don't know if I can/should since the repo isn't "official". Introducing some letter - like 3.0.0.4u1 would be an option, but Microsoft's "versioninfo" only accepts 4 digits. Does anybody have any thoughts?

When I've decided what to do with the version number, I'll upload the built DLLs - and I should probably add a link to the GitHub repo from the NSIS wiki as well.

I assume that the lack of response means that nobody has any opinions as to what to do with the version number. I think it's likely that we won't see another "official" release, so I'm leaning towards just incrementing the version number from the last "official" release.

Here is the release for download: https://github.com/DigitalMediaServe...dList/releases