Error dynamic symbol retrieval error win32 error 127

Receiving error when attempting to run app on Windows 7 #353

Hi. I have an app that uses ffi to connect a C library to Node. I’ve got it working properly on Mac so, this week, I’ve been tasked with getting it to work on Windows as well. We have a .dll that was built from the same code used to build the Mac framework so we know the build is good. It is, however, a 32-bit build. Now, I’m not a Windows guy so I might have missed something small but here’s some details:

• OS Version: Windows 7 Professional (SP1) 64-bit
• Node version: 6.9.2 (installed with nvm-windows )
• npm version: 3.10.9

When I attempted to run my app with default settings, I received a «Win32 error 193» when loading the .dll . I know the file is there and verified the absolute path I was passing was correct. This same binary is being used by multiple other apps so I know it is functional. From some research, it seems as if an error 193 means the application is not a valid Windows application or that there’s a 32/64 bit mismatch.

So, I installed the 32-bit version of node and reinstalled all modules using the —arch ia32 flag which caused the «cannot find bindings.node» error I’ve seen so many times before along with a host of other issues with non- ffi modules I was using (specifically, electron ).

Is this expected behavior (i.e. not being able to load a 32-bit .dll using ffi without switching to a 32-bit architecture)? If not, can you shed some light onto things I could try to get this application to load properly? Any known pitfalls or tips/tricks you can pass on?

Let me know what other details you need (versions, paths, source code, etc.). Thanks!

The text was updated successfully, but these errors were encountered:

Источник

JS call C ++ dynamic library DLL simple DEMO and problem collection [favorites version]

Anan7 months ago (04-13)front end526

contents

Frequent question card

Question 1, *. Node is not a valid win32 application

Question 2 Error: Dynamic Linking Error: Win32 Error 193

Question three, error: Dynamic Linking Error: Win32 Error 126

Question four, error: Dynamic Symbol Retrieval Error: win32 error 127

Implement steps and minimalize code

1. Install the tool library

2. Import dependency library

3. Export dynamic library method

4. Call the export method

Foreword

During the ELECTRON development process, many times will encounter the need to call C ++ dynamic library DLL. Use JS to call the DLL library, it is very high, JS and C ++ basically have no two languages, and I took out the spark at this time. Today, I will introduce this magical use process and the possible problems that may be encountered. If you are interested in the front-end students, welcome to collect + practice!

Have to say, want to implement the JS call C ++ DLL dynamic library, which requires a third-party tool and middleware.

Nodejs has a lot of related tool classes that can easily implement JavaScript loading and calling DLL dynamic libraries, and is also responsible for processing type conversion issues across JavaScript and C.

Similar plugins are roughly as follows:

Frequent question card

Let me talk about the problem that may be encountered, and the article is finally given an minimalist code example.

Question 1, *. Node is not a valid win32 application

Report error message:

Error: \?G:projectworkelectron-quick-startnode_modulesffi-napibuildReleaseffi_bindings.node is not a valid Win32 application.
\?G:projectworkelectron-quick-startnode_modulesffi-napibuildReleaseffi_bindings.node
at process.func [as dlopen] (electron/js2c/asar.js:140:31)
at Object.Module._extensions..node (internal/modules/cjs/loader.js:1034:18)

Cause: The relying library is not 32-bit.

Solve: This problem is generally more common, because many dependent libraries may be inconsistent with the target application type, in most cases, in the dependency library of Node_Modules.

It is also very simple to handle, just need to rebuild.

The execution command in the dependency library is as follows:

node-gyp clean configure build —verbose —arch=ia32

If you still don’t know how to do it, you can refer to my previous article — «Electron FAQ 9 — * .Node Is Not a Valid Win32 Application》

Question 2 Error: Dynamic Linking Error: Win32 Error 193

Report error message:

