Cannot get bitmap from native DLL from multi threaded Java app.

Question

I have a native DLL that gives me a HBITMAP (Windows handle to bitmap). I have made a JNI wrapper for this that gives me a BufferedImage back. The native code simple gets the actual bitmap for the handle, converts the RGB byte triplets to RGB ints, puts this in a jintArray and creates a BufferedImage.
This all works fine within a single Java thread. If I do this multi threaded (thread 1 calls the native function and several seconds later, thread 2 calls the native function) I keep getting the last image of the first thread. Can enyone help me out?
I know that this is probably a question for MSDN but I just know that they will tell me its a JNI question.
The native code:
JNIEXPORT jobject JNICALL Java_somenamespace_getPicture
(JNIEnv *env, jclass cl, jstring serialNumber)
jobject jImage;
jclass jImageClass;
jmethodID jMethod;
jfieldID jField;
jintArray rgbArray;
char *str;
char *charArray;
int *intArray;
int w, h, index, type;
HBITMAP hbmp;
BITMAP bmp;
str = (char*)((*env)->GetStringUTFChars(env, serialNumber, NULL));
// Gets the HBITMAP handle from the native DLL. The first argument is to select the device, based on serial number.
getPicture(str, &hbmp);
(*env)->ReleaseStringUTFChars(env, serialNumber, str);
// Get the BITMAP for the HBITMAP
GetObject(hbmp, sizeof(BITMAP), &bmp);
// Create my BufferedImage
jImageClass = (*env)->FindClass(env, "java/awt/image/BufferedImage");
jMethod = (*env)->GetMethodID(env, jImageClass, "<init>", "(III)V");
jField = (*env)->GetStaticFieldID(env, jImageClass, "TYPE_INT_RGB", "I");
type = (*env)->GetStaticIntField(env, jImageClass, jField);
jImage = (*env)->NewObject(env, jImageClass, jMethod, bmp.bmWidth, bmp.bmHeight, type);
// Get the RGB byte triplets of the BITMAP
charArray = (char *)malloc(sizeof(char) * bmp.bmHeight * bmp.bmWidth * 3);
GetBitmapBits(hbmp, sizeof(char) * bmp.bmHeight * bmp.bmWidth * 3, charArray);
// Allocate space to store the RGB ints and convert the RGB byte triplets to RGB ints
intArray = (int *)malloc(sizeof(int) * bmp.bmHeight * bmp.bmWidth);
index = 0;
for (h = 0; h < bmp.bmHeight; ++h)
for (w = 0; w < bmp.bmWidth; ++w)
int b = *(charArray + index * 3) & 0xFF;
int g = *(charArray + index * 3 + 1) & 0xFF;
int r = *(charArray + index * 3 + 2) & 0xFF;
*(intArray + index) = 0xFF000000 | (r << 16) | (g << 8) | b;
++index;
// Create a jintArray for the C RGB ints
rgbArray = (*env)->NewIntArray(env, bmp.bmHeight * bmp.bmWidth);
(*env)->SetIntArrayRegion(env, rgbArray, 0, bmp.bmHeight * bmp.bmWidth, (jint*)intArray);
// Use BufferedImage.setRGB() to fill the image
jMethod = (*env)->GetMethodID(env, jImageClass, "setRGB", "(IIII[III)V");
(*env)->CallVoidMethod(env, jImage, jMethod,
0, // int startX
0, // int startY
bmp.bmWidth, // int width
bmp.bmHeight, // int height
rgbArray, // int[] rgbArray
0, // int offset
bmp.bmWidth); // int scansize
// Free stuff
(*env)->DeleteLocalRef(env, rgbArray);
free(charArray);
free(intArray);
return jImage;
}I already tried working with native HDCs (GetDC, CreateCompatibleBitmap, SelectObject, GetDIBits, ...) but this just complicates stuff and gives me the same result.

Answer 1

Have you verified what the "native DLL" gives you back on the second call?The HBITMAP handle returned is the same each call (no matter which thread). The actual BITMAP associated with this handle is only updated in the first thread.
How are you determining that the image is the same?If I point the camera (I don't get a stream, I just get individual images) to a moving scene, I get different images for each call from within the first thread. The second thread only gets the latest image from the first thread. There is no concurrency of the threads and all methods are synchronized.
Specifically did you verify that the problem is not that your test code itself is using the same instance?Yes, I tested the native side as well as the Java side. The BufferedImage is always an exact copy of the native BITMAP.
Try printing out the hash for each instance.I have written the image to a file in the native code itself to eliminate anything related to the mechanism of returning the BufferedImage. This had the same result.
The return values of all native calls all indicate successful calls.
I am suspecting the native side of creating a second graphical context for the second thread while it keeps refering to the first context.
(I will start a thread on the MSDN as well and will post here if anything turns up.)