How to solve the problem with scanning the list of available FTDI devices?

Question

C++ / C#

There is a strange issue when scanning FTDI devices. The first scan goes without problems. A list of devices is shown. Let's say we have two devices. The list shows four because the chip has two device ports. After the first connection, scanning for available devices works fine. But after the second connection, the problems begin. Attempting to scan the device results in a memory leak, according to the debugger. And this is where it stops. It is strange that it does not produce zero at least, since it is no longer available.

public TemplateFTDI.InfoDevice[] GetNumberOfDevices()
        {
            DeviceCount = 0;

            DeviceStatus = FTDI.FT_STATUS.FT_OK;

            // количество обнаруженных устройств
            DeviceStatus = Device.GetNumberOfDevices(ref DeviceCount);

            // составление списка устройств
            DeviceList = new FTDI.FT_DEVICE_INFO_NODE[DeviceCount];

            DeviceStatus = Device.GetDeviceList(DeviceList);

            InfoDevice = new TemplateFTDI.InfoDevice[DeviceCount];

            for (uint i = 0; i < DeviceCount; i++)
                InfoDevice[i] = new TemplateFTDI.InfoDevice()
                {
                    Number = i,
                    Description = DeviceList[i].Description.ToString(),
                    Flags = DeviceList[i].Flags.ToString(),
                    Handle = DeviceList[i].ftHandle.ToString(),
                    ID = DeviceList[i].ID.ToString(),
                    LocID = DeviceList[i].LocId.ToString(),
                    SerialNumber = DeviceList[i].SerialNumber.ToString(),
                    Type = MessageParse.TypeDevice(DeviceList[i].Type.ToString()),
                };
            return InfoDevice;
        } // получение списка обнаруженных устройств

There is a memory leak in place of GetNumberOfDevices.
PS Chips work in Sync FIFO mode.
Information update. When one device is working, there are no problems with leaks.

Answer 1

Problem solved. I'll answer my own question. It turns out that he incorrectly applied the mechanism for accessing elements from the stream. Because of what devices were blocked. Dispatcher.BeginInvoke should be replaced with Dispatcher.Invoke. This is where the memory leak occurs. True, the speed of access to devices has dropped noticeably. But this is not so critical.