G:projectworkelectron-quick-startdll.dll
(node:23644) UnhandledPromiseRejectionWarning: Error: Dynamic Linking Error: Win32 error 193
at new DynamicLibrary (G:projectworkelectron-quick-startnode_modulesffi-napilibdynamic_library.js:75:11)
at Object.Library (G:projectworkelectron-quick-startnode_modulesffi-napiliblibrary.js:47:10)
at G:projectworkelectron-quick-startmain.js:81:18
(node:23644) UnhandledPromiseRejectionWarning: Error: Dynamic Linking Error: Win32 error 193
at new DynamicLibrary (G:projectworkelectron-quick-startnode_modulesffi-napilibdynamic_library.js:75:11)
at Object.Library (G:projectworkelectron-quick-startnode_modulesffi-napiliblibrary.js:47:10)
at G:projectworkelectron-quick-startmain.js:81:18

Cause 1. The called dynamic library DLL is 32-bit, and the target module needs to be 64-bit.

Rebate a 64-bit DLL dynamic library, solve the problem.

If we have changed to 64-bit DLL dynamic libraries, there is this problem, the big probability problem is that the DLL lacks the corresponding dependent DLL library.

Cause 2. There is lack of dependencies.

Partners engaged in Windows systems know that we generally develop tool DLL libraries, more or less dependent on the system or third party DLL library. This is also the advantage of the DLL dynamic library, which can be dynamically dependent and dynamically called. If you want to save things, we can directly pack your needs or third-party libraries, in the form of a static library, so you can use it, and the big probability will not happen. Therefore, we can use the tools such as Depends to see if the DLL’s dependency library is all.

Question three, error: Dynamic Linking Error: Win32 Error 126

Report error message:

(node:17224) UnhandledPromiseRejectionWarning: Error: Dynamic Linking Error: Win32 error 126
at new DynamicLibrary (G:projectworkelectron-quick-startnode_modulesffi-napilibdynamic_library.js:75:11)
at Object.Library (G:projectworkelectron-quick-startnode_modulesffi-napiliblibrary.js:47:10)
at G:projectworkelectron-quick-startmain.js:81:18

Cause: Path problem, it is likely that there is no need for DLL dynamic library.

Solve: Avoid this problem, it is to use absolute paths as much as possible to avoid using relative paths. Of course, if you can ensure that there is no problem with the path, this is random.

Since the debug start path of Electron is different from the installation, this is not the same, this requires special attention.

Note: The path started in the development mode is the node_modules / electron / directory. Be

Question four, error: Dynamic Symbol Retrieval Error: win32 error 127

Report error message:

(node:21764) UnhandledPromiseRejectionWarning: Error: Dynamic Symbol Retrieval Error: Win32 error 127
at DynamicLibrary.get (G:projectworkelectron-quick-startnode_modulesffi-napilibdynamic_library.js:113:11)
at G:projectworkelectron-quick-startnode_modulesffi-napiliblibrary.js:55:21
at Array.forEach ()

The cause of this problem is generally a problem with DLL. That is to say, there is a problem with the generated C ++ DLL dynamic library, which is generally because there is no sign of the export method, so the corresponding method cannot be found when the DLL is called.

The simplest reason is to export function methods, no added extern «C» 。

Actually, I have been encountered by I. . .

So why can EXTERN «C» affect export symbols? Then we need to introduce it to its role.

Essential effect is to correctly implement C ++ code calls other C language code.

When we add Extern «C», the compiler will compile this part of the code in a C language (rather than C ++).

Since the C ++ support function is overloaded, the compiler is compiled, and the parameter type of the function is also added to the compiled code, not just a function name; and the C language does not support the function overload, so compile The function of the C language code does not bring the parameter type of the function, which generally only includes a function name. This feature is very useful, because many code written before C ++, and the bottom library is also written in the C language, in order to better support the original C code and the already written C language library, It is necessary to support C ++, so extern «C» has become an inevitable choice.

Said so much, add your own dynamic libraries to Extern «C», and recompile.

See if it is a problem.

Finally, attach a piece of code example:

Implement steps and minimalize code

It is not easy to encounter these problems.

Next, describe the specific steps.

1. Install the tool library

Ann a tool library introduced in the beginning of the article, here is FFI-NAPI as an example, specific command:

