I received a NullReferenceException from your library while using the WinForms ImageViewerControl.
Message: Unhandled Exception | System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.NullReferenceException: Object reference not set to an instance of an object.
at VideoOS.Platform.SDK.PlatformImageViewerControl.ImageViewerControl_OnImageOrPaintSizeChanged(Object sender, EventArgs e)
at VideoOS.Platform.SDK.UI.SDKImageViewerControl.ImageViewer_onImageOrPaintSizeChanged(Object sender, _DImageViewerEvents_onImageOrPaintSizeChangedEvent e)
at AxVideoOS.RemoteViewer.ImageViewerActiveXDotNet._DImageViewerEvents_onImageOrPaintSizeChangedEventHandler.Invoke(Object sender, _DImageViewerEvents_onImageOrPaintSizeChangedEvent e)
at VideoOS.Platform.SDK.UI.DirectX.ImageViewerDirectX._smartClientVideoPlayer_VideoImageChanged(Object sender, VideoImageEventArgs e)
The full stack trace is attached.
At the time of the exception there was no user interaction with our software. The control is being hosted in a winforms container inside a WPF application.
Any help is appreciated as to what caused this.
We have investigated the code, but the only way we can find this to potentially happen is if Dispose has been called without previous call to Close. From you description of what was going on this does not sound likely unless you have some automated replacement of the control?
Is there any way you can provide a crash dump for the application?
Thanks. We will be moving away from this control and utilizing the wpf one, for now we will monitor to ensure the disconnect/close/dispose are all being called correctly. If we observe this issue again (which only occurred once so far), we will follow up with you.
I appreciate the swift response.
Hi, we recently started experiencing the same issue ever since upgrading our Milestone integration to use the MIPS 2018 R1 SDK. We have confirmed that we are calling close before dispose on the ImageViewerControl.
We can provide a dump file if that would help resolve this issue?
Hi Rob,
A dump file would be very helpful indeed. To be honest I am not entirely sure whether the forum will allow large file sizes, so if you cannot upload it here please let us know and we will provide you with an alternative upload location.
Also could you please provide more information about what is happening in the application around the time where the crash happens? Are the ImageViewerControl being removed, replaced or similar?
/Peter
Thanks for the response,
Yes, unfortunately the dump file is too large for the forum. If you can let us know an alternative upload location that would be perfect.
Each time the tile inside our integration is ‘refreshed’, we destroy the existing ImageViewerControl and create a new one.
The disposal consists of:
_milestoneLiveViewerCtl.Close();
_milestoneLiveViewerCtl.Dispose();
(_milestoneLiveViewerCtl is an ImageViewerControl)
This worked fine when we were compiling against the 2014 SDK but after upgrading to 2018 we started experiencing this issue. It seems to be very reproducible.
Thanks for the assistance!
If requested to upload files to the support FTP server, please upload the files to a folder carrying the case number (MSCxxxxx) as folder name. If the folder does not exist, please create it. → MSC306240
EMEA FTP server details:
FTP url: msftp.milestone.dk
Username for uploading files: UpLoad
Password for uploading files: 1qazxsw2
Link: FTP://UpLoad:1qazxsw2@msftp.milestone.dk
If you are uploading large files or have connectivity issues, then we recommend using a FTP client program that supports resume.
And please let us know when the upload is done.
I am not really sure why, but the dump doesn’t really provide much useful information - not even where the exception happened.
Would it in any way be possible for you to migrate the relevant code into a small sample application which can reproduce the issue, so that we can run debug sessions at our machines?
Hi,
I have the same problem with ImageViewerControl_OnImageOrPaintSizeChanged NullReferenceException.
I make my integration with MIPS 2018 R1 SDK.
Does anyone have got an issue for this probleme or may I have to create a new post about this problem ?
As previously mentioned the only way we can see this happen is if Dispose() is called without calling Close() first, so please verify that you always call Close() before Dispose() on the control.
If this is the case, could you please try pull out the relevant parts of your application to make a small test application that can reproduce this and send it to us? Even though we have tried multiple times we have not been able to reproduce this in house and the code does not show any obvious reasons for this problem.