Archive: Pluginsdir persists - system.dll
Pluginsdir persists - system.dll
Using an app of my own with installoptions, the temp folder ceated by NSIS ($temp\ns*) persists after closing the app, with the file system.dll (10Kb) inside. Soon, there are so many temp folders as the times the app was executed.
How to unload this dll automatically as the app ends ?
I'm not preserving any file and there is no "system" word in my script.
I'm calling InstallOptions, tooltips, filefunc, winmessages, .onUserAbort and changeUI.
:tinfoil:
You probably have SetPluginsUnload in the script. Attach the script for a review.
BTW, the remaining system.dll files are queued for deletion after reboot.
Pluginsdir persists - system.dll
Here goes the script.
there are others, but this is the main.
More:
The others apps I use based on nsis doesn't leave files in temp dir.
My "startup monitor" never advised me about deletion on reboot of nsis apps residues, although do it with most of other "instalations".
My app is not an installation.
Which of the scripts show this behavior? Does it happen with Clipboard.nsi?
No.
If I open a.nsi (TrocarProxy.exe) and cancel, or close (X) or do something,.. in all cases, the system.dll is not deleted.
All the others, including old apps of oder versions, don't do it. I've canceled tooltips and made some changes, but is still the same.
It's a bug with the System plug-in. When a function with no arguments is called, it incorrectly calculates the number of arguments to push. Instead of pushing no arguments, it pushes one. When a stdcall function is called, like every Windows API function, it's its responsibility to clear the stack. When that extra argument is pushed and not cleared by the function, because it shouldn't, the stack gets corrupted. This causes CallProc, the function that actually calls the requested function in System.dll, to incorrectly restore the registers from the stack, including edi. In the installer code that calls the plug-in, edi is used to keep the handle to the loaded plug-in. Because of the corruption, the code calls FreeLibrary on the wrong handle and fails to unload System.dll. Because System.dll is still in use, it cannot be deleted and remains in the temporary folder.
In your case, it's the CopyFromClipboard function that triggers this bug. It calls CloseClipboard which has no arguments. To avoid this bug, for now, you can use:
System::Call "user32::CloseClipboard()?c"
Notice the `?c` addition. It tells System to treat the function as a cdecl function, which means System will clear the stack for it. Because the function has no arguments, System will only clear the arguments it wrongly pushed.FINISHED !
You really know about these things.
THANK YOU !
Fixed for 2.19.