запросы чтения ключа идут с интервалом 10-ки и 100-и миллисекунд
моя гипотеза о причине: если драйвер ключа не будет успевать отвечать (это вполне вероятно на компе под нагрузкой, а платформа еще и рашифровывает прочитанное из ключа), то защитные механизмы платформы сочтут "по замерам времени получилось, что код "долго" (больше положенного) выполнялся в крит.секции, похоже нас трассируют в отладчике"
у меня лично компу более 10 лет, но проц у меня i7 4 физических ядра, каждое с hyper threading, и оперативки 32Гига - больше мазерборд не скушает (я бы дал).
на шустром компе такое поведение может не проявиться
но это только лишь мое предположение, можно включить более подробное логирование, но мне не хватит опыта в нем разобраться.
напоследок, я бы проделал последний эксперимент, но тут нужен еще один физический комп для эмулятора:
1) поставить на него эмуль и Lic. Manager - раздавать ключи по сети
2) тест гилева выполнять в ситуации, когда локальный эмулятор не работает. ключик ловится по сети со 2-го компа
3) для ловли ключа из сети возможны болшие задержки, поэтому парни в "1 сек" ввели параметры таймаутов в hethasp.ini (смотреть пост #177). при работе с локальным ключом невозможно увеличить таймауты на операциях чтения ключа. Поэтому на слабом компе тест гилева надо выполнять с сетевым эмул-ом и hethasp.ini как в посте #177.
я в
другой ветке форума предположил, что крах "Ключ защиты программы больше не доступен! Работа программы завершена." вызван недоработкой парней, сделавших "лекарство" unipatch (rbc_icp - это он же с добавлением лечения краха "повреждение девственности платфлормы" ). Но теперь у меня созревает подозрение, что крах "Ключ защиты программы больше не доступен! Работа программы завершена." ловят те, кто работает с локальным ключом/эмулем на относительно слабом железе.
Социальные закладки