Насчет того, какой вызов соответствует запросу пароля тут давненько идут баталии, полной правды пока не видел. В теории можно вызвать CryptAcquireContext (создать hProv), потом установить для hProv параметр с пин-кодом и запроса не будет при всех операциях с этим hProv (а то и с этим контейнером - если закэшируется пароль в хранилище). Из этого как бы следует, что CryptAcquireContext не запрашивает пароль. В теории.

Также очевидно что если к моменту вызова CryptSignHash пин-код не сохранен средствами криптопровайдера, не закэширован в хранилище (за это отвечает Microsoft CryptoApi) и не установлен для конкретного hProv, то CryptSignHash вызовет обращение к закрытому ключу и запрос пин-кода точно будет. Про то, что в промежутке между CryptAcquireContext и CryptSignHash - не ясно, в теории тоже не должно спрашивать.

Например, при подписи xml хэш считается минимум 2 раза, подписывается только последний. Иногда для первого вычисления хэша также вызывают контекст с контейнером вместо VERIFY_CONTEXT.

Кроме того, мне вспоминается поведение КриптоПро CSP когда у меня запрашивались пин-коды от трех "первых попавшихся" контейнеров и если в них не находилось нужного, выдавалась ошибка. Не очень хорошо помню при какой ситуации это было. При "автоопределении" контейнера, соответствующего сертификату или при вызове CryptAcquireCertificatePrivateKey.Сертификат это сертификат, в нем не хранится ссылка на контейнер ЗК. В хранилище ссылка хранится, но некоторым плагинам этого мало и они перечисляют сами контейнеры, а вдруг токен не вставлен. Контуровская диагностика активно продвигает драйверы рутокена, что на самом деле контейнер не на токене - алгоритм не волнует. Так что и плагин может быть написан с упором на токены. Более того, диагностика еще и выдает рекомендацию использовать КС1 вместо КС2.Модальное окно запроса пароля? Серьезно? Модальное - это когда не дает переключиться на какое-то другое (родительское) окно, на версии 4 мне такое не встречалось - для этого надо специально передавать hwnd родительского окна.