# Failure to interact with Device after reconnection **URL:** \ **Category:** .Net API\ **Created:** [June 2, 2023, 9:59am UTC](https://forum.commonvisionblox.com/t/failure-to-interact-with-device-after-reconnection/1960 "2023-06-02T09:59:30Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![ThomasDb](https://avatars.discourse-cdn.com/v4/letter/t/9d8465/32.png) [@ThomasDb](https://forum.commonvisionblox.com/u/ThomasDb)\ **Post date:** [June 2, 2023, 9:59am UTC](https://forum.commonvisionblox.com/t/failure-to-interact-with-device-after-reconnection/1960/1 "2023-06-02T09:59:30Z")
# Bug description It appears that any attempted interaction with a device via [CVB.Net](http://CVB.Net) fails if it disconnected while a stream was running and if the GenICam VIN is responsible for debayering the image. # Information - OS: Windows 10 Enterprise LTSC, Version 10.0.17763 Build 17763 - Tested with **CVB 13.03.003** and **CVB 14.00.004** - Tested behaviour with own application code and example program **SystemBrowser** (%CVB%\Tutorial\Image Manager\Cvb.Net\SystemBrowser) - Tested with **AlliedVision Mako G-234C** , **AlliedVision Mako G-234B** and **Teledyne Dalsa Nano-M1280** GenICam devices # Related forum post [Camera disconnection](https://forum.commonvisionblox.com/t/camera-disconnection/1596) This post describes a similar problem, but never seemed to reach a conclusion. # Steps to reproduce 1. Launch **SystemBrowser.exe** (%CVB%\Tutorial\Image Manager\Cvb.Net\SystemBrowser\bin\Release) and open a camera with a Bayer sensor 2. Ensure the **PixelFormat** is set to **BayerRG8** or similar 3. (Optional) Set the **TriggerMode** to **On** and **TriggerSource** to anything but **Freerun** , since **Freerun** seems to cause some inconsistent behaviour, especially when debugging. 4. Ensure the device is grabbing after the changed **PixelFormat** has taken effect 5. Interrupt the connection to the device (e.g. by disabling the **TCP/IPv4** stack in the network adapter if connected by **GigEVision** ) # Expected behaviour The **SystemBrowser** application monitors the connection of the device. When the link to an opened device disappears, it will attempt to abort streaming (if applicable), dispose said device and perform a discovery of available devices. If the connection to the device is re-established and a new discovery is performed, the device should reappear in the device list and opening it should be possible # Result The stream is not stopped, the device is not disposed and no automatic discovery is performed. No meaningful interaction with the opened device is possible but triggering a discovery of devices by any means will result in the device no longer being present in the list. If the connection to the device is re-established and a new discovery is performed, the device reappears in the camera list but is not accessible. # Additional information By debugging the application it becomes clear that the following call never returns in **CameraProxy.cs** line 333: ```auto 327 /// 328 /// Stops the Grap 329 /// 330 public void StopGrab() 331 { 332 if (Device.Stream.IsRunning) 333 Device.Stream.Abort(); 334 } ``` Other operations on the **Stream** (**TryAbort()**, **Stop()**, etc.) and **Device** (**Dispose()**) result in the same blocking: pausing the program after such a call shows the thread waiting for current function to return. If the same steps are repeated either with a monochrome camera or a Bayer camera with its output set to **Monochrome** or **RGB8Packed** , there is no issue and the expected behaviour takes place. If the same steps are repeated with a Bayer camera but it is kept in **Freerun** , a breakpoint is triggered before line 333 is reached and execution is not immediately resumed, the expected behaviour might also take place. It is unclear if letting the GenICam VIN debayer the image is truly the cause of the issue, but it at appears related. At the very least this behaviour seems unintended. Could this be confirmed? ---
**Author:** ![Chris](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.commonvisionblox.com/chris/32/1154_2.png) [@Chris](https://forum.commonvisionblox.com/u/Chris)\ **Post date:** [June 6, 2023, 7:18am UTC](https://forum.commonvisionblox.com/t/failure-to-interact-with-device-after-reconnection/1960/2 "2023-06-06T07:18:05Z")
Hi @ThomasDb we can reproduce the behaviour you described and we will see, what we can do to avoid this. I will let you know as soon as there are any news on this.