Unexpected behaviour when opening devices with .NET API (socket driver)

I see some odd behaviour when opening devices the old (C-style) and new (.NET API) way. The CVB version I use is 13.02.000.

What I do is as simple as opening 2 GenICam devices (GEV, socket driver), fetch the GenICam nodemap and acquire images in C#.

Until now, I’ve been using this kind of code, which gave me access to everything around the cameras, as I would expect it:

            String filePath = System.Environment.ExpandEnvironmentVariables(@"%CVB%Drivers") + "\\GenICam.vin";

        Cvb.SharedImg cam0Img, cam1Img;
        if (Cvb.Image.LoadImageFile(filePath, out cam0Img))
            Cvb.Driver.ICameraSelect2.CS2SetCamPort(cam0Img, 1, 0, out cam1Img);
            Cvb.Image.LoadImageFile(filePath, out cam0Img);

            Cvb.GenApi.NODEMAP cam0NodeMap, cam1NodeMap;
            Cvb.Driver.INodeMapHandle.NMHGetNodeMap(cam0Img, out cam0NodeMap);
            Cvb.Driver.INodeMapHandle.NMHGetNodeMap(cam1Img, out cam1NodeMap);


I recently decided to switch to the .NET API, so I tried to do just the same thing there. While I receive the correct devices from DeviceFactory.Discover, only the first has a Stream.Count of 1 (the second has 0).

Interestingly, the nodemap of the first device is reproducably corrupted (n/a values), while the one of the second device is fine.

The above two observations are seemingly device indepenent, as they stay in place if I load the cameras in a different order.

        static Device OpenDevice(int index)
        using (var devices = DeviceFactory.Discover(DiscoverFlags.IgnoreGevFD | DiscoverFlags.IgnoreVins | DiscoverFlags.IncludeInaccessible))
            if (devices.Count > 0)
                return DeviceFactory.Open(devices[index]);
                return null;

        Stemmer.Cvb.Device Camera0 = OpenDevice(1);
        Stemmer.Cvb.Device Camera1 = OpenDevice(0);

        Stemmer.Cvb.GenApi.NodeMap NodeMap0 = Camera0.NodeMaps[Stemmer.Cvb.Driver.NodeMapNames.Device];
        Stemmer.Cvb.GenApi.NodeMap NodeMap1 = Camera1.NodeMaps[Stemmer.Cvb.Driver.NodeMapNames.Device]; 

I tried to strip everything down to the minimum, yet it seems I can’t get around it. Do you see any reasons for this kind of behaviour?

Thanks a lot.

As an aside: I can also reproduce the described behaviour independent from my devices, by using 2 instances of GEV server from the socket based VB tutorial example.

Hi @MarSch,

This sounds like a bug in the CVFactory.dll we had in an older Version of CVB which should have been fixed for 13.02…

Could you please tell me the file version of your CVFactory.dll? It is located in the installation directory of :cvb:

Hi Thomas,

the CVFactory.dll version is from v13.02.

Note that the other thread seems to refer to the filter driver, i.e. the socket driver approach might not have been fixed.

I’m looking forward for any workaround, as I can’t use the filter driver in the application I’m developing.

Hi @MarSch

as we discovered you had a development version of the CVFactory.dll. A clean installation of CVB 13.2.0 fixed the issue.