SQLinForm x64 crashes with N++ 8.5.5

Guido Thelen

Hello,
my SQLinForm Plugin (64bit) crashes with N++ 8.5.5 (64bit).
SQLinForm Plugin (64bit) works fine with N++ 8.5.4 (64bit)
SQLinForm Plugin (32bit) works fine with N++ 8.5.5 (32bit)

The Plugin is written in C# using the NppPluginNET

Any idea what could be the reason for the crash in N++ 8.5.5 (64bit) and where I could start identifying the reason for the crash?

REgards
GuidoMarcel

rdipardo

Without access to the source code, the only reply anybody can make will be a shot in the dark.

The most I can say is that it’s not reproducible in the following environment:

Notepad++ v8.5.5   (64-bit)
Build time : Aug  7 2023 - 18:44:22
Path : C:\Users\Public\Downloads\npp.8.5.5.portable.x64\notepad++.exe
Command Line :
Admin mode : OFF
Local Conf mode : ON
Cloud Config : OFF
OS Name : Windows 10 Pro (64-bit)
OS Version : 22H2
OS Build : 19045.3324
Current ANSI codepage : 65001
Plugins :
    mimeTools (2.9)
    NppConverter (4.5)
    NppExport (0.4)
    SQLinFormNpp64 (6.23.3.24)

Guido Thelen

@rdipardo Many thanks for your answer. Indeed I can’t reproduce the error anymore myself. The error was reported by one of the plugin users and Friday I was able to reproduce the error. But now, after re-installing N++ 8.5.5 again from fresh the error seems to have disappeared. Maybe there was a new version of N++ 8.5.5 published in the meantime.

Regards
Guido

Alan Kilborn

@Guido-Thelen said in SQLinForm x64 crashes with N++ 8.5.5:

Maybe there was a new version of N++ 8.5.5 published in the meantime.

There actually can be different versions of 8.5.5. What makes a notepad++.exe unique is its Build time. So if you are really suspecting something like what you mentioned, have a look at that in your and your user’s debug info.

Guido Thelen

@Alan-Kilborn , thanks for this hint. The Build Time of N++ did not change in-between. Then this proves that a miracle happened ;-)
I will need probably more info from other plugin-users to identify the real issue.

Alan Kilborn

@Alan-Kilborn said in SQLinForm x64 crashes with N++ 8.5.5:

There actually can be different versions of 8.5.5. What makes a notepad++.exe unique is its Build time.

BTW, this would only actually happen because of the “release candidate” versions of Notepad++. Each RC for a specific version has the “real” version number on it (in case it is proven out and actually becomes the release).

rdipardo

@Guido-Thelen said in SQLinForm x64 crashes with N++ 8.5.5:

I will need probably more info from other plugin-users to identify the real issue.

Have a look at https://community.notepad-plus-plus.org/post/88577.

rdipardo

Have a look at https://community.notepad-plus-plus.org/post/88577.

One more thing to note: the commit that @Fruchtzwerg94 mentioned also enabled large address awareness for x64 builds of N++. There’s a classic post on Stack Overflow explaining how that can pull the rug out from under third-party DLLs, which suddenly have to cope with 64-bit pointers.

It should be irrelevant if the only faulting DLL is 64-bit, which obviously addresses memory with “large” ordinals all the time. In fact the new build option is supposed to be enabled by default for 64-bit targets.

But then there’s the whole .NET Framework to think about. The C# plugin template is basically a 32-bit module, with some “support” for x64 bolted on rather recently.

Guido Thelen

@rdipardo thanks! This sounds as it could be related to my issue. Just wondering how I could change this CETCOMPAT Flag myself.

Guido

Guido Thelen

@rdipardo @Alan-Kilborn it looks like there is a fix now available. https://community.notepad-plus-plus.org/post/88610

Thanks for all your feedback!