Electron running SQLlite 3 on Windows - A dynamic link library (DLL) initialization routine failed

Question

This is similar to this Electron Uncaught Error: A dynamic link library (DLL) initialization routine failed

ELECTRON_ASAR.js:173
        return old.apply(this, arguments)
                   ^

Error: A dynamic link library (DLL) initialization routine failed.
\\?\C:\workspace\client\client\desktop\node_modules\sqlite3\lib\binding\node-v57
-win32-x64\node_sqlite3.node
    at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:173:20)
    at Object.Module._extensions..node (module.js:671:18)
    at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:173:20)
    at Module.load (module.js:561:32)
    at tryModuleLoad (module.js:504:12)
    at Function.Module._load (module.js:496:3)
    at Module.require (module.js:586:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (C:\workspace\client\client\desktop\node_modules\sqlit
e3\lib\sqlite3.js:4:15)
    at Object.<anonymous> (C:\workspace\client\client\desktop\node_modules\sqlit
e3\lib\sqlite3.js:190:3)

I've tried everything suggested in this post and anything else I can find

I've installed electron-rebuild and added "rebuild": "electron-rebuild -f -w sqlite3 -V 1.7"

This is running without errors.

I tried "postinstall": "install-app-deps",

This isn't helping..

Anything else to try?

The files are in there..

The

Answer 1

This ended up being a mashup of a bunch of different issues on my end. I'll start with the simplest and go from there.

Platform

Your error there indicates that it wants node-v57-win32-x64, but if you are running from Electron it should be electron-v2.0-win32-x64 (or electron-v1.7-win32-x64 if you are using an older version). I ran into this as well because I am running sqlite3 in a child process. Child processes in Electron are in a full node context and not an Electron (browser or node+browser) context. I fixed this by passing the Electron version from the main browser process (process.versions.electron) to the child process via an environment variable and setting it on process.versions.electron in the child process.

WARNING: that is a HACK and works because I'm not using anything that expects a full Electron environment in that process. It is literally only to make it find the correct native bindings. A more correct fix would be to look into making electron-builder build node-v57-win32-x64 instead.

Speaking of which, let's create those next.

postinstall

"scripts": {
  ...
  "postinstall": "electron-builder install-app-deps"
}

This should attempt to rebuild your native dependencies when running npm install or yarn install. If you have a project/app directory, they will be placed in project/app/node_modules/. Otherwise they'll go in project/node_modules.

Transitive Dependency

In my case, sqlite3 is actually a transitive dependency of another package in my dependency set. While electron-builder on Linux/OS X picked these up correctly and showed this during installer creation:

• rebuilding native production dependencies platform=linux arch=x64
• rebuilding native dependency name=sqlite3

the Windows build showed:

• no native production dependencies

This was fixed by adding the transitive dependency as a direct dependency. After I did this, the package started to be picked up by electron-builder for compilation and was spitting out errors.

Windows Build

To fix those errors:

• Install python (I used the latest 2.7)
• Install Microsoft Build Tools 2013 and restart
• run your postinstall script again

This is the point where I said it was "half-solved" on my end. This should be the full solution for basic electron project setups.

yarn workspaces

I use the yarn workspaces feature and my project setup is something like this:

yarn-workspace-project/
  workspace/
    project/
      web-app/
    project-electron/
      app/

For this kind of setup, yarn install is generally run in the yarn-workspace-project or yarn-workspace-project/workspace directory, rather than in each project. This produces a hoisted node_modules/ directory at yarn-workspace-project/node_modules. When creating the packaged version, electron-builder grabs the dependencies from that hoisted location and everything runs.

When running my start script in project-electron, however, electron . had some issues finding the native binding. The package using sqlite3 was installed under yarn-workspace-project/node_modules, and was therefore resolving sqlite3 to yarn-workspace-project/node_modules/sqlite3. This definitely exists per the yarn install, but the electron bindings got put in yarn-workspace-project/workspace/project-electron/app/node_modules/sqlite3.

There are multiple obvious solutions to that, so I'll leave that as an exercise to the reader. The key problem here is that the default bindings that get downloaded (I think? I don't recall them being built) for node-v57-win32-x64 do not work out of the box for Windows 10 like they do for Linux / OS X, even though the error indicates that they don't exist (which they do).