"Unspecified error" is transformed from COM error E_FAIL, which tells all and nothing. Knowing that it is used for many reasons and by many objects, I did not want to add to confusion, and have stayed away from explicitly generating E_FAIL inside QuickOPC, except for very few instances which I will eventually remove as well. It is therefore quite likely that this error comes from the target OPC server, and I would suggest they try to determine this by either using server diagnostics if available, or trying other OPC client to read from the same tag. I do not know the application logic, but if this is genuine error reported by the OPC server, then retrying may not be the right thing to do. It may be a bug in the server, or it may be the server telling the client the right thing – either way, the app is informed about this, and unless it absolutely needs to obtain the value, it should be prepared to handle the problem somehow without retrying. If efforts to determine the cause do not help, then with the debug build of the component and some special registry settings, we should be able to “trap” the precise place in code where it first occurs, but I would like to reserve this as last resort.
Note that there already is an internal retry mechanism for any errors that happen during AddItems call on the OPCGroup object. For every item that reports an error in AddItems (any error – not just “invalid item id”), the item is marked as “in failure”, and kept on list. Periodically (default: 1 minute), the component goes through the list of items that are “in failure”, and those that are in the list longer than certain period without retrying (default: 5 minutes) will be passed to AddItems again. If the error is indeed coming from AddItems, this is yet another reason why the user’s code should NOT quickly retry: It will not do anything. Items that are “in failure” will simply keep returning the error they gave in the last call.