Application is using the wrong midlib2.dll

Make sure that you copy the midlib2.dll (found in C:\Aptina Imaging) into the same directory as your executable. A mismatch between the midlib2.lib you link with and the midlib2.dll can show up in many different ways. Also make sure that you recompile your application anytime you receive a new software installation and that the midlib2.h and the midlib2.lib you use also come from the same software release.

mi_grabFrame() returns error code 4

Error code 4 is MI_NOT_ENOUGH_DATA_ERROR. There are several reasons this can be happening. As a sanity check, make sure that what you are trying to do works with DevWare. There are some board/sensor/PC combinations that just cannot handle the amount of data being sent. For example this may happen with a Demo1 or Demo1A board when trying to run 10-bit data for a 2MPixel sensor. If DevWare can handle it, then your application should be able to handle it as well.
If you are changing the size of the image by writing to the sensor registers, make sure that you are supplying the correct width and height to mi_updateFrameSize(). Remember mi_updateFrameSize() does not affect the amount of data being sent. It just tells the library how much data to expect.
If you are capturing JPEG data, this return value is normal since the compressed image will be smaller than the buffer.
Another reason you may not be able to capture an image is due to data swizzling. This is only relevant to Demo1/Demo1A boards when outputting 10bit Bayer data. The data coming from the sensor head has been wired such that the 8 most significant bits are in the low order byte and the 2 least significant bits are in the high order byte. This is done so that we can run in 8bit mode. When running in 10bit mode the data has to be reordered (swizzled) so that all of the bits are in the correct order. This is done in hardware on the Demo2 boards, however on the Demo1/Demo1A boards this can either be done by the library or the application. In order to prevent the user from having to swizzle the data, we provide this mechanism in the library. However due to timing considerations, if the library has to grab a frame and then swizzle the data, the processor may not be able to keep up and will start dropping frames. To prevent this, we have a swizzle mode which can be disabled so that the library doesn't do the swizzling and the Application does it instead. This works because we usually grab frames in one thread and another thread processes the frames. There are examples of the data swizzling in the SimpleCapture application.

Midlib2.h causes compilation errors

Please see the NOTE in the Portability section ( 4.0) above.