JNI C++ DLL - 'UnsatisfiedLinkError: %1 is not a valid Win32 application'

For me, the problem was that my newly-added DLL relied on other DLLs I didn't know about. Windows helpfully went out and found a 32-bit version in my path, but was unable to load it, as my application is 64-bit.

I used Dependency Walker (there are 32 and 64-bit versions, as well as Itanium...) and Process Monitor to debug this. The long and short of it is make sure that every single DLL that your DLL pulls in is also 64-bit, and you'll be a lot happier.

One thing to watch out for is if Windows finds a 32-bit DLL of the right name it will try to load it, and in Process Monitor it will look like it's reading it successfully. Make sure to keep scrolling down!! You may find that the system discards this DLL and moves on to keep searching the path for a 64-bit version.

Update:
Two other things to be aware of:

1) Old Dependency Walker can look like there are mismatches for the DLLs it loads e.g. it might find a 32-bit match first, when you really wanted a 64-bit DLL, and tell you there are CPU type mismatches. Just get the new version, and this issue goes away. Thanks to https://stackoverflow.com/a/22384936/309502 for this information.

2) Order matters when you're loading DLLs. I didn't realize I was loading two of them in the wrong order and could not figure out why it wasn't working. Check that you load the prerequisites first. :-)

I was initially getting Can't find dependent libraries error, to resolve which I added the DLLs in the path. But this led me to the error %1 is not a valid Win32 application at java. To resolve it all, making a static build worked for me, which compiles with: g++ -static. It adds the dependent libraries in the build itself.

i also got the same kind of issue.The problem in my case was my dll was taking some 64bit dependent dll.i opened my jni dll into dependency walker, there i found the 64 bit dll. I replaced it with 32 bit.My problem got resolved.