Thank you for detailed description.
The reason why the browsing dialog takes long is clear - when the OPCEnum fails, the browsing from registry is used, and that is slow, especially remotely, because it requires going through many registry keys one by one.
The OPCEnum as distributed by the OPC Foundation is implemented as "Local Server" (which can also be remoted), and nothing else. Therefore, when we allow all possible execution context, it is the local OPCEnum as "Local Server", or a proxy of a remote OPCEnum (which is considered "Remote Server") that should be chosen and work. And it does work - except in your situation; we haven't seen this problem before. Which Windows version are you using?
A hypothesis is that somebody has installed and registered a (non-functional) "inproc handler" for OPCEnum on your machine. This handler gets chosen, because it is allowed by our default execution context, and inproc servers and inproc handlers are generally faster so I would expect Windows to prefer them when it has the choice; and the handler fails.
Since it would be very unusual for OPCEnum to actually be anything else than "Local Server" or "Remote Server" anyway, based on this report we will probably change the default execution context for OPCEnum in some future QuickOPC version/build, in order to prevent possible problems.
Can you live with the workaround you found for now?
