none
Bug report: MediaLibrary.SavePicture NullReferenceException

    Question

  • I’m getting random null ref exceptions on my app compiled under OS v8 Nokia 920. This occurs roughly once per 20 high-res photo saves:

    A first chance exception of type 'System.NullReferenceException' occurred in Unknown Module.

    An exception of type 'System.NullReferenceException' occurred in Unknown Module. and wasn't handled before a managed/native boundary

    SaveImageStreamToMediaLibrary(Waypoint_20121212-093506_Aaa.jpg exception: System.NullReferenceException: Object reference not set to an instance of an object.

       at Microsoft.Xna.Framework.Media.MediaLibrary.SavePicture(String name, Stream source)

       

    • Retrying the call generally works OK
    • Compiling the library under OS v7.1 works OK
    • The problem worsens under increased memory pressure
    • I now call this from the UI thread – it’s somewhat worse when called from a worker thread.

    The retry workaround somewhat acceptable, if not pretty.

    Gerald Maffeo


    Gerald Maffeo

    Saturday, December 15, 2012 9:06 PM

Answers

  • Hi Gerald,

    The Marketplace support team brought this thread to my attention. Here is what I have discovered.

    The development team were aware of this bug. Their tests suggested that any >8MB picture saved to the library could cause the NullReferenceException.

    That issue has been corrected and will be propagated in a future update to the operating system; I cannot offer an anticipated date.

    There is a little more to the story. After fixing it, success was reported, using sizes of 11MB and 16MB.

    But they noted that there is still a possibility of an app running out of system memory while decoding the JPEG, with larger file sizes.

    In your app you should consider not only reacting to the NullReferenceException, but also place a try/catch exception wrapper around SavePicture in the event that it runs out of memory.

    In any event, perhaps, before running the affected code, you can release as much RAM memory as possible first (i.e. unneeded objects, other images etc.). This, in combination with retrying, may be the best workaround for now.

    Hope this helps,
    Mark


    Mark Chamberlain Sr. Escalation Engineer | Microsoft Developer Support | Windows Phone 8

    • Marked as answer by GeraldMaffeo Thursday, February 07, 2013 6:43 PM
    Thursday, February 07, 2013 6:18 PM

All replies

  • Can confirm this bug too. I am saving only one single image from web and receive same error!

    Still unable to find whats wrong.

    Sunday, December 30, 2012 9:41 PM
  • I can confirm this behaviour also occurs for the MediaLibrary.SavePictureToCameraRoll method, with the same retry workaround as acceptable but not ideal.
    Saturday, January 26, 2013 9:59 AM
  • I am experiencing the same issue
    Thursday, January 31, 2013 11:28 AM
  • The problem has worsened for some reason and is far more serious than I indicated in the original thread. This may be related to to a recent phone software update.

    Further information:

    - The stream position is nearly always at 2.3MB when the exception occurs.

    - A temp file gets created in isolated storage named something like pho833D.tmp. If I rename it to pho833D.jpg, I see nearly half the picture, with the remainder blank (its color seems to vary depending on what was last rendered) 

    THIS IS A DEPLOYMENT BLOCK for my app. I have submitted a support request, hope someone in the forum has a workaround.


    Gerald Maffeo

    Sunday, February 03, 2013 7:26 PM
  • Hi Gerald,

    The Marketplace support team brought this thread to my attention. Here is what I have discovered.

    The development team were aware of this bug. Their tests suggested that any >8MB picture saved to the library could cause the NullReferenceException.

    That issue has been corrected and will be propagated in a future update to the operating system; I cannot offer an anticipated date.

    There is a little more to the story. After fixing it, success was reported, using sizes of 11MB and 16MB.

    But they noted that there is still a possibility of an app running out of system memory while decoding the JPEG, with larger file sizes.

    In your app you should consider not only reacting to the NullReferenceException, but also place a try/catch exception wrapper around SavePicture in the event that it runs out of memory.

    In any event, perhaps, before running the affected code, you can release as much RAM memory as possible first (i.e. unneeded objects, other images etc.). This, in combination with retrying, may be the best workaround for now.

    Hope this helps,
    Mark


    Mark Chamberlain Sr. Escalation Engineer | Microsoft Developer Support | Windows Phone 8

    • Marked as answer by GeraldMaffeo Thursday, February 07, 2013 6:43 PM
    Thursday, February 07, 2013 6:18 PM
  • Mark - Thanks very much for the reply. I spent a few hours yesterday working on this and came up with a solid repro for the support team. Guess I don't need it now!

    I did learn that by NOT disposing the image stream after each (simulated) camera capture and simply setting the length to 0 before each new capture, I can mitigate the problem. This will hopefully also work in my app.

    I already do all of the things you suggest in your reply (minimize memory pressure, wrap the save in try/catch).

    I am all too aware of memory issues working with large images, especially if you have to do any image manipulations - it has been a major challenge.

    Gerald


    Gerald Maffeo

    Thursday, February 07, 2013 6:43 PM
  • Hi Gerald,

    I hope your mitigation(s) work.

    Thank you for your feedback!

    -Mark


    Mark Chamberlain Sr. Escalation Engineer | Microsoft Developer Support | Windows Phone 8

    Thursday, February 07, 2013 6:52 PM
  • Hi Mark,

    I'm hitting a similar issue, but unfortunately, mine isn't fixed by retrying the API call.  In my case, I call the SavePicture API many times (~30 usually), each at a user interaction.  Eventually, I hit the NullReferenceException in MediaLibrary.SavePicture which Gerald mentions above.  However, if I then catch that exception and make another call to MediaLibrary.SavePicture, the thread totally hangs.  I'm doing this in a BackgroundWorker, and the SavePicture call never returns.  I've waited for as long as 5 minutes and the call just doesn't come back.  Any subsequent calls to MediaLibrary.SavePicture using new media library objects also hang in this manner.  Code included below.

    using (IsolatedStorageFile progStore = IsolatedStorageFile.GetUserStoreForApplication())
                {
                    using (IsolatedStorageFileStream imgFileStream = progStore.OpenFile(imgName, System.IO.FileMode.Open, System.IO.FileAccess.Read))
                    {
                        using (MediaLibrary library = new MediaLibrary())
                        {
                            imgFileStream.Seek(0, SeekOrigin.Begin);
    
                            try
                            {
                                // TODO: Sometimes code freezes here.
                                library.SavePicture(imgShortName, imgFileStream).Dispose();
                            }
                            catch (NullReferenceException)
                            {
                                // Sometimes saving to the library fails with a null reference for unknown reasons.
                                status = DownloadStatus.Failed;
                            }
    
                            imgFileStream.Close();
                        }
                    }
                }

    Saturday, February 23, 2013 6:29 AM
  • I am facing the same problem very often as well, as described by others above. I can add an image after the failure by creating a new memory stream and pass this stream to the "SavePicture*" method.

    But there is another problem: once the method "SavePicture*"has failed at least once then the memory usage increases with each newly added image stream until the app totally crashed because it uses all available RAM:

    e.g.

    MediaLibrary.SavePicture(stream); // Used RAM: 43 MB
    MediaLibrary.SavePicture(stream); // Used RAM: 43 MB
    MediaLibrary.SavePicture(stream); // crash (caught in try/catch)-> Used RAM: 53 MB
    // do: stream.Close/Dispose/Null
    MediaLibrary.SavePicture(stream); // Used RAM: 53 MB
    MediaLibrary.SavePicture(stream); // Used RAM: 63 MB
    MediaLibrary.SavePicture(stream); // Used RAM: 73 MB
    // and so on until the app crashes because all memory is used. The images are successfully added even after the crash

    • Edited by SyFr Wednesday, March 27, 2013 4:43 PM
    Wednesday, March 27, 2013 4:42 PM
  • The mitigations somewhat lessened, but never solved, my problems. Once the exception occurs, memory appears to be left in a mess.

    Even worse, the original version of my app was running without these kinds of issues until people started installing it on Windows 8. Now I've started getting crash reports for the photos - different APIs, different implementation.

    When will we see a fix??! This is getting worse than annoying. It's pissing off my users and blocking me from releasing the new version.


    Gerald Maffeo

    Wednesday, March 27, 2013 5:03 PM
  • I found a workaround that so far seems to work pretty well. Call the following from the UI thread:

    mediaLib.SavePictureToCameraRoll(fileName, ((MemoryStream)e.ImageStream).ToArray());
    e.ImageStream.Close();

    Calling this in a worker thread (ThreadPool) is not stable. I have not tested how this behaves on a 7.8 device yet, only on a Lumia 920 WP8.

    Here's the related bug report:

    http://connect.microsoft.com/VisualStudio/feedback/details/776453/savepicturetocameraroll-randomly-throws-nullreferrenceexception

    Saturday, April 20, 2013 2:23 PM
  • Luis - Many thanks for the suggestion, but it unfortunately doesn't work for me.  (I am calling it from the UI thread, by the way.)

    Gerald Maffeo

    Sunday, April 21, 2013 10:17 PM
  • Same issue here, some users can't save any picture while it works fine for others.

    I have managed to reduce the memory footprint by setting the DecodePixelHeight/Width, which partially solved the issue ...

    Still no news about an eventual fix ? :(

    Wednesday, April 24, 2013 9:25 AM
  • Hi,

    My Feb 7 posting is still valid, unfortunately it is not Microsoft's policy to release timing regarding updates until they are actually propagated.  The update timing also depends on the OEM and carrier deploying the update.

    -Mark


    Getting Started? Click here
    Blog: Windows Store & Phone Developer Solutions

    Wednesday, April 24, 2013 2:53 PM
  • I consulted with the WP development team. As Mark mentioned, the problem is known and the fix should be pushed in one of the next updates. They suggested the following to at least mitigate the issue:

    a) Force GC prior to calling the API
    b) Try/catch the call and re-try if it fails
    c) Scale down the image before saving (as Cyril mentioned - if that’s an acceptable option)

    Unfortunately, there is no reliable workaround, we will have to wait for the update.

    Wednesday, April 24, 2013 7:06 PM
  • My application operated with GC.collect.
    Thursday, July 11, 2013 5:16 PM
  • I installed 8.0.10328.78 on a Lumia 920 and took over 20 high-res pictures programatically and they all got saved and no exception was thrown. So this issue seems to be fixed now.
    Thursday, August 29, 2013 9:19 AM
  • Luis - Thanks for letting us know. As for most of us in the US with 920s, we're still waiting on AT&T to release the new build. Hopefully we'll see it soon!

    Gerald Maffeo

    Sunday, September 01, 2013 4:08 PM
  • I still have the problem. After taking 4-5 picture in a row, the exception is thrown.

    Please remember to mark the replies as answers if they answered your question!

    Sunday, November 24, 2013 9:36 AM
  • Phone type, resolution, OS version, etc.???
    Sunday, November 24, 2013 11:09 AM