2. Import dependency library

Add a reference to the FFI-NAPI dependency library in your code.

3. Export dynamic library method

Next, it is to use FFI-NAPI to export the required methods for the DLL dynamic library. It is necessary to note that the exported declaration statement should be consistent with the name, parameter table, return value of the C ++ method in the DLL dynamic library.

Here with one summary method int sum(int a, int b) Take the example, the code is as follows:

4. Call the export method

This step is also simple, the code is as follows:

Источник

Dynamic Linking Error Win32 error 127 #755

I’m trying to get vosk to work inside nodeJS on Windows:

• Window 10 21H1 (OS Build 19043.1288)
• NodeJS v16.10.0
• npm 7.24.2
• vosk 0.3.32

But i get this error:

I’ve already tried or read through the threads on:

Loading DLLs from nodejs on Windows #457
This doesn’t seem to work/change the error. eg: adding C:Users. repossubtitle-syncernode_modulesvosklib to my PATH env variable.

I installed vosk using the python command:

And then also inside node:

The text was updated successfully, but these errors were encountered:

Most likely you have 32-bit node. We only support 64-bit.

I installed vosk using the python command:

You don’t need python for node module

ok, i reinstalled NodeJS x64 and now it works:

thx for the help.

oeps, this worked because i tried it on another pc.
On my laptop it still fails.

i tried reinstalling nodejs x64 on my laptop but it didn’t help.

libvosk.dll info from dumpbin:

The error when i execute the program in node:

If i debug at the failure point:

I double checked that this file does exist:

Источник

Получил ошибку «Ошибка динамического поиска символов: ошибка Win32 127» при загрузке DlL из nodejs

Я хочу загрузить файл dll из узла js. Вот заголовочный файл:

При компиляции как я выбираю «скомпилировать как код C»

В активной платформе решения я выбираю x64

И затем я использую модуль ffi для его загрузки:

Но у меня ошибка:

3 ответа

На случай, если сюда приземлится еще кто-нибудь.

В приведенном выше примере ffi.Library имеет (в основном) два параметра: первый — это путь к файлу (dll); второй определяет функции, на которые следует ссылаться (имя функции: [return_type], [parameter_type]. ).

Я не уверен на 100% в номерах ошибок, но я «думаю», что если вы получаете ошибку 126, это указывает на проблему с первым параметром — он не может найти файл (для проверки просто попробуйте использовать полный путь и отладить из там).

Если вы получаете ошибку 127 (о которой сообщается здесь), это указывает на проблему со вторым параметром — он не может найти указанную функцию в указанной dll.

Обычно это указывает на проблему с компиляцией dll. В приведенном выше примере указано, что он был скомпилирован как «C» (не C++), это сведет на нет включение экспорта из-за #if __cplusplus.

Я думаю, если бы проект был скомпилирован как C++, он бы работал.

В качестве альтернативы, это пример, который работает для меня (в моем файле export.h).

Ваш пробег может отличаться

Я тоже столкнулся с той же проблемой. Я не знаю точной причины этой ошибки. Но я изменил следующее (Просто измените имя DLL с «test» на «./test»), и это работает. Вы тоже попробуйте то же самое и дайте мне знать, если это сработает. Спасибо.

Источник

Dynamic Symbol Retrieval Error on Windows 10 about argon2-ffi HOT 53 CLOSED

Slayther commented on January 15, 2023 1

Yes, it does not throw any errors on include!

PlasmaPower commented on January 15, 2023 1

That’ll throw an error BTW, you’re probably looking for this:

cjlarose commented on January 15, 2023

Sorry about this! What version of Node.js are you using?

Urik commented on January 15, 2023

Don’t worry! v4.4.4
Thanks for looking into it.

Slayther commented on January 15, 2023

I’m getting the same error with same-ish trace.
Full output:

PlasmaPower commented on January 15, 2023

Since someone else got this error, it looks like it’s more than just bad luck/configuration unfortunately. Here’s my troubleshooting:

