Тогда получается совсем странная ситуация. Программа вылетает из-за того, что возникают ситуации с одновременным доступом ключу методами 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 и, не выполняя автозащиту, потестируйте сервис.
Если падение не воспроизведется, то выполните автоматическую защиту с указанными ранее параметрами и также проверьте.
Сообщите результаты.
]]>