Could not load Scintilla module without VC++ runtime installed

This component runs well on local pc but...
I dont know if it is something to to with RDP but this is the error I get on my remote PC

Hi, I didn't have all the notifications on so I didn't receive an email about this message. Is the NuGet at the latest version. One DLL fix has been done at c8084a3.

@VPKSoft

@VPKSoft This fix is wonderful! Any plans to update the nuget package?
EDIT: my bad, misread the dates

I actually still have this issue also with other forks like fernandreu/ScintillaNET.
Some users report that it's fixed when they install some version of the VC Redist 2005-2022 distributions.

Could not load the Scintilla module at the path 'C:\Users\serve\AppData\Local\Temp\Scintilla.NET\5.1.5\x86\Scintilla.dll'.
AtSystem.Windows.Forms.CreateParams get_CreateParams() 
Origin:
StackTrace:
   at ScintillaNET.Scintilla.get_CreateParams()
   at System.Windows.Forms.Control..ctor(Boolean autoInstallSyncContext)
   at System.Windows.Forms.Control..ctor()
   at ScintillaNET.Scintilla..ctor()
   ...

Any clues?

Hi,
Please make an issue to the maintainer of the fork you are using. I really don't support all the forks - sorry about that👍

Please reopen this issue. It is definitely still a problem with VPKSoft/ScintillaNET. I haven't used any other forks, but this bug has happened to us at work on one machine this week. It happened RDPing into a Windows 2016 server, but the same software works RDPing into a Windows 2019 server.

We thought it might be related to how the TEMP environment variable is overridden in RDP to have the session ID on the end of it (as described here). However, we turned that off via group policy, and the bug still happened.

So, I haven't tracked this down yet, but it's still a problem with VPKSoft/ScintillaNET v5.1.5.4. This happened with a .NET Framework build; I haven't tried a "Core" build yet. I'm hoping to spend some more time digging into it next week. Below is the call stack and error message from our app. We verified that the Scintilla.dll was correctly extracted to the stated temp path, and we could access it as the current user. It's a mystery why the app that just extracted it can't load it. 🤷‍♂️

An unhandled exception occurred in a Windows Forms thread.

Could not load the Scintilla module at the path 'C:\Users\grg\AppData\Local\Temp\2\Scintilla.NET\5.1.5\x64\Scintilla.dll'.
                                The specified module could not be found