Googling «win32 error 127» gives a lot more results than «‘Dynamic Symbol Retrieval Error». The error is ERROR_PROC_NOT_FOUND, «The specified procedure could not be found.».

It looks like the problem can stem from several things:

• The more obvious case of the library not having the procedure (function) used by Node. This is the likely cause, as the error occurs when loading a specific function. However, I don’t see why the dll would be missing a function. If you have visual studio installed, could you do dumpbin /EXPORTS path/to/argon2.dll ? That should list exported functions, we can see if they match up with what we’re using.
• You have multiple DLLs with different versions in the library loading path. From my understanding of node-argon2, it will specify a static path to load from, which would mean that this couldn’t happen.
• Argon2 has it’s own runtime dependency which it is failing to load. However, I know that this is not the case.

So, the first case seems like the only likely one. If you could get the functions exported from the dll that would be great.

Urik commented on January 15, 2023

Here’s mine, sorry if something’s missing, I’m on a rush.

Slayther commented on January 15, 2023

I figured it out. Here is mine:

PlasmaPower commented on January 15, 2023

That’s odd, it would appear that the library is being built wrong as it exports no functions. Normally you’d see an output something like the one in this StackOverflow post.

PlasmaPower commented on January 15, 2023

Can you try building argon2 manually, and replacing the built DLL with the manually built one? I’d like to confirm that this is the problem. I’m not sure what is causing it yet.

Slayther commented on January 15, 2023

I tried building with instructions from the repository, and replaced the dll file, but the same error appears. I’m not sure if I have built it correctly, or should I have used something different..

Here is the output:

PlasmaPower commented on January 15, 2023

@Slayther That’s how you would build it through argon2-fii, I should have been a bit more specific. Try building argon2 standalone (without Node or argon2-ffi). It can be found here: https://github.com/P-H-C/phc-winner-argon2 and I think it can be built with visual studio.

Once you have built the DLL, replace the DLL in argon2-fii/build/Release with the DLL you built.

Slayther commented on January 15, 2023

Excuse my ignorance, but I am not sure how to build it. I tried running make with command prompt at the folder cloned from git.

PlasmaPower commented on January 15, 2023

@Slayther Assuming your Node isn’t built through Cygwin, don’t build argon2 through Cygwin. Try opening the project in Visual Studio (try the vs2015 folder and subfolders, and if that fails, simply import the sources).

Slayther commented on January 15, 2023

I opened one of .vcxproj files in VS and pressed Build > Build Solution . There were no errors, but there is no .dll . What else should I do to get it?

PlasmaPower commented on January 15, 2023

@Slayther Did you open the Argon2Opt one? A bit of research shows that should produce a build similar to what we’re doing. If that doesn’t give you a DLL, try creating a new console project with application type DLL, copying in the c files specified here, copying in all header files (.h), and building.

Slayther commented on January 15, 2023

Yes, I opened Argon2Opt.vcxproj .

Are there any additional options I should check?

PlasmaPower commented on January 15, 2023

@Slayther What’s the build log? If it’s long, post it at https://gist.github.com/

PlasmaPower commented on January 15, 2023

@Slayther Also, make sure the application type is set to DLL in the project options.

Slayther commented on January 15, 2023

Project options of the application cloned from git or the one I would create manually and import the code files into?

PlasmaPower commented on January 15, 2023

@Slayther The one cloned for git (well both really) — it should be preset to DLL but it looks like it isn’t for some reason (it’s building an EXE).

Slayther commented on January 15, 2023

I’m not sure how I can switch the type to dll, can’t find the option. Unless I create it manually like you said.

PlasmaPower commented on January 15, 2023

@Slayther Maybe it’s in output type? I’ll be rebooting into windows in a while anyway, so I’ll see if I can’t look into this while I’m there. Basically look for a dropdown that has a DLL selection (probably labeled as a type).

Slayther commented on January 15, 2023

Going to Project > Properties has no options that say dll or anything similar. Not sure where I would find the option.

PlasmaPower commented on January 15, 2023

@Slayther Okay, it should be there. I’m rebooting into Windows to investigate.

