DeviceDiscovery.Discover - still an SEHException

Programming Questions C-style API
,
1

Hi,
I’ve a very similar problem to this one:
https://forum.commonvisionblox.com/t/devicediscovery-discover-sehexception/264

However, since the other topic has been closed in between, and I’m using a much newer Version: 13.1.0.0.

So, just as in the other case, the grabbing is active (with the RingBuffer active - if that makes any difference), but when I try to make a Device Discovery again:
Driver.DeviceDiscovery.Discover(
Driver.DeviceDiscovery.Flags.IgnoreVins | Driver.DeviceDiscovery.Flags.IgnoreAccessStatus,
out SharedATList deviceList);

I get:
System.Runtime.InteropServices.SEHException: ‘External component has thrown an exception.’
at Stemmer.Cvb.DriverLib.DODiscover(String seed, Int64 flags, Int64 reserved, IntPtr& list, IntPtr timeout)
at Cvb.Driver.DeviceDiscovery.Discover(String seed, Flags flags, Int64 reserved, Int32 timeoutMs, SharedATList& list)
at Cvb.Driver.DeviceDiscovery.Discover(Flags flags, SharedATList& list)
at Imaging.CVB.CvbCameraDiscoverer.GetAvailableCameras()

I’ve connected to the active camera from an Access Token of a previous discovery.
I’ve two (Allied Vision GT1930L) cameras connected to my computer using a switch.
It doesn’t make any difference, whether I dispose the ATList from the previous discovery, or don’t. (I’ve tried not to dispose it - for just in case)

The acquisition runs on also on an error.
If the acqusition is stopped before the discovery and then restarted, there is no problem.

Is this a bug, or per design so?

Thank you for your help!

Botond

2

Hi @ABotond,

regarding the crashes: Until we release a :cvb: 13.00.006 version, you can update the GigE Vision transport layer with these files:

Fix_GEV_13_00_005_Win32_DiscoveryCrash.zip (858.1 KB)
Fix_GEV_13_00_005_x64_DiscoveryCrash.zip (1.1 MB)

The file-set is from our current nightly build and I did a discovery stress test on them showing no errors (discover, open, close, repeat). It is intended to be used on the 13.00.005 release (latest as of today). You need to replace the files in:

%CVB%GenICam\bin\win32_i86\TLIs for Win32

or

%CVB%GenICam\bin\win64_x64\TLIs for x64

3

Regarding the acquisition error: when you experience an external SEHException it means, that you got an operating system exception (in this case an AccessViolation). After that the state of the process is corrupted and normal functionality can not be resumed. The only thing you can do is do reduce the damage (try to save necessary data – which might also have been corrupted) and exit the process.

So due to the AccessViolation in the transport layer also acquisition handling is not safe anymore, thus you see the error (I assume an IGrab2 call returned an error). Problem is; behaviour is undefined when something like this happens. All kinds of error can show up.

To sum it up: an SEHException is always a bug and everything following it cannot be trusted.

P.S.: When you use the C-style API we never throw exceptions. So if you see one something has really gone wrong. CVB .Net uses exceptions, but never SEHExceptions.