Log Level:              Error
Source Class:         Equinox.Windows.Forms.WindowsUtility
Thread Id:              1
Application:           Equinox Management Studio
Execution Info:      {Name = Equinox Management Studio, Id = d1a3deb2-0dc7-4ff4-bcb6-1eae96f9136b, Started = 10/11/2022 22:07:02}
Source Method:    Equinox.Windows.Forms.WindowsUtility.<>c__DisplayClass9_0.<InitializeApplication>b__0(Object sender, ThreadExceptionEventArgs e)
System.ComponentModel.Win32Exception (0x80004005): Could not load the Scintilla module at the path 'C:\Users\grg\AppData\Local\Temp\2\Scintilla.NET\5.1.5\x64\Scintilla.dll'. ---> System.ComponentModel.Win32Exception (0x80004005): The specified module could not be found
   at ScintillaNET.Scintilla.get_CreateParams()
   at System.Windows.Forms.Control..ctor(Boolean autoInstallSyncContext)
   at ScintillaNET.Scintilla..ctor()
   at Equinox.Windows.Forms.SyntaxEditor.InitializeComponent() in C:\Agent\_work\1\s\Libraries\Equinox.Windows.Forms\SyntaxEditor.Designer.cs:line 31
   at Equinox.Windows.Forms.SyntaxEditor..ctor() in C:\Agent\_work\1\s\Libraries\Equinox.Windows.Forms\SyntaxEditor.cs:line 42
   at Equinox.Management.TextEditor..ctor() in C:\Agent\_work\1\s\Applications\Equinox.Management\TextEditor.cs:line 28
   at Equinox.Management.DatabaseEditors.Logic.Editor.InitializeComponent() in C:\Agent\_work\1\s\Applications\Equinox.Management.DatabaseEditors\Logic\Editor.Designer.cs:line 44
   at Equinox.Management.DatabaseEditors.Logic.Editor..ctor() in C:\Agent\_work\1\s\Applications\Equinox.Management.DatabaseEditors\Logic\Editor.cs:line 43
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Equinox.Management.Manager.GetEditor(EditorInfo info, Boolean throwIfUnavailable) in C:\Agent\_work\1\s\Applications\Equinox.Management\Manager.cs:line 869
   at Equinox.Management.Manager.Activate(String editorName) in C:\Agent\_work\1\s\Applications\Equinox.Management\Manager.cs:line 340
   at Equinox.Management.Studio.MainForm.Tree_AfterSelect(Object sender, TreeViewEventArgs e) in C:\Agent\_work\1\s\Applications\Equinox.Management.Studio\MainForm.cs:line 566
   at System.Windows.Forms.TreeView.OnAfterSelect(TreeViewEventArgs e)
   at System.Windows.Forms.TreeView.TvnSelected(NMTREEVIEW* nmtv)
   at System.Windows.Forms.TreeView.WmNotify(Message& m)
   at System.Windows.Forms.TreeView.WndProc(Message& m)
   at Equinox.Windows.Forms.ExtendedTreeView.WndProc(Message& m) in C:\Agent\_work\1\s\Libraries\Equinox.Windows.Forms\ExtendedTreeView.cs:line 163
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Reopened, I don't have an environment to test RDP so:
The Scintilla and Lexilla DLL files, which the control is based on are extracted to:

var scintillaName = "Scintilla.NET";
var modulePathScintilla =
                    Path.Combine(
                        Path.Combine(Path.Combine(Path.Combine(Path.GetTempPath(), scintillaName), version),
                            (IntPtr.Size == 4 ? "x86" : "x64")), "Scintilla.dll");

See. Scintilla.cs line 999, internal static string GetModulePath().

@Fiahblade

I tracked this problem down using the free https://github.com/lucasg/Dependencies utility. The problem is related to what @Fiahblade said on Aug 2. The v5 DLLs for Scintilla and Lexilla both have native DLL dependencies on:

msvcp140.dll
vcruntime140.dll
vcruntime140_1.dll

These DLLs were present on the Windows Server 2019 machine at work, but they weren't on the Windows Server 2016 machine. I installed the vc_redist.x64.exe as discussed on MSDN, rebooted, and then my app started loading Scintilla.dll and Lexilla.dll correctly.

FWIW, the old https://github.com/jacobslusser/ScintillaNET code used v3.6.3 of SciLexer.dll, which didn't have any dependency on the VC++ runtime.

So, no code changes are needed for the VPKSoft fork, but it's probably worth adding a note to this project's readme that the VC++ runtime is now required because it uses v5 of Scintilla. It might also be good to change the title of this issue to "Could not load Scintilla module without VC++ runtime installed".

Thanks for investigating this 👍 - It would be time to update the readme indeed as it's still in the same state as it was when forking the repository (Note to self: TODO). I'll keep this issue open as a reminder.

I spent a little more time looking at this tonight, and I noticed that the Scintilla.dll and Lexilla.dll included with the 5.3.1 release of SciTE do not have dependencies on the VC++ runtime. So, they don't require a separate installer, which allows SciTE to be "xcopy deployed".

It would be fantastic if you could update your embedded Scintilla.zip to include those DLLs instead of the ones that require a separate installer. The version numbers of the DLLs included with SciTE match the ones included in your .zip, so they're probably binary compatible. There are 32-bit and 64-bit builds of SciTE available.

