SampleV2CredentialProvider does not work on windows 11

Question

Hello,

I was trying to implement a 3rd party credential provider and wanted to run the sample before modifying it, on my windows11vm. I built it within the VM using visual studio 2022, but it did not change my logon screen.
I have placed the DLL in system32 (it is built as release x64), and registered the application with ./register.reg. I also tried using regedit /s register.reg.

I checked the register and found the following in place:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers{5fd3d285-0dd9-4362-8855-e0abaacd4af6}

        Default SampleV2CredentialProvider

    HKEY_CLASSES_ROOT\CLSID\{5fd3d285-0dd9-4362-8855-e0abaacd4af6}

        InprocServer32 had 

            Default Value = "SampleV2CredentialProvider.dll" - i tried changing this to "C:\Windows\system32\SampleV2CredentialProvider.dll", which didn't fix things either

            ThreadingModel = "Apartment"

I tried messing with the registry directly, and can provide more details on that if you want.
I checked the events viewer under

windows logs -> system sources

        Winlogon: User Logon Notification for Customer Experience Improvement Program

        User Profile Service: Nothing

        CredentialProviderFramework: Nothing

and windows logs -> application find
SampleV2CredentialProvider: Nothing

        Winlogon : The winlogon notification subscriber <SessionEnv> was unavailable to handle a critical notification event. (I dont know what this means)   

I've also ran the process monitor and captured the logon process, which has verified that logonui.exe has registered the dll successfully. I can provide this logfile if requested.
I've also ran logman trace on the services listed below, which I can provide as well.
logman update trace CredProviderTrace -p "Microsoft-Windows-Winlogon" 0xFFFFFFFF 0xFF

logman update trace CredProviderTrace -p "Windows Winlogon Trace" 0xFFFFFFFF 0xFF

logman update trace CredProviderTrace -p "Microsoft-Windows-Shell-AuthUI" 0xFFFFFFFF 0xFF

logman update trace CredProviderTrace -p "Microsoft-Windows-AuthenticationProvider" 0xFFFFFFFF 0xFF

logman update trace CredProviderTrace -p "Local Security Authority (LSA)" 0xFFFFFFFF 0xFF

logman update trace CredProviderTrace -p "Microsoft-Windows-OtpCredentialProviderEvt" 0xFFFFFFFF 0xFF

logman update trace CredProviderTrace -p "Microsoft-Windows-CertificateServicesClient-CredentialRoaming" 0xFFFFFFFF 0xFF

logman update trace CredProviderTrace -p "Microsoft-Windows-WebAuth" 0xFFFFFFFF 0xFF

logman update trace CredProviderTrace -p "Microsoft-Windows-WebAuthN" 0xFFFFFFFF 0xFF

logman update trace CredProviderTrace -p "Security: Kerberos Authentication" 0xFFFFFFFF 0xFF

logman update trace CredProviderTrace -p "Security: NTLM Authentication" 0xFFFFFFFF 0xFF
What I found from that there was no CoCreateInstance, CLSID, DllGetClassobject, or other COM registration/initialization for the Dll.

Where do I go from here?

Answer 1

Hello @Isaac Burns ,

Thanks for the detailed write-up. Based on what you describe, I'd lean toward this not being a build or registration failure, but there are two things worth ruling out first.

The first is that the sample tile may actually be there, just not selected by default. In CSampleProvider::GetCredentialCount() the sample returns CREDENTIAL_PROVIDER_NO_DEFAULT and autoLogon = FALSE, so its tile isn't auto-shown. Windows keeps the last user's tile, and the sample only appears once you click "Other user" / switch user. Since it looks like a normal password field, it's easy to miss.

The second is that the missing CoCreateInstance in your trace may just be a tracing-scope artifact. LogonUI.exe runs on the secure desktop (a different desktop/session), so a capture started from your interactive session usually won't see its COM activity. I wouldn't treat "no CoCreateInstance" as conclusive. A boot/global WPR trace tends to capture that path better.

To narrow down the cause, you can try reproducing what LogonUI does from a normal app like the example below. This separates "is the COM object healthy?" from "is it being shown?":

#include <windows.h>
#include <credentialprovider.h>
#include <stdio.h>
// {5fd3d285-0dd9-4362-8855-e0abaacd4af6} : must match guid.h / register.reg
static const CLSID CLSID_CSample =
    { 0x5fd3d285,0x0dd9,0x4362,{0x88,0x55,0xe0,0xab,0xaa,0xcd,0x4a,0xf6} };
int wmain() {
    CoInitializeEx(nullptr, COINIT_APARTMENTTHREADED);
    ICredentialProvider* p = nullptr;
    HRESULT hr = CoCreateInstance(CLSID_CSample, nullptr,
                                  CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&p));
    wprintf(L"CoCreateInstance hr=0x%08X\n", hr);
    if (SUCCEEDED(hr)) {
        DWORD count = 0, def = 0; BOOL autoLogon = FALSE;
        p->SetUsageScenario(CPUS_LOGON, 0);
        p->GetCredentialCount(&count, &def, &autoLogon);
        wprintf(L"count=%lu default=0x%08X\n", count, def);
        p->Release();
    }
    CoUninitialize();
    return 0;
}

The returned HRESULT should narrow it down fairly quickly. If it's 0x00000000 (S_OK), the DLL is fine, and you can focus on clicking "Other user" after a sign-out/reboot, treating the trace as a scoping issue. If it's 0x8007007E (ERROR_MOD_NOT_FOUND), that points to a missing dependency and most likely a Debug/CRT build; switching to a static CRT (C/C++ -> Code Generation -> Runtime Library -> /MT) removes the VC++ redist dependency. If it's 0x80040154 (REGDB_E_CLASSNOTREG), that's a CLSID mismatch between guid.h and register.reg worth re-checking.

References:

• GetCredentialCount
• Winlogon & credential providers

If you can share the HRESULT and whether the tile shows under "Other user", I'm happy to dig further. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Answer 2

On Windows 11, a custom logon credential provider must fully implement the required COM interfaces and correctly participate in the Winlogon/Credential Provider framework; simply having the DLL registered and loaded is not enough for its tile to appear.

Key points to verify based on the platform behavior described in the documentation:

1. Implement the correct interfaces (V2 provider recommended)
   The provider must implement at least:
   • ICredentialProvider
   • ICredentialProviderCredential For a V2 provider (recommended on Windows 10/11), it must also implement:
   • ICredentialProviderCredential2
   If these interfaces are not implemented correctly, Winlogon/LogonUI can load the DLL but will not be able to enumerate or display any tiles.
2. Support the correct usage scenarios
   Credential providers are queried per usage scenario (for example, logon, unlock, credential UI). The provider must correctly handle the usage scenarios it is intended to support via CREDENTIAL_PROVIDER_USAGE_SCENARIO. If it returns that it does not support the current scenario, LogonUI will not show its tiles even though the DLL is registered and loaded.
3. Correct registration and COM class mapping
   The registry entries under:
   • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers (mapping provider GUID → friendly name)
   • HKEY_CLASSES_ROOT\CLSID\{provider-guid}\InprocServer32 (mapping provider GUID → DLL path and threading model)
   must match the CLSID that the provider actually exposes in its COM class factory. If the CLSID in the DLL does not match the GUID used in the registry, CoCreateInstance for that CLSID will fail, and no tile will be created, even if the DLL is present and loaded.
4. Understand that providers only gather credentials, not enforce logon
   The provider’s job is to describe required credential fields, collect them from the user, and serialize them for authentication. The actual logon enforcement is handled by the local authority and authentication packages. If the provider does not correctly package credentials for interactive logon, it may be ignored or fail silently at runtime.
5. Avoid wrapping system providers when testing
   The documentation explicitly discourages wrapping system credential providers because changes to system providers can break wrappers and even prevent logon. For initial testing on Windows 11, use the sample as a standalone custom provider rather than as a wrapper around an existing system provider.
6. Use the official sample and SDK guidance
   The Windows SDK includes a sample credential provider under \Samples\Security\CredentialProvider. Comparing the implementation and registration of that sample with the current DLL can help identify mismatches in GUIDs, interfaces, or usage scenario handling.

Given that Process Monitor shows the DLL being loaded but there is no CoCreateInstance or DllGetClassObject activity, the most likely issues are:

• CLSID mismatch between the DLL and the registry entries, or
• The provider indicating that it does not support the current CREDENTIAL_PROVIDER_USAGE_SCENARIO, so LogonUI never attempts to instantiate it.

Verifying the CLSID consistency and the ICredentialProvider implementation (especially how it responds for the logon scenario) is the next step.

---

References:

• Credential providers in Windows
• Winlogon and Credential Providers