- Access violation when accessing pixel data

I use the driver in a 64 bit VS2017 C++ project to access a IDS uEye camera.
I can initialize the camera without problems but get a read access violation if i grab an image with the following code:

void* pixPtr = nullptr;
intptr_t XInc, YInc;
cvbResult = Snap(pImage->Handle());
cvbResult = GetLinearAccess(pImage->Handle(), 0, &pixPtr, &XInc, &YInc);
int c = *((unsigned char*)pixPtr);// !! read access violation

The GetLinearAccess function returns a pointer != null and correct XInc/YInc values.
But if i try to read from the pixeldata pointer I get a ‘read access violation’.

Any idea?


Maybe your image is invalid or locked/opened in another process? Can you check IsImage(pImage->Handle())?

I would also like to recommend our C++ API which wrapps the C API and is easier to use.



everything @usernv said is correct.

Your issue would suggest that the image gets deleted (or moved or …) between line 4 and 5.
Could this be a lifetime issue of pImage?
Is your code snippet an approximation of your code (i.e. there is stuff happening between line 4 and 5) or the full code?

Hi usernv and c.hartmann

Thanks for your reply.
The code snippset is exactly the code I use in my application.
Initially I used the C++ API reading from stream with GetTimedSnapshot() or WaitFor().
The Methods deliver a valid image, but any access to the pixel data leads to the access violation.
I use the code in a Camera class that loads/initializes the camera device in the constructor and reads the images via a Read() method. The Read() method is called from a separate grabbing thread.
Using the driver the code works perfectly.
May be a problem with the used ‘’ driver?
Next week I have the chance to test the code with the ‘’ driver…

@POI, I sent you a new driver version which should fix the problem. I would highly suggest to use cameras which comply with the GenICam standard though and thus use the whenever possible. The is deprecated and will not further be maintained.

Yeah, the new ‘’ fixes the problem.

Thank you very much.