I am having a C# (.NET 3.5, VS2005 Professional) application that uses unmanaged 32bit library written in C/C++. API that I use is like this:
void * Initialize(int x);
voic GetData(void *);
And this works when I run it on Windows XP 32bit, but on Windows XP64bit it throws exception:
Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
at Aktuelizator.CommonLibrary.InitializeRingBuffer(Int32 dim)
at Aktuelizator.AktuelizatorWService.AktuelizatorWS..ctor()
These unmanaged DLL's work under 64bit XP when called from 32bit unmanages application writetn in C/C++.
Does anyone have any idea?
Your build configuration Platform is set to 'Any CPU', that means on a 64 bit OS it runs as 64 bit and you can't load the dll. Set it instead to x86, this will force it to run as 32 bit regardless of OS and your dll will load fine.
It sounds like your DLL is only compiled to 32 bit, but you try to call it from both a 32 bit and 64 bit process. The former will work, of course. The later, however, won't. 32 bit DLLs can only be used in 32 bit processes. Try compiling the DLL to a 64 bit target and let the C# app use that one.
Check all parameters that are defined as Int32, that should in fact be IntPtr.
Related
Converting VB code from XNA 3.1 to MonoGame.
Any attempt to access class GraphicsAdapter throws the exception below. For example, trying to enumerate GraphicsAdapters. On this line:
For Each adapter As GraphicsAdapter In GraphicsAdapter.Adapters
Result is an exception:
System.TypeInitializationException occurred
HResult=-2146233036
Message=The type initializer for 'Microsoft.Xna.Framework.Graphics.GraphicsAdapter' threw an exception.
Source=MonoGame.Framework
TypeName=Microsoft.Xna.Framework.Graphics.GraphicsAdapter
StackTrace:
at Microsoft.Xna.Framework.Graphics.GraphicsAdapter.get_Adapters()
at ...my code...
InnerException:
HResult=-2146233054
Message=Could not load type 'SharpDX.Rectangle' from assembly 'SharpDX, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b4dcf0f35e5521f1'.
Source=MonoGame.Framework
TypeName=SharpDX.Rectangle
StackTrace:
at Microsoft.Xna.Framework.Graphics.GraphicsAdapter.CreateAdapter(Adapter1 device, Output monitor)
at Microsoft.Xna.Framework.Graphics.GraphicsAdapter.PlatformInitializeAdapters(ReadOnlyCollection`1& adapters)
at Microsoft.Xna.Framework.Graphics.GraphicsAdapter..cctor()
Note the inner exception:
Could not load type 'SharpDX.Rectangle' from assembly 'SharpDX, ...Version=4.0.1.0, ...
The project references these assemblies (among others):
MonoGame.Framework version=3.6.0.1625
from NuGet "MonoGame.Framework.WindowsDX", file
packages\MonoGame.Framework.WindowsDX.3.6.0.1625\lib\net40\MonoGame.Framework.dll
SharpDX version=4.0.1.0
SharpDX.Direct2D1 version=4.0.1.0
SharpDX.Direct3D9 version=4.0.1.0
SharpDX.DXGI version=4.0.1.0
SharpDX.Mathematics version=4.0.1.0
So I don't see why it would fail this way.
What could be wrong? Not compatible with this SharpDX version?
NOTE: These are all up-to-date packages from NuGet, in Visual Studio 2015. Targeting .Net 4.5.2.
UPDATE
To prove it isn't a problem with SharpDX, I put this line before that GraphicsAdapter line:
Dim testRect As SharpDX.Rectangle = New Rectangle()
This successfully created testRect. No Exception until attempt to access GraphicsAdapter. Also tried all the other Shared (static) properties of GraphicsAdapter, such as GraphicsAdapter.DefaultDevice. Any one fails with same exception.
I posted the same question to MonoGame forums:
http://community.monogame.net/t/solved-typeinitializationexception-accessing-graphicsadapter-adapters-could-not-load-type-sharpdx-rectangle/9803
Cause of problem:
Current release of MonoGame.Framework for WindowsDX (Windows OS + DirectX drivers), 3.6.0.1625 is built against SharpDX 2.6.3, and is not compatible with more recent SharpDX versions.
(Interim) Solution:
The developer branch of MonoGame does target the current SharpDX. Builds can be obtained from MonoGame's teamcity (free registration required).
Tested MonoGame.Framework build 3.7.0.994; it worked with SharpDX 4.0.1:
http://teamcity.monogame.net/viewLog.html?buildId=56483&tab=artifacts&buildTypeId=MonoGame_PackagingWindows
That build installs most SharpDX dlls to
C:\Program Files (x86)\MonoGame\v3.0\Assemblies\Windows
However, SharpDX.Mathematics.dll is currently missing,
so I still install SharpDX from NuGet, rather than using those.
Standard location for MonoGame releases:
(look for at least 3.7, which is not there yet, as I write this):
http://www.monogame.net/downloads/
(If instead of NuGet packages for MonoGame and SharpDX, I had downloaded MonoGame 3.6 installer and used its version of SharpDX dlls at C:\Program Files (x86)\MonoGame\v3.0\Assemblies\Windows, then I would not have had this incompatibility. However, that was not recent enough SharpDX for my purposes. This should be resolved by release of MonoGame 3.7)
I have the following setup:
Eclipse Mars 4.5 (Build id:20150621-1200)
MinGW 201310 with g++ 4.8.1
Windows 10
I followed few post to add std=c++11 in Project property and make sure __cplusplus is 201103L. Here is the result:
I can see that std::map compile and run ok.
If I #include , there is no syntax error. But the declaration of thread in main() shows error "Type thread could not be resolved". Then I open up thread header file located in c:/MinGW/lib/gcc/mingw32/4.8.1/include/c++/thread, it seems that the whole class is dimmed due to that _GLIBCXX_HAS_GTHREADS is undefined. If I manually define it in the path and symbols, then the thread class is fully defined. But there comes more errors in the thread itself. Did I missed something? Or if the C++11 thread isn't ready on eclipse+MinGW? Thank you!
To get support for std::thread, you will want a MinGW build equipped with posix threading model support.
I'm not sure if there's a "classic" MinGW build with that feature,
but it's available with MinGW-w64.
You can get a MinGW-w64 installation in a number of ways, but the installer under the "Mingw-builds" link should be sufficient to get you started (and will let you pick which release GCC you want).
I trying to use the j2pkcs11.dll (packaged with jdk1.8.0 - 64bit) to access certificates stored on a smartcard but not unable to make it work.
--- sample code to add the SunPKCS11 provider dynamically ---
String pkcs11ConfigSettings = "name = " + "TestSmartCard" + "\n" + "library = " + "C:/jdk1.8.0_11/jre/bin/j2pkcs11.dll";
byte[] pkcs11ConfigBytes = pkcs11ConfigSettings.getBytes();
ByteArrayInputStream confStream = new ByteArrayInputStream(pkcs11ConfigBytes);
Provider p = new sun.security.pkcs11.SunPKCS11(confStream);
---- the exception I get ---
java.security.ProviderException: Initialization failed
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:376)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:103)
at scpoc.SmartCard.main(SmartCard.java:28)
Caused by: java.io.IOException: The specified procedure could not be found.
at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method)
at sun.security.pkcs11.wrapper.PKCS11.<init>(PKCS11.java:138)
at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:313)
JEP 131 claims to have PKCS11 support in Java 8 (http://openjdk.java.net/jeps/131) but I have not been able to get it to work on windows 7 using the java8 64-bit. Note: I also tried the java 8 32-bit on windows 7 - but no luck either.
Has anyone had any success using the SunPKCS11 provider with java 8 (Windows 7)?
SunPKCS11 provider is present only in 32-bit Windows version of JRE up until JRE7. Since JRE8 it is present also in 64-bit Windows version of JRE. This is the information you see in JEP131.
If you need to use PKCS#11 API in 64-bit Windows version of JRE older than JRE8 then you will have to use one of alternative 3rd party implementations - such as IAIK-JCE.
I have also noticed in your code sample that you are trying to directly use "j2pkcs11.dll" as a PKCS#11 library which is wrong because it is just a JNI wrapper sitting between JRE and the library implementing PKCS#11 interface. Instead of loading "j2pkcs11.dll" you need to load PKCS#11 library provided by your smartcard or HSM vendor.
We have a project in which we want to control a Lego Mindstorms robot with the Microsoft Kinect sensor. We decided to use SimpleOpenNI with Processing to read the sensor and leJOS to control the robot for a simple reason: since both is in Java, we can specifiy a kind of RoboHandler and call its methods from the sensor reading class.
In order to achieve that, we downloaded the leJOS plugin for eclipse, created a new leJOS NXT project and put the processing and SimpleOpenNI libraries in the build path. Note that to use SimpleOpenNI, it is required an old processing version without Java.
Now the problem is, that when installing leJOS, it strictly requires a 32-bit Java JDK, so I had to download this and point to it at installation.
At this point, following build paths are in the project:
LeJOS NXT Runtime (which has among others java.awt classes)
core.jar (used to run Processing in eclipse)
SimpleOpenNI.jar
Having all this, and setting up a first Processing sketch like
import processing.core.*;
public class Test extends PApplet{
(....)
}
results in following error code:
Multiple markers at this line
- The type java.awt.event.MouseMotionListener cannot be resolved. It is indirectly referenced from
required .class files
- The type java.applet.Applet cannot be resolved. It is indirectly referenced from required .class files
- The type java.awt.event.MouseListener cannot be resolved. It is indirectly referenced from required .class files
- The hierarchy of the type FirstTry is inconsistent
- The type java.awt.event.FocusListener cannot be resolved. It is indirectly referenced from required .class files
- The type java.awt.event.KeyListener cannot be resolved. It is indirectly referenced from required .class files
When I downloaded the Processing without Java version, I wasn't able to choose from 32bit- or 64bit version. The SimpleOpenNI is installed as 64bit-version.
When adding the 64bit-JDK (eclipse workspace default) as workspace too, the error disappears, but when trying to run a sketch, following error gets printed in the console:
Invalid layout of java.lang.Thread at name
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (javaClasses.cpp:128), pid=9176, tid=8740
# fatal error: Invalid layout of preloaded class
#
# JRE version: 7.0_04-b22
# Java VM: Java HotSpot(TM) 64-Bit Server VM (23.0-b21 mixed mode windows-amd64 compressed oops)
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\Valentino\Desktop\workspaces\workspace_processing\RoboZeugs\bin\hs_err_pid9176.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#
So in my oppinion there is a problem with the JDK versions (32 and 64 bit), but there must be a way to handle this. Has anyone experience on this specific topic, maybe even with Kinect -> Mindstorms? Can anybody tell me what this error exactly means?
You're mixing classes that are designed to run with the JVM on the NXT brick (i.e. everything in classes.jar) with classes that are designed to run with a fully fledged JVM on the PC.
Don't do that. If you want to remote control an NXT, use pccomms.jar and everything else in lib/pc. But never add classes.jar or anything else in lib/nxt to the classpath when you're starting a Java program on your PC.
The error message about java.lang.Thread is probably due to the fact, that java.lang.Thread in classes.jar in by no means compatible with java.lang.Thread that comes with the JVM on your PC.
The setup I have is I'm using a Java application to call native C-code with JNI, which in turn starts up the MATLAB runtime and calls functions on it (I know there are other solutions to call MATLAB methods from Java).
The problem is that the MATLAB engine crashes at some point during the initialization and I don't know what's causing it exactly. The crash causes my jvm to terminate, I assume it's some kind of memory corruption.
The C++ code calling MATLAB functions that is actually crashing is
JNIEXPORT void JNICALL
some_jni_vodoo_initializeLibrary(JNIEnv* env, jclass thisClass) {
try {
if (!mclInitializeApplication(NULL, 0)) {
THROW_EXCEPTION(env, "Could not initialize the application properly.");
return;
}
if (!<library>Initialize()) {
THROW_EXCEPTION(env, "Could not initialize the library.");
return;
}
} ...
The function <library>Initialize() crashes here, the Java error log reads
Stack Trace:
[0] jmi.dll:0x793f4175(0x7934cdca, 1, 0x7937e67c "à;.y`E.y#E.ychar in C:\BUILD_ARE..", 0x792d6a32)
[1] jvm.dll:0x792df9a5(0xc0000005, 0x79356791, 0x4961b400 "Ð\8y", 0x6d8b29de)
[2] jvm.dll:0x792e0431(0x8b515008, 0x70f0e8ce, 0x8b5ffffa, 0xc25d5ec6)
------------------------------------------------------------------------
Fatal Java Exception detected at Fri Apr 30 11:08:08 2010
------------------------------------------------------------------------
Configuration:
MATLAB Version: 7.8.0.347 (R2009a)
MATLAB License: unknown
Operating System: Microsoft Windows Vista
Window System: Version 6.0 (Build 6002: Service Pack 2)
Processor ID: x86 Family 6 Model 10 Stepping 5, GenuineIntel
Virtual Machine: Java is not enabled
Default Encoding: windows-1252
Java is not enabled
I really have no idea what could be wrong. Is there not enough memory from the jvm? I guess the problem is somehow related to Java, since calling the JNI functions from a simple test C++ program works fine...
Thanks
Initial Ideas
The only similar thing I've ever seen is a silent exit from MATLAB due to an invalid license.
Another possibility is the nested Java environments. Since MATLAB expects its own Java environment, perhaps there is some problem here. Edit: See below!
Are you running the MATLAB Engine? Or are you calling separate MATLAB commands using some "system" or "exec" call? This might give a good clue.
Answer
The answer appears below in the comments. It is copied here for readability:
When nesting an invocation of MATLAB's engine in a process that has its own JVM, you must either tell MATLAB to run without a JVM by passing -nojvm to mclInitializeApplication or tell it which JVM to use by setting the global MATLAB_JAVA to the location of the JVM you wish to use, C:\Program Files\Java\jre6 for example.
The first option will disable any functionality in MATLAB that requires the JVM, so the second option is preferable.