I have a custom credential provider and the credential implements IConnectableCredentialProviderCredential
. It is written using Visual C++ 2019 and ATL. It works on Server 2016/2019 and Windows 10/11, if I use it on Server 2012R2, then the UI crashes during UAC--trying to elevate a non-admin user to use an Administrator PowerShell session for example.
I attached a remote debugger and the debugger intercepts the exception consistently as: Exception thrown at 0x00007FFE9E627EC3 (authui.dll) in consent.exe: 0xC0000005: Access violation reading location 0x0000000000000008.
I had some logging/debugging code and I could see that the system never calls my Connect()
or GetSerialization()
method on the credential when it crashes. My logging showed the username and password getting set, but then after keying the Enter key or clicking on OK, the process crashes without ever asking the credential to serialize its credentials. The logging showed that the last call into my credential provider was to ICredentialProviderCredential::SetStringValue()
which was corresponding to entering the password before keying the Enter key.
Since it was throwing an access violation, I assumed that I must be passing bad data back to the system when it was calling the ICredentialProvder::GetFieldDescriptorAt()
or possibly the ICredentialProviderCredential::GetStringValue()
or some other CredentialProvider::Get...()
function. I've gone over the methods with fine tooth comb as well as all other methods and have found nothing. For the GetStringValue() implementation, I am calling SHStrDupW()
like in the SDK examples, and for GetFieldDescriptorAt()
I am calling the same functions as the SDK examples. In fact, I copied the SDK code.
I decided to distill my credential provider down to a minimal reproducible example. That minimal example is at https://github.com/willcoxson/CredDemo
If anyone could see where I might be passing bad data back in one of the methods, I'd sure be grateful.
IConnectableCredentialProviderCredential
have sense only for CPUS_LOGON
case. so for other scenarion your QueryInterface
must return E_NOINTERFACE
when system ask for IConnectableCredentialProviderCredential
in your concrete case we have CPUS_CREDUI
scenario. inside function
void CGetSerializationJob::Do(CREDENTIAL_PROVIDER_THREAD_JOB_CONTEXT const &)
system query you for IConnectableCredentialProviderCredential
("9387928b-ac75-4bf9-8ab2-2b93c4a55290" )
and if you return this interface - run next code
system try access some object by pointer - CPLAPCallback::_pSingleton
but pointer is 0. crash exactly at yellow line ( 0xC0000005: Access violation reading location 0x0000000000000008. )