cs-script.npp: Creating a new script crashes latest 64-bit Notepad++ release

Rookie mistake 😊 I just had to override the security block that Windows applies to executables from “untrusted” sources:

For reference, all of the following need unblocking as well:

CSScriptNpp/
|__
    CSScriptNpp.dll
    CSScriptNpp/
    |__
        CSScriptIntellisense.dll
        CSScriptLibrary.dll
        CSScriptNpp.asm.dll
        ICSharpCode.NRefactory.CSharp.dll
        ICSharpCode.NRefactory.dll
        Intellisense.Common.dll
        Mono.Cecil.dll

Great. Thank you. And I even managed to convince N++ team to embed the compatibility metadata in the https://github.com/notepad-plus-plus/notepad-plus-plus/issues/11198

There is no drop-in replacement for cs-script’s heavily customized hosting model.

I am glad you noticed the difference between the original NppPlugin.Host architecture and the approach CS-Script.Npp has taken.

I was not satisfied with the idea of building two versions of a plugin assembly and duplicating probably 80% of the codebase. Instead, I wanted to utilize .NET offers a very natural any CPU model.

Thus I have created two functionally identical plugin hosting assemblies (x86 and x64) and a single AnyCPU plugin assembly to be loaded by the hosting assembly dynamically. That’s it. 😃

I even contacted the developer of the NppPlugin.Host and shared the approach. Even offered assistance with incorporating it. But it did not go any further.

That’s why this plugin also maintains the customized fork of NppPlugin.Host.

Thank you for looking into this.

You are absolutely right the crash is not reproducible in Notepad++ 8.2.1. In fact, I would advise users to resist upgrading their editors, or else use only 32-bit versions for the time being. It has happened again in the now generally available 8.3 release. The runtime version of the assembly that faulted in 8.2.2 and now 8.3 was reported as “4.0.30319” by the Windows Event Viewer(*); the same runtime target as the NppPlugin.Host assemblies:

https://github.com/oleg-shilo/cs-script.npp/blob/0b8d87b8b3946bdbe857901671e5fc4679bda4cb/src/NppPlugin.Host/NppPlugin.Host.csproj#L13

As I tried to convey in the linked issue, this is not a bug in either the plugin or the editor. The developers of N++ are well aware that the new release will be an unstable host for 64-bit plugins.

The problem goes back to a feature request against N++ to make massive files of >2GB editable. It was just barely achieved (for x64 builds only) by retyping Scintilla’s Sci_PostionCR message as intptr_t, which expands to eight bytes on x86_64 architecture.

The hosting model’s equivalent type, CharacterRange, declares fields that are currently too small to safely handle the 64-bit values that calling into SCI_GETTEXTRANGE will now return from 64-bit editors.

There’s an open PR at the hosting model’s parent repo to address multi-arch memory safety; e.g., preferring IntPtr to int for types exposed to unmanaged interactions with Scintilla’s API. As you rightly suggested earlier, this will be no help, assuming it ever gets merged. There is no drop-in replacement for cs-script’s heavily customized hosting model.

I can confirm that a patched plugin can be safely loaded by even a pre-release editor once the struct declaration near line 214 of NppPlugin.Host/PluginInfrastructure/GatewayDomain.cs is changed to use IntPtr for the cpmin and cpmax fields, with the other type changes that entails. Notice the type and bit width of each member in the watch list below:

These will be sized accordingly in 32-bit builds, so backward compatibility isn’t affected:

I can’t predict if there will be regressions; that should be weighed against the current risk of losing data to an application crash.

Notepad++ v8.3   (64-bit)
Build time : Feb  5 2022 - 19:10:24
Path : C:\Program Files\Notepad++\notepad++.exe
Command Line :
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
OS Name : Windows 11 (64-bit)
OS Version : 2009
OS Build : 22000.469
Current ANSI codepage : 65001
Plugins : CSScriptNpp.dll mimeTools.dll NppConverter.dll NppExport.dll

---

(*)

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name=".NET Runtime" />
    <EventID Qualifiers="0">1026</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2022-02-06T20:37:13.4781435Z" />
    <EventRecordID>20975</EventRecordID>
    <Correlation />
    <Execution ProcessID="9132" ThreadID="0" />
    <Channel>Application</Channel>
    <Computer>AcerNotebook</Computer>
    <Security />
  </System>
  <EventData>
    <Data>Application: notepad++.exe 
    Framework Version: v4.0.30319
    Description: The process was terminated due to an unhandled exception.
    Exception Info: exception code c0000005, exception address 00007FF6BE92EFFF
    Stack:
    at Kbg.NppPluginNET.PluginInfrastructure.Win32.SendMessage(IntPtr, UInt32, IntPtr, IntPtr)
    at Kbg.NppPluginNET.PluginInfrastructure.Win32.SendMessage(IntPtr, UInt32, IntPtr, IntPtr)
    at Kbg.NppPluginNET.PluginInfrastructure.ScintillaGateway.GetTextRange(Kbg.NppPluginNET.PluginInfrastructure.TextRange)
    at CSScriptIntellisense.NppExtensions.GetTextBetween(Kbg.NppPluginNET.PluginInfrastructure.ScintillaGateway, Int32, Int32)
    at CSScriptNpp.CodeMapPanel.RefreshContent()
    at CSScriptNpp.Plugin.OnCurrentFileChanged()
    at CSScriptNpp.UnmanagedExports.beNotified(IntPtr)
    at Kbg.NppPluginNET.UnmanagedExports.beNotified(IntPtr)
    at Kbg.NppPluginNET.PluginInfrastructure.Win32.SendMessage(IntPtr, UInt32, IntPtr, System.String)
    at Kbg.NppPluginNET.PluginInfrastructure.Win32.SendMessage(IntPtr, UInt32, IntPtr, System.String)
    at CSScriptNpp.ProjectPanel.newBtn_Click(System.Object, System.EventArgs)
    at System.Windows.Forms.ToolStripItem.RaiseEvent(System.Object, System.EventArgs)
    at System.Windows.Forms.ToolStripButton.OnClick(System.EventArgs)
    at System.Windows.Forms.ToolStripItem.HandleClick(System.EventArgs)
    at System.Windows.Forms.ToolStripItem.HandleMouseUp(System.Windows.Forms.MouseEventArgs)
    at System.Windows.Forms.ToolStrip.OnMouseUp(System.Windows.Forms.MouseEventArgs)
    at System.Windows.Forms.Control.WmMouseUp(System.Windows.Forms.Message ByRef, System.Windows.Forms.MouseButtons, Int32)
    at System.Windows.Forms.Control.WndProc(System.Windows.Forms.Message ByRef)
    at System.Windows.Forms.ToolStrip.WndProc(System.Windows.Forms.Message ByRef)
    at System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)</Data>
  </EventData>
</Event>