一、前因
在windows下用cmake+VS编译了一个jni动态库，再使用java测试程序调用这个动态库的时候报错：“%1 不是有效的win32应用程序”
对于这类题目，一样平常从以下几个方面考虑：
- 动态库文件破坏
- 动态库大概其依赖库文件路径错误导致找不到。（不过这种动态库本身路径错误一样平常会报“找不到”）
- 动态库架构与体系架构大概JDK架构不一致
- 动态库的依赖库架构不匹配
那么从这几方面考虑，逐一举行排查就涉及到了一些相关的下令。
一、设置临时情况变量
下令行中使用java下令来运行测试程序加载jni动态库时，为了确保可以或许找到动态库，可以将动态库以及其依赖库地点的目次添加到临时情况变量Path,下令： set PATH=%PATH%;C:\Directory1\;C:\Directory2\;C:\Directory3\
二、检察JDK架构
下令1. java -version ,如下图，可以看出jdk版本是17.0.10， 架构是64位
下令2. java -d32 -version 大概java -d64 -version 哪个运行乐成就是哪个j架构。（但是我这两个下令都出现了error，不知道为啥）
那么目前可知JDK和体系架构都是64位的，动态库也是编译的64位，但是保险起见，还是要通过下令实际看一下动态库的位数。
三、检察动态库的架构
如图，打开VS的下令行工具， 也可以直接去dumpbin.exe地点的目次下面打开cmd， dumpbin 通常位于 Visual Studio 的安装目次下的 VC\Tools\MSVC\<版本号>\bin\Hostx64\x64 或 Hostx64\x86 文件夹中
然后，输入下令 dumpbin /hearders a.dll ,然后看下面输出内容中“machine”的部门，后面括号中"x64"表现是64位，"x86"表现32位
那么到这里可以确定我的动态库本身是没有题目的，那么题目可能就出在依赖库上。
四、检察动态库的依赖项
同样打开VS的下令行工具，使用下令：dumpbin /dependents +dll/exe文件路径
如图，可以看到这些依赖库中只有第一个是一个第三方依赖库，别的几个都是windows底层库，那么需要重点关注的就是第一个依赖库。
首先确保这个依赖库跟报错的动态库一起都加入了情况变量中能被Java找到（第一步），然后同样查抄一下这个依赖库的依赖库，发现它只依赖了一些windows底层库，没什么题目，再查抄一下它的架构（第三步下令），发现它竟然是32位的！！！
好好好，题目找到了，主动态库和jdk都是64位的，偏偏这个第三方依赖库是一个32位。那么现在只需要将它更换成64位的版本，题目就解决了。（鼓掌）
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