I spent a few minutes looking through the Scintilla C++ source files to try to find the options SciTE uses to compile their Scintilla.dll and Lexilla.dll files without the VC++ runtime dependencies, but I couldn't figure it out. Maybe you'll have better luck. Or the Scintilla download page seems to imply that it's ok to use the DLLs included with the SciTE download, which might be easier.

I don't mind skipping the DLL build process - does the control work if the extracted files in the %TEMP%\Scintilla.NET\5.x.y are replaced with the SciTE ones?

Yes. Replacing the extracted DLLs in the temp folder with the ones from SciTE works fine for my app.

Thanks for the suggestion to use SciTE DLL files. I think I tried this at some point without success or not 🤔Released v.5.3.1.1

You're welcome! And thank you for the quick update. I'm using the v5.3.1.1 NuGet package in my app now, and it's working great.

I'm afraid I can't share the same good news. It now fails with or without VC++ R installed. Tried on my dev machine + a clean W10 VM. Are additional steps/configuration required or what am I missing?

Exception TargetSite: IntPtr DirectMessage(IntPtr, Int32, IntPtr, IntPtr)
Exception StackTrace: 
   at ScintillaNET.Scintilla.DirectMessage(IntPtr sciPtr, Int32 msg, IntPtr wParam, IntPtr lParam)
   at ScintillaNET.Scintilla.DirectMessage(Int32 msg, IntPtr wParam, IntPtr lParam)
   at ScintillaNET.Scintilla.DirectMessage(Int32 msg, IntPtr wParam)
   at ScintillaNET.Scintilla.InitDocument(Eol eolMode, Boolean useTabs, Int32 tabWidth, Int32 indentWidth)
   at ScintillaNET.Scintilla.OnHandleCreated(EventArgs e)
   at System.Windows.Forms.Control.WmCreate(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at ScintillaNET.Scintilla.WndProc(Message& m)```

Hi, is this VM 32 or 64 bit? Are you running .NET 5, 6, Core 3.1 or .NET Framework. I tried the test application on:

Windows 10 with .NET Framework 4.7.1 and .NET 6 on a 64 bit machine (required .NET 6 install)
Windows 11 with .NET Framework 4.7.1 and .NET 6

With both the NuGet as dependency and the Scintilla.NET project as dependency without an error.

This is an x64 machine, the application is .NET 6 but it's published as a 'self-contained' deployment. So .NET isn't installed on the machine.

I've now tried creating a traditional 'Framework-dependent' deployment and installed '.NET Desktop Runtime 6.0.10' with the same result.

I've found the culprit. Because my app is built against x86, I decided to test and build it against x64. And it now works in either deployment mode. With or without the VC++ dependencies.

So perhaps there is something wrong with the x86 DLLs?

All right, I'll check the x86 build after work 👍

@Fiahblade

Hi,
Version 5.3.1.2 should fix the 32-bit DLL problem. If you could verify this @Fiahblade.

@VPKSoft

@VPKSoft Works flawlessly, thank you 👍

Navigation Menu

Repository navigation

Could not load Scintilla module without VC++ runtime installed #16

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Could not load Scintilla module without VC++ runtime installed #16

Description

Activity

VPKSoft commented on May 12, 2022

Fiahblade commented on Aug 2, 2022

Fiahblade commented on Aug 2, 2022

VPKSoft commented on Oct 16, 2022

menees commented on Oct 16, 2022

VPKSoft commented on Oct 16, 2022

menees commented on Oct 16, 2022

VPKSoft commented on Oct 16, 2022

menees commented on Oct 16, 2022

VPKSoft commented on Oct 17, 2022

menees commented on Oct 17, 2022

VPKSoft commented on Oct 17, 2022

menees commented on Oct 17, 2022

Fiahblade commented on Oct 17, 2022

VPKSoft commented on Oct 18, 2022

Fiahblade commented on Oct 18, 2022

Fiahblade commented on Oct 18, 2022

VPKSoft commented on Oct 18, 2022

VPKSoft commented on Oct 18, 2022

Fiahblade commented on Oct 18, 2022

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions