Saving DeviceImage crash with System.AccessViolationException

Programming Questions .Net API
6

Hi @johmarjac

Use of Save() without a quality parameter as opposed to Save() with a quality parameter does not imply lossless saving of images. The format that will actually be used for saving is determined based on the file name’s extension, and when calling Image.Save("test.jpg"), the image data still undergoes lossy jpeg compression - but with a default quality value, whereas when calling Image.Save("test.jpg", 0.2) you have control over the quality/size tradeoff of the save operation. Or, to put it differently, the problem does not really have anything to do with what overload you called and would occur identically in both cases.

What I did want to suggest is that alongside with the jpeg image you also save a (lossless) bmp image so that we might be able to investigate if there is a problem caused by the actualy image content - but I have by now received your crash dump, and I do not think that will be necessary any more.

It is a bit harder to figure out what went wrong than I hoped. Here’s what I found out so far:

  • in none of the threads that were active the moment your application crashed was the CVCFile.dll that I did originally suspect based on your report, so a crash inside CVCFile.dll currently seems unlikely.
  • in one thread the CVCImg.dll is on the top of the call stack, but due to a configuration problem on our end I cannot precisely tell what function has been called most recently
  • the thread in whose context the crash appeared has been in the clr.dll function ThreadpoolMgr::GateThreadStart() and only has core CLR or OS runtime functions on the call stack.

Without context I’d be doubting that this is actually happening inside :cvb: functionality, but then again what you describe is a significant correlation between saving the images and the crash occurring after a while. I would therefore like to suggest two things:

  1. Please head to this post and put a LoadLibrary("CVCFile.dll") somewhere in your code to make sure that the CVCFile.dll is always loaded and stays in memory. This is admittedly a bit of a hack for the moment, but what I am aiming at is this: When calling Save() with one of the formats handled through CVCFile.dll then the DLL is loaded dynamically, the save function is called and the DLL gets unloaded (as described in the discussion that I linked to). This has performance implications (see there), but there is a wee chance that the repetitive and manifold load/unload cycles might be otherwise unhealthy and contribute to the problem you’re seeing.
    So my first recommendation would be to try out this workaround. If it works, I’d leave it in (and we put a similar statement somewhere in our code), if not we’ll have to dig deeper.
  2. If we have to dig deeper can you please give this CVCImg.dll a try: CVCImg.zip (591.8 KB); just replace the one that exists in your %CVB% directory with this one (which is basically the same but built with more debug info) and wait for a new crash dump.

Thanks a lot!