With those symptoms it’s very likely that an uncooperative Transport Layer (TL) is installed on the system. Transport Layers are enumerated by both, the Management Console’s Device Configurator and the GenICam Browser. Every TL found on the system will be used the the GenICam.vin/GenICam Browser/Device Configurator for detecting compatible devices. If, to put it neutrally, the implementation of the GenApi and the TL are “on opposite ends of the standard” a crash is - unfortunately - a possibility.
There are ways to verify this and find out which TL is not cooperating with , though. One possibility is to press the “Programm debuggen” (= “Debug program”) option on the second dialog if a development environment is available on the system. In that case, have a look at the call stack of the thread that raised the problem. In all likelihood you will find a module with a name ending in *.cti on top of the call stack. *.cti is the standard extension for TLs (for example the TLs installed by are named CVUSBTL.cti and GevTL.cti). If you don’t have access to a development environment on that machine you can also produce a dump file and pass that on to a machine that has one or to us to analyze it.
Another option is to use the Dependency Walker and launch the GenICam Browser inside that tool (make sure you download the correct the architecture of the Dependency Walker) it will show which modules are being loaded - just look for the TL file that gets loaded right before the program fails.
Once the offending TL has been identified it usually suffices to rename the *.cti file so that won’t find it any more (but keep in mind that other software you have installed might need it again later on…).