Тогда получается совсем странная ситуация. Программа вылетает из-за того, что возникают ситуации с одновременным доступом ключу методами API и автозащитой. Соответственно, чем чаще автозащита будет проверять ключ, тем еще чаще будет вылетать программа.

Для представленных примеров это также следствие слишком избыточного применения функции блокировки GrdLock, которая в основном нужна для обеспечения "безопасности" во время работы функций обновления памяти ключа, чтобы предотвратить в момент обновления обращения к ключу от любых других функций.

Также стоит все же внимательно следить за использованием GrdHashEx, которая, как я уже упоминал раньше, также блокирует ключ на время работы. Вполне уместным может быть использование программных функций вычисления хеш-суммы, что скорее всего не сильно уменьшит стойкость хорошей схемы защиты но привнесет прирост в производительности.

eugene_sm пишет:

Антон Тихиенко пишет:

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

Я правильно Вас понял, что мне это как-то поможет?

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

Тогда получается совсем странная ситуация. Программа вылетает из-за того, что возникают ситуации с одновременным доступом ключу методами API и автозащитой. Соответственно, чем чаще автозащита будет проверять ключ, тем еще чаще будет вылетать программа.

Антон Тихиенко пишет:

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

Я правильно Вас понял, что мне это как-то поможет?

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

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

Я правильно Вас понял, что мне это как-то поможет?

Уважаемые разработчики! Как скоро можно ожидать решения проблемы? Работа стоит...

Прошу прощения за задержку с ответом.
Кардинальных изменений можно ждать только с выходом следующего релиза SDK, где будет реализована альтернативная утилита автоматической защиты с поддержкой x64 для native-приложений и возможностью защиты *.dll. Но это не раньше конца текущего года.
Защита большего числа импортируемых функций, а также извлечение большего количества инструкций (лучше это делать по списку, при помощи профайлера) выправят ситуацию в лучшую сторону.

eugene_sm пишет:

Когда примерно ждать исправления?

Прошу прощения, в данном случае это все же не столько проблема сколько "фича".
Дело в том, что используемая в примере функция GrdHashEx на время работы с аппаратным алгоритмом блокирует электронный ключ и автозащита не может работать с ним.
В данном случае пользоваться можно, например, программной реализацией вычисления хеш-суммы.

Хм. Странная фича, больше похожая все же на баг ;)
Кстати, не менее странная "фича" возникает (правда не всегда, но очень часто) при одновременном запуске нескольких копий одного защищенного автозащитой приложения, типо невозможно получить доступ к ключу.

И еще, до сих пор можно у защищенного приложения заморозить потоки GRDVKC32.dll* и спокойно продолжать работать без ключа :)

Когда примерно ждать исправления?

Прошу прощения, в данном случае это все же не столько проблема сколько "фича".
Дело в том, что используемая в примере функция GrdHashEx на время работы с аппаратным алгоритмом блокирует электронный ключ и автозащита не может работать с ним.
В данном случае пользоваться можно, например, программной реализацией вычисления хеш-суммы.

eugene_sm пишет:

Отправил на хотлайн тестовый пример с исходниками, маску и прочее.

Проблему подтверждаем.
Передана на исправление в отдел разработки.

Добрый день!

Когда примерно ждать исправления?

Отправил на хотлайн тестовый пример с исходниками, маску и прочее.

Проблему подтверждаем.
Передана на исправление в отдел разработки.

Проблема на мой взгляд кроется в файле GrdVkc32.dll. Выяснил с помощью ProcessExplorer от SysInternals.

Прилагаемый пример стабильно зависает(иногда вылетает) ровно через минуту.
Если после зависания открыть в Process Explorer мой процесс и посмотреть текущие потоки, можно увидеть что большинство потоков заморожены. Если в определенной последовательности (заморозив потоки от GrdVkc32.dll) их размораживать можно добиться восстановления работоспособности приложения или же получить вылет программы.

Кстати, несколько лет назад я уже писал Вам по этому поводу. Тогда автозащита в момент вытаскивания ключа не блокировала все потоки приложения и через все тот же Process Explorer можно было продолжать пользоваться приложением неограниченное время. С тех пор это Вы исправили :)

А вот с автозашитой проблемы повторяются. Программа вылетает через некоторое время.

Это уже куда понятнее.

Пришлите на наш e-mail ( hotline@guardant.ru ) любое тестовое приложение-сервис, не защищенное автозащитой, которое после защиты с указанными параметрами "падает".
Также приложите *.nsd-файл маски, которая прошита в электронных ключах, участвующих в тестировании.

Будем отлавливать ошибку.

eugene_sm пишет:

Замена константы не помогла, ситуация с вылетами не изменилась.

Вообще странно, если все компоненты Guardant API использовались из состава SDK последней версии, то значение константы должно было быть уже $4000. Скорее всего API используется "староватое".

Соберите приложение с объектными и заголовочными файлами строго из состава Guardant SDK 7 Update 2 и, не выполняя автозащиту, потестируйте сервис.

Если падение не воспроизведется, то выполните автоматическую защиту с указанными ранее параметрами и также проверьте.

Сообщите результаты.

Добрый день!

Заголовочные файлы действительно были от 6 версии.
Вчера все поменял до последней версии.

Без автоматической защиты сервис выполнялся всю ночь и работает до сих пор без ошибок.
А вот с автозашитой проблемы повторяются. Программа вылетает через некоторое время.

Замена константы не помогла, ситуация с вылетами не изменилась.

Вообще странно, если все компоненты Guardant API использовались из состава SDK последней версии, то значение константы должно было быть уже $4000. Скорее всего API используется "староватое".

Соберите приложение с объектными и заголовочными файлами строго из состава Guardant SDK 7 Update 2 и, не выполняя автозащиту, потестируйте сервис.

Если падение не воспроизведется, то выполните автоматическую защиту с указанными ранее параметрами и также проверьте.

Сообщите результаты.