Поскольку поиск сетевого ключа и логин проходят без проблем, то в данном случае возможно что в момент выполнения чтения защищенной ячейки, действительно, по каким то (характерным для инфраструктуры ЛВС и рабочих станций конкретного клиента) причинам, происходит разрыв соединения (например, какой либо антивирус или сетевой экран обрывают соединение, считая по своим, субъективным причинам, передаваемый трафик ненадежным).

Тут следует убедиться, что в ЛВС клиента и на целевом компьютере, нет никаких механизмов (настройки маршрутизации, доменные политики, средства проактивной защиты (антивирусы, антиспамы, брандмауэры и.тп)) препятствующих обмену трафиком между защищенным приложением и сервером Guardant Net.

Для того чтобы однозначно исключить влияние подобных факторов следует выполнить проверку по следующему алгоритму:

1) Взять два ПК полностью отключенных от ЛВС (желательно не те на которых ведется текущее тестирование);
2) На одном установить драйвер, подсоединить ключ и запустить сервер Guardant Net, а на другом установить защищенное приложение;
3) Соединить данные две машины, прямым (без использования хабов или маршрутизаторов), кроссовым патчкордом;
4) Вручную настроить стандартную (вида: 192.168.x.x) подсеть между данными компьютерами;
5) Выключить абсолютно все средства проактивной защиты запущенные на обоих компьютерах;
6) Запустить защищенное приложение на ПК-клиенте.

Можете уточнить, почему может появляться ошибка GrdE_NetConnectionLost ?

Используется для защиты API и сервер 6.2. У себя не могу воспроизвести, а у одного из многих пользователей это происходит на начальном этапе инициализации и чтения защищенной ячейки при, в общем то стандартной, последовательности вызовов SetFindMode-Find-Login-SetWorkMode-PIRead. При этом Web-интерфейс на сервер работает без проблем, ini-файлы на сервере и клиенте стандартные.

Не подскажите ли какая из API функций может выдать например ошибки {GrdE_NetDongleNotFound,GrdE_NetServerReloaded, GrdE_NetConnectionLost }

Ошибка GrdE_NetDongleNotFound, например, характерна для функции GrdFind, а ошибки GrdE_NetServerReloaded и GrdE_NetConnectionLost всегда являлись весьма специфическими, проявлялись редко и для последних версий (6.х) сервера сетевых ключей Guardant Net, Guardant API и автозащиты проявляться не должны.

В целом, построение системы анализа состояния, например, сетевых интерфейсов ПК при помощи Guardant API не совсем правильно, в общем случае все сводится к детектированию факта наличия валидного для защищенного приложения ключа. Дополнительная диагностическая информация, в этом смысле, достаточно скудна и проверять состояние ЛВС, доступность сервера с выяснением конкретных причин сбоя с ее помощью едва ли удастся.

Отдельно хочу отметить что в нашем  стандартном примере по использованию API (примеры для разных сред разработки можно найти в папке «\Samples» установленного комплекта разработчика - директория по умолчанию: %Program Files%\Guardant\Guardant 6\%Public Code%\Samples) показан некоторый, на наш взгляд достаточно оптимальный, механизм анализа кодов ошибок функций API.

Функция GrdCheck, как и указанно в ее описании, в качестве выходных параметров выдает стандартные коды возврата ошибок (подробнее см. справку по Guardant API: файл «GrdAPI.chm», по умолчанию в папке: %Program Files%\Guardant\Guardant 6\%Public Code%\Doc\), которые и следует анализировать.

Эти же ошибки возвращают и другие функции Guardant API, и на основе их и следует самостоятельно строить систему анализа и проверки ключа.