# Saving DeviceImage crash with System.AccessViolationException **URL:** \ **Category:** .Net API\ **Created:** [November 8, 2018, 6:10pm UTC](https://forum.commonvisionblox.com/t/saving-deviceimage-crash-with-system-accessviolationexception/583 "2018-11-08T18:10:16Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![illusive](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.commonvisionblox.com/illusive/32/61_2.png) [@illusive](https://forum.commonvisionblox.com/u/illusive)\ **Post date:** [November 19, 2018, 1:27pm UTC](https://forum.commonvisionblox.com/t/saving-deviceimage-crash-with-system-accessviolationexception/583/6 "2018-11-19T13:27:15Z")
Hi @johmarjac > [@johmarjac](#): > > @illusive I dont know if I understood correctly, you mean I should use the other overload of Save() which just takes the filename and saves the image lossless? 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](https://forum.commonvisionblox.com/t/different-performance-when-saving-different-formats/252/4) 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](https://forum.commonvisionblox.com/uploads/commonvisionblox/original/1X/fbcc51c4bc4f576cecb7f0dccc0b7ee32cf1c666.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! --- _[View the full topic](https://forum.commonvisionblox.com/t/saving-deviceimage-crash-with-system-accessviolationexception/583)._