Plugin causes notepad++.exe process to remain open after quitting app

[favorini]

Tried version 0.9.0 and 0.9.2 with Notepad++ 7.5.4 32-biit on Windows 7 x64. If I remove NppMenuSearch, process exits as expected. See https://github.com/notepad-plus-plus/notepad-plus-plus/issues/4062 for more info.

[chcg]

And see also https://notepad-plus-plus.org/community/topic/15163/process-explorer-shows-npp-instances-remain-after-closing

[dodmi]

I realized it's a conflict with NPPMenuSearch and DSpellcheck. If I remove one of the both, all is working fine

[dinkumoil]

I already reported a bug concerning this issue on SourceForge. I haven't installed DSpellCheck and are facing the hung Npp process either.

There is definitely an interconnection with the presence and/or absence of other plugins. At my site the problem disappears when NppFTP plugin gets installed.

An additional issue with the MenuSearch plugin is that it causes loss of content of the file favorites.dat belonging to the Explorer plugin, see here.

[brgrvrm]

I'm also facing the problem that notepad++.exe process remains active when closing the notepad++ app. This only happens with other plugins installed.

In my case it is when NppMenuSearch and jN npp plugin are installed. It seems to be a problem with NppMenuSearch plugin that is triggered by other plugins.

Sadly it looks like NppMenuSearch is not in active development by @peter-frentrup. But @budul100 did some commits in the past. Hopefully someone can dig into this issue. NppMenuSearch is a daily driver and we will badly miss the power it has.

Notepad++ 7.7.0 (32 bit) NppMenuSearch 0.9.2 (32 bit) JN npp plugin 2.2.185.5 (32 bit)

[shriprem]

I noticed this issue with the 64-bit version of the plugin. The 32-bit version has worked fine.

I then downloaded the source code, and started playing with it. I think I may have a solution. The issue is with the Main.cs >> PluginCleanup() method. I had to comment out the line with ReleaseHandle() call. Here is the changed version of the method:

internal static void PluginCleanUp()
{
    Settings.Save(xmlFilePath);
    //NppListener.ReleaseHandle();
}

Notes:

1. I tried substituting the ReleaseHandle call with a DestroyHandle call. Notepad++ seemed to close fine. But on the next launch, it launched with a reduced font size. I believe the handle release/destroy is best left to be managed internally by the NativeWindow ancestor class of the NppListener class. I am not an experienced coder in C#. So others will have a better insight into this.
2. After the code change, I first had to once do a build in the Debug mode (x32 or x64 didn't matter). Only therafter, the release version for both the 32-bit and 64-bit DLLs started loading in corresponding versions of Notepad++ without a Unicode-related error. I am using Visual Studio 2019. Again, I have to admit that C# is not something in which I have coded anything significant. If the author of this plugin (many thanks to him for this useful plugin!) or someone more knowledgeable in C# than me can review the change, do a fork, and provide the patched DLLs, I am fine with it. Otherwise, if anyone is interested that I take the initiative and provide the patched DLLs, please let me know. Thanks.

[peter-frentrup]

Dear @shriprem, thank you for your effort. After some testing I think your workaround of just not calling ReleaseHandle() is the best solution. I will apply the fix.

[pidgeon777]

I also had this problem when enabling FingerText and/or NppExec, with NppMenuSearch active, too. Glad this has been fixed.