PlasmaPower commented on January 15, 2023

I forgot what a pain it is to setup a proper Windows dev environment.

Slayther commented on January 15, 2023

Can I do anything further?

PlasmaPower commented on January 15, 2023

@Slayther I figured it out; Properties -> General -> Project Defaults — set to Dynamic Library (.dll), then a bit up there’s a Target Extension, change that to .dll instead of .exe. I’m seeing if I can run it with that dll now.

PlasmaPower commented on January 15, 2023

Because I can’t get my node-gyp environment setup properly (I think I need VS2013, I have VS2015 for argon2) I can’t test the built DLL.

Slayther commented on January 15, 2023

Ok, I will try it out

PlasmaPower commented on January 15, 2023

Odd, I don’t see any exports in my VS built DLL.

Slayther commented on January 15, 2023

Where is that Properties ? There is no General under Project > Properties

PlasmaPower commented on January 15, 2023

@Slayther Right click Argon2Opt on the right

Slayther commented on January 15, 2023

I just choose dll and build?

PlasmaPower commented on January 15, 2023

@Slayther You choose DLL in two spots, then build yes.

Slayther commented on January 15, 2023

In 2 spots?
There is another under General > General, but it’s dll already. Is that the one?

PlasmaPower commented on January 15, 2023

@Slayther Both general and general -> project defaults -> configuration type.

Slayther commented on January 15, 2023

Ok, then I’m good. Building

Slayther commented on January 15, 2023

Okay, now there are multiple .dlls, for each folder. How do I get the single one I need?

PlasmaPower commented on January 15, 2023

This just got significantly more complicated. It looks like the problem is that for VS you have to put __declspec(dllexport) before any function you want to export when building a DLL. That’s why our built DLLs have no functions.

PlasmaPower commented on January 15, 2023

@Slayther should be the Argon2Opt one

PlasmaPower commented on January 15, 2023

There’s no way to automatically export all functions (that’s built into VS at least), so it looks like it won’t easily work unless argon2 adds specific support for Visual Studio.

Slayther commented on January 15, 2023

Yup, still getting the same error.

Slayther commented on January 15, 2023

Wish I had more knowledge regarding all this. I would love to help with that.

Slayther commented on January 15, 2023

Re-running dumpbin gives different output now, if that helps

PlasmaPower commented on January 15, 2023

I figured it out! In argon2.h, change:

Then the built DLL has the correct dumpbin /exports output! I think that should work!

Slayther commented on January 15, 2023

Will test my app now

PlasmaPower commented on January 15, 2023

I think we can close this issue when the linked PR for argon2 gets merged. Until then, @Urik you can manually build the DLL in visual studio as described above.

Slayther commented on January 15, 2023

Well, I have a bug in it and it hangs.. Oh well, no errors, nice work!

Slayther commented on January 15, 2023

How long should this execute for?
argon.argon2i.hash(«123456», 10, function (err, hash) );

Edit:
It just seems to hang forever.

Edit:
It seems like it’s not doing much as Task Manager shows 0% for CPU usage..

PlasmaPower commented on January 15, 2023

@Slayther I think you missed the move to promises. A breaking update switched the style from callbacks to promises. Try this:

Slayther commented on January 15, 2023

Ahh, thank you very much!

• Support passwords of type String
• Update readme with suggestions on how to generate salts
• Update readme with suggestions on how to use promises with the lib
• Change memoryCost to not be powers of two
• Remove dependency on enum module HOT 1
• Calling verify with undefined or null encodedHash segfaults
• Elaborate on the difference with similar package
• 1.1.0 broke semver for us. HOT 4
• Cannot run in AWS Lambda HOT 7
• Unable to load argon2-ffi library on node 6.12.2 HOT 4
• ENOENT: no such file or directory, open node_modules/argon2-ffi/build/Release/argon2.so HOT 8
• Unable to load 1.1.1 on Windows. HOT 3
• Dynamic Linking Error
• Unable to npm install argon2-ffi HOT 4
• Buffer() is deprecated (Version 13.7.0)
• importing argon2-ffi crashes node 14 HOT 5
• Unable to install argon2-ffi with npm HOT 1
• Support for macs with new apple silicon HOT 5

