...Попробуйте вместо GrdLock воспользоваться глобальным именованным мьютексом...

Проблемы:
- если приложение работает в Linux под Wine, то, будучи установленным в разные экземпляры ("префиксы") Wine, приложения одного префикса не видят мьютексы другого. Даже если мьютексы созданы в глобальном пространстве имен Windows (с префиксом "Global\");
- "нативное" приложение под Linux не видит мьютексы Windows-приложений, запущенных в префиксах Wine. Более того, в Linux вообще нет глобальных именованных мьютексов (но можно придумать костыли разной степени колченогости)
- "нативные" приложения под Linux могут быть запущены в докер-контейнрах, изолированных от рабочей хост - среды.
Во всех этих случах приложения могут совместо использовать локальный донгл.
...
Можно ли как-то организовать логическую блокировку донгла на аппаратном уровне? Например, записывать идентификатор сессии в память донгла или что-то ещё. Подскажите.

Обратите внимание, сегодня актуальная версия Guardant SDK - 7 update 9. Найти ее можно у нас на сайте - https://www.guardant.ru/support/developers/sdk.

Да, я 7.9 использовал, конечно. Исправил № в сообщении, извинения.

Я, когда писал сообщение, смотрел № последнего релиза на страничке https://www.guardant.ru/support/release/ - там последний релиз 7.7; возможно есть смысл добавить туда инфорсацию о релизе 7.9?

Обратите внимание, сегодня актуальная версия Guardant SDK - 7 update 9. Найти ее можно у нас на сайте - https://www.guardant.ru/support/developers/sdk.

...
2. Сегодня такую информацию мы уточнить не можем, так как SDK 6.3 обновлялся более 3 лет назад. Вероятно обе ваши ошибки имеют одну природу происхождения, и связаны с некорректной работой инструментов, входящих в SDK 6.3. Уточните, воспроизводятся ли такие ошибки на SDK 7.3?

Сегодня вернулся к этому вопросу: скачал самый свежий DSK (7.9). Баг не исправили. Вот такой цикл всё так же выполняется всего 10 раз, вылетает с кодом GrdE_DongleLocked:

        int i = 0;
        DWORD ret;
        do {
            ret = GrdLock(hGrd, 2000, 3000, GrdLM_All);
            i++;
        } while (!ret);

1. Приложения, защищенные с SDK 7.3 должны работать работать и на Windows XP в том числе. Совместимость есть. Однако сам комплект разработчика все же рекомендуем устанавливать на современных операционных системах.

2. Сегодня такую информацию мы уточнить не можем, так как SDK 6.3 обновлялся более 3 лет назад. Вероятно обе ваши ошибки имеют одну природу происхождения, и связаны с некорректной работой инструментов, входящих в SDK 6.3. Уточните, воспроизводятся ли такие ошибки на SDK 7.3?

2. Уточните, пожалуйста, о какой "исправленной ошибке" идет речь? О той, где одно приложение может разблокировать другое, или о той, где одно приложение может "безнаказанно" вызвать GrdLock() лишь 10 раз?

Обратите внимание! При установке\обновлении Guardant SDK, на компьютере с уже установленным ранее SDK, строго необходимо делать резервную копию базы данных утилиты программирования GrdUtil.exe.

1. К письму приложен 7z - архив, в нем - исходник тестового приложения, само приложение и инструкция по сборке и запуску в MS Word файле Readme.doc. Тест касается https://forum.guardant.ru/post/3662/#p3662

2. По поводу ограничения количества вызовов GrdLock() - https://forum.guardant.ru/post/3659/#p3659 - тест не создавал, для повторения достаточно в цикле вызывать

  fStatus := GrdLock(fGrdHandle, 1000, Cardinal(-1), GrdLM_All);

- анализируя возвращаемый код fStatus и подсчитывая количество итераций цикла.

Пример с исходным кодом
Версия SDK с которой проводите защиту
Версия ОС
Среда разработки
Отчет утилиты диагностики ключа, с которым защищаетесь

При параллельном запуске приложений, первое приложение блокирует ключ по GrdLock().  При этом значение параметра dwTimeoutAutoUnlock в GrdLogout() равно 0xFFFFFFFF, т.е. время блокирования не ограничено и блокировка может быть снята только функцией GrdUnlock.

Запускается второе приложение, которое вполне логично получает отказ по GrdLock() (т.к. первое уже заблокировало ключ), затем это второе приложение просто выполняем GrdLogout(), GrdCloseHandle(), потом затем снова инициализирует дескриптор ключа, выполняем поиск ключа, и - вуа-ля! - вызов GrdLock() выполняется успешно, первое приложение "отваливается" от ключа с кодом GrdE_DongleLocked - ну, красота, в общем.

Еще раз напомню, что значение параметра dwTimeoutAutoUnlock в GrdLogout() равно 0xFFFFFFFF, т.е. время блокирования не ограничено и блокировка может быть снята только функцией GrdUnlock (согласно документации).

Уважаемые разработчики, кто-нибудь вообще тестировал метод GrdLock()?

...

Остался вопрос: как обеспечить эксклюзивный доступ к ключу в цикле, и при этом не заблокировать ключ надолго в случае "зависания" приложения?

Придумал костыль:

- в начало цикла, перед вызовом GrdLock()

var
  fLockCounter: DWORD;
begin
...
  Начало_Цикла

    while True do begin
      GrdGetInfo(fGrdHandle, GrdGIL_LockCounter, @fLockCounter, SizeOf(DWORD));
      if fLockCounter <= 1 then Break; // fLockCounter и так маленький (< 10)
      FStatus := GrdUnlock(fGrdHandle);
      if FStatus <> GrdE_OK then 
        //  действия в случае, когда ключ захвачен в другой сессии
    end;

    FStatus := GrdLock(...);
    if FStatus <> GrdE_OK then 
      //  действия в случае, когда ключ захвачен в другой сессии
...
... Тело цикла
...
Конец_Цикла

Описание: приведенный код не позволяет счетчику блокировок увеличиться до недопустимого значения.
Если счетчик не боле, чем 1, то предполагается, что ключ был захвачен в этом сеансе. Иначе (счетчик больше 1), выполняется попытка уменьшить значение счетчика блокировок. Если не получилось - следовательно, ключ заблокирован в другой сессии.

~~~~~~~~

Ну, хоть так.

Можно было бы такое поведение и в документации отразить, тем более, что вопрос уже возникал: https://forum.guardant.ru/post/1092

~~~~~~~~~~~~~~~~~

Остался вопрос: как обеспечить эксклюзивный доступ к ключу в цикле, и при этом не заблокировать ключ надолго в случае "зависания" приложения?

Итак:

Счетчик увеличивается на 1 при вызове GrdLock().
Счетчик уменьшается на 1 при вызове GrdUnlock() либо автоматически, по достижении момента времени, равного моменту последнего вызова GrdLock() плюс время, заданное в параметре dwTimeoutAutoUnlock.
Если счетчик равен 10, то вызов GrdLock() завершится с кодом GrdE_DongleLocked.

Задал время выполнения итерации цикл равным ровно 1 секунда

Начало_Цикла
  fStatus := GrdLock(fGrdHandle, 1000, aValue, GrdLM_All);
  Проверка_Значения (fStatus);
  ...
  ... // Что-то делаю
  ...
Конц_Цикла

Выяснил:

Если значение времени авторазблокировки aValue меньше времени итерации цикла (например, aValue = 900, а dwTimeoutAutoUnlock = 1000), то GrdLock() всегда отрабатывает успешно.

Если значение времени авторазблокировки aValue больше времени итерации цикла (например, aValue = 1100, а dwTimeoutAutoUnlock = 1000), то GrdLock() отрабатывает успешно лишь 10 раз.

Непонятно, как блокировать ключ с учетом появившихся в результате экспериментов новых сведений.
Можно, конечно, после первого успешного захвата ключа просто периодически вызывать GrdLock(), не заботясь о коде завершения ("это же я первым ключ захватил!"), но в случае с перезапуском удаленного сервера, такая тактика, имхо, не будет правильной...