nppShell icon indicating copy to clipboard operation
nppShell copied to clipboard

"Hardening" of the NppShell code needed.

Open xomx opened this issue 9 months ago • 1 comments

Some reports of the Explorer shell crashes caused by this extension:

https://community.notepad-plus-plus.org/topic/26565/notepad-v8-7-1-32-bit-nppshell-dll-is-intermittently-crashing-windows-explorer https://github.com/notepad-plus-plus/notepad-plus-plus/issues/15683 https://github.com/notepad-plus-plus/notepad-plus-plus/issues/15788 https://github.com/notepad-plus-plus/notepad-plus-plus/issues/12448

I was unable to identify exact culprit in the NppShell code, partly due to the current nature of Microsoft's way of dealing with such crashes (instead of a direct crash where the app callstack leading to a crash is preserved, they decided to invoke their CRT func handlers like abort(), which then make it impossible to reveal the callstack from the dump, thus making the dumps useless).

Anyway, I reviewed the NppShell code and found several issues, some of which are fundamental and need a major revision of the code design.

Most importantly, the code uses throwing (of unhandled exceptions) when detecting a problem - this is unacceptable in a shell extension because of it then leads to the entire Explorer shell crashing!

Furthermore, the code does not assume at all that an unexpected situation could occur when handling inputs (e.g. reading from the Registry, i.e. invalid or corrupted key data), while using WINAPIs or CRT funcs, which will generate an exception itself in such a situation...

I will try to do some PRs to fix this and hopefully that will solve these crash issues reported.

xomx avatar Feb 14 '25 09:02 xomx

While an older ticket, this was relevant for me as I had long had issues of Windows 11's Explorer window locking up on mouse clicks on the bottom half (however, keyboard still worked!!), and it turned out, yes NppShell was causing this behavior. I could "unfreeze" a frozen Explorer window by opening a new tab (as the top half is NOT frozen) and break off the frozen tab, and it becomes clickable again, until I right-click enough times before it froze again.

In fact, when I went to disable the plugin first in Autoruns and ShellExView, it turned out NppShell was nowhere to even be found, yet it clearly is registered and running. Just no CLSID? (Can anyone else confirm this?)

When I went to uninstall Notepad++ after such a freeze had just occurred, the uninstaller itself then got stuck at: regsvr32 /u /s "C:\Program Files\Notepad++\contextmenu\NppShell.dll"

Since being uninstalled, this "freeze" which I didn't even think was Explorer related (I kept hounding Microsoft over it) has never once returned now, so it was reinstalled without the extension since I didn't really need it anyway (but it was helpful).

(EDIT: Just for clarification, Notepad++ was auto-updating itself, but the uninstaller said v8.7.7. Might it not actually have been updating correctly in the first place? Either way it was reinstalled without the plugin as I don't wish to troubleshoot anymore, but I did want to point out my observation that CLSID's were not enumerating in any Shell Extension viewer, that's about it.)

MasterLink86 avatar Nov 14 '25 20:11 MasterLink86