Recommend Projects

React

A declarative, efficient, and flexible JavaScript library for building user interfaces.

Vue.js

🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

Typescript

TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

TensorFlow

An Open Source Machine Learning Framework for Everyone

Django

The Web framework for perfectionists with deadlines.

Laravel

A PHP framework for web artisans

Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

javascript

JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

Some thing interesting about web. New door for the world.

server

A server is a program made to process requests and deliver data to clients.

Machine learning

Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

Visualization

Some thing interesting about visualization, use data art

Some thing interesting about game, make everyone happy.

Recommend Org

Facebook

We are working to build community through open source technology. NB: members must have two-factor auth.

Microsoft

Open source projects and samples from Microsoft.

Источник

LitchGZ opened this issue 4 years ago · comments

var ffi = require('.ffi')
var mstsc = ffi.Library('./mstscax.dll', {
  'put_Server': [ 'void', [ 'string' ] ]
})

Error: Dynamic Symbol Retrieval Error: Win32 error 127
    at DynamicLibrary.get (e:zhoulfnode-ffilibdynamic_library.js:112:11)
    at e:zhoulfnode-ffiliblibrary.js:50:19
    at Array.forEach (<anonymous>)
    at Object.Library (e:zhoulfnode-ffiliblibrary.js:47:28)
    at Object.<anonymous> (e:zhoulfnode-ffiexamplefactorialfactorial.js:3:24)
    at Module._compile (internal/modules/cjs/loader.js:698:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)
Waiting for the debugger to disconnect...
Error: Dynamic Symbol Retrieval Error: Win32 error 127
    at DynamicLibrary.get (e:zhoulfnode-ffilibdynamic_library.js:112:11)
    at e:zhoulfnode-ffiliblibrary.js:50:19
    at Array.forEach (<anonymous>)
    at Object.Library (e:zhoulfnode-ffiliblibrary.js:47:28)
    at Object.<anonymous> (e:zhoulfnode-ffiexamplefactorialfactorial.js:3:24)
    at Module._compile (internal/modules/cjs/loader.js:698:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:712:10)
    at Module.load (internal/modules/cjs/loader.js:600:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:539:12)
    at Function.Module._load (internal/modules/cjs/loader.js:531:3)

E:zhoulfnode-ffi>node -v
v10.15.3

E:zhoulfnode-ffi>npm -v
6.9.0

OS version: Windows 10

mstscax.dll: ActiveX control 

package main

import "C"

func Add(x, y int) int {
	return x + y
}

func main() {}

const { resolve } = require('path');
const ffi = require('ffi-napi');
const ref = require('ref-napi');
const sharedGoLib = resolve(__dirname, './add');

const int = ref.types.int;
const nodeGo = ffi.Library(sharedGoLib, {
  Add: [ int, [ int, int ] ],
});

console.log(nodeGo.Add(2, 4));

var ffi = require('ffi');

var current = ffi.Library(null, {
  'atoi': [ 'int', [ 'string' ] ]
});
console.log(typeof current.atoi('1234')); // 1234

    throw new Error('Dynamic Symbol Retrieval Error: ' + this.error())
    ^

Error: Dynamic Symbol Retrieval Error: Win32 error 127
    at DynamicLibrary.get (D:webnode_modulesffilibdynamic_library.js:112:11)
    at D:webnode_modulesffiliblibrary.js:50:19
    at Array.forEach (native)
    at Object.Library (D:webnode_modulesffiliblibrary.js:47:28)
    at Object.<anonymous> (D:webnativewinapi.js:5:19)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)

3 ответа

#ifdef __cplusplus
extern "C" {
#endif
    __declspec(dllexport) int add(int a, int b);
#ifdef __cplusplus
}
#endif

const ffi = require('ffi');
var libm = ffi.Library(__dirname + '/dll/add.dll', {
    'add': ['int', ['int', 'int']]
});

console.log(libm.add(1,2));