Hello; yes, this is quite weird. Obviously the error is coming from the security. Because the browsing works, the issue probably has to do with the "reverse" way of communication: In OPC Data Access, the OPC Server needs to make callbacks into the OPC Client - so it could be failing at the moment where QuickOPC registers its "sink" interfaces for the callbacks with the OPC Server - these are only needed for reads/writes/subscriptions, but not for browsing.
I do not know why the supplied C# app should differ from VB or from your own apps. The only idea that comes to my mind has to with default DCOM settings on the *client* machine. For the "reverse" communication to work, DCOM has to be set on the client as well. This can be done for specific registered applications, or the default can be set for other "unknown" applications, by DCOMCNFG program. Normally, however, QuickOPC should override most settings that apply to the client side, so that the communication works. From the fact that the same component behaves differently under different apps, I guess that there may be some relevant setting that QuickOPC still takes from the system.
For this reason, and without having to troubleshoot directly on the problematic system, I would for start suggest to experiment with following settings:

DCOMCNFG "Default Properties": For "Default Authentication Level", try both "Connect" and "None".
"Default Impersonation Level" is normally "Identify"; try "Impersonate" as well.
DCOMCNFG "COM Security Tab": For test only, make it wide open (I can provide more help here if you need - let me know). If this helps then of course for the production configuratation it'll have to be shrunk down again.
Try both 'true' and 'false' for the static property EasyDAClient.ClientParameters.TurnOffActivationSecurity (this has to be set before any connection is made).

Regards