Exception triggered somehow with Component Integration

I occasionally get the following error stack trace when either opening or closing the ImageViewerControl.

I do not know exactly how this occurs however. I see this happen occasionally and it is unclear how it happens. What we are doing is performing some stress tests that will create a new ImageViewerControl and connect and display video and then after a few seconds, disconnect/close it, and immediately create a new one and connect to the same video. Perhaps it has something to do with constantly trying to re-create the same video over and over again too quickly? Can you please advise?

Here is the relevant code to create a new ImageViewerControl:

imageViewerControl = ClientControl.Instance.GenerateImageViewerControl();

          playbackController = ClientControl.Instance.GeneratePlaybackController();

          imageViewerControl.PlaybackControllerFQID = playbackController;

          imageViewerControl.Dock = DockStyle.Fill;

          imageViewerControl.MaintainImageAspectRatio = true;

          imageViewerControl.EnableVisibleHeader = false;

          imageViewerControl.EnableVisibleTimeStamp = true;

          imageViewerControl.EnableVisibleCameraName = false;

          imageViewerControl.EnableMouseControlledPtz = false;

          imageViewerControl.EnableMousePtzEmbeddedHandler = false;

          imageViewerControl.InfoText = "Connecting to camera";

          imageViewerControl.ShowImageViewer = false;

          imageViewerControl.ConnectResponseEvent += ImageViewerControl\_ConnectResponseEvent;

          imageViewerControl.ImageDisplayedEvent += ImageViewerControl\_ImageDisplayedEvent;

          imageViewerControl.ClickEvent += ImageViewerControl\_ClickEvent;

          imageViewerControl.DoubleClickEvent += ImageViewerControl\_DoubleClickEvent;

          imageViewerControl.RightClickEvent += ImageViewerControl\_RightClickEvent;

          imageViewerControl.MouseMoveEvent += ImageViewerControl\_MouseMove;

          imageViewerControl.MouseLeaveEvent += ImageViewerControl\_MouseLeave;

          imageViewerControl.MouseDown += ImageViewerControl\_MouseDown;   // doesnt work. Left here for future reference that it doesn't work.

          imageViewerControl.MouseUp += ImageViewerControl\_MouseUp;     // doesnt work. Left here for future reference that it doesn't work.

          panelDisplay.Visible = true;

          panelDisplay.Controls.Clear();

          panelDisplay.Controls.Add(imageViewerControl);

          imageViewerControl.CameraFQID = cameraFQID;

          imageViewerControl.Initialize();

          imageViewerControl.Connect();

And here is the code where it disconnects the ImageViewerControl:

    if (imageViewerControl != null)

    {

       imageViewerControl.Disconnect();

       imageViewerControl.Close();

       imageViewerControl.Dispose();

       imageViewerControl = null;

       Logger.DebugFormat("Disposing Milestone ImageViewerControl");

    }

    if (playbackController != null)

    {

       ClientControl.Instance.ReleasePlaybackController(playbackController);

       playbackController = null;

    }

Thanks

Most important first - have you updated to the newest graphics driver?

It is critical to have the drivers for the graphics cards in your test PCs (or customer site PCs) up to date. We see many issues of Smart Client or ImageViewerControl based client application leaking or malfunctioning in other ways and a graphics driver update makes the issue go away.

Please tell us which product and version of the XProtect VMS you use.

Please verify that you use the newest MIP SDK.

Yes, the graphics driver is updated to latest. It happens on multiple developer machines so it is not just my own system.

We are using VMS XProtect Essential+ 20.2a and MIP SDK 2020 R2. We can try release 3 but the SDK release notes do not mention fixing any memory issues.

We updated to MIP SDK 2020 R3 but still see the same issues.

I have consulted Milestone Developers and we are wondering whether it leaks, can you please check it?

Looking at task manager, I do not see User Objects or GDI objects leaking so as far as I can tell, I do not think there is a memory leak anywhere.

I did find the cause of the exception and it appears to be because of the call: imageViewerControl.Close(). If I do not call that when disposing of resources, I don’t get that exception anymore. Even after not calling this, I do not notice any resources being left over.

We have looked further into the code and this is clearly a problem on our side, and we honestly don’t believe the right solution is to stop calling Close(). For now the best you can do is to reuse the ImageViewerControls instead of disposing and creating new, but the team has also started looking into how to fix the problem, and we hope we can have a preliminary version ready within a few days, which we then hope you will test for us? If it solves the problem the next step will of course be that we provide an official hotfix.

We can definitely try the fix when it is ready.

Thanks

We have now analyzed the code further and we think that we understand why the exception is thrown. We have however not yet been able to reproduce the issue in-house so there is some element of uncertainty here.

We only believe that the exception you see can happen if the ImageViewerControl is constructed and hosted on a UI thread other than the applications main UI thread. Is your application creating new UI threads and creates the ImageViewerControls on these?

Also we will like to know what UI technology is used by the application. Is it a pure Windows Forms or WPF application or a mix? And if it is a mix, is the application type then Windows Forms of WPF?

Finally I have attached a dll where the issue you see hopefully is solved. Can you please try to reproduce using that dll? Please note that the dll is a local untested build and should NOT be distributed elsewhere.

I looked more at the issue and got even further I think. So when you do your test then please use this new attach dll.

Thanks

Hi Jimmi,

I have tried the latest dll and it appears it no longer causes the exception.

To answer your questions, as far as I know, there is only 1 UI main thread so I don’t know how it can be on another UI thread. This is also a pure .NET Windows Form application.

Since this works, do you know when an official SDK will be available with this fix? I would like to update our application install bundle to include the official fix.

Thanks

Hi David,

We will prepare an official hotfix as soon as possible, but will probably not be ready until some time next week.

An official hotfix is available following this link: https://supportcommunity.milestonesys.com/SCRedir?art=000028001&lang=en_US

This fix is in the from of a new Smart Client installer not a new MIP SDK. You will need to persuade customers that see the issue to update their Smart Clients.

Hi Bo,

I’m confused. The previous temporary fix provided by Jimmi was in a dll that we incorporate into our application that we need for our integration of the component libraries to address the problem. We are NOT using the Smart Client at all. How does this address our issue?

Thanks

Hi David,

It is me who has mixed up two different cases and requested a Smart Client hotfix for your case. :frowning:

I have now requested a hotfix for the SDK instead.

Sorry for the confusion and the delay…

Best regards,

Peter

Sorry for the confusion.

Now you will find a new MIP SDK installer here - https://supportcommunity.milestonesys.com/s/article/XProtect-2020-R3-cumulative-patch-installers?language=en_US

Thanks