Credential Provider showing incorrect tiles

Question

EDIT: Turns out I was probably overthinking this. See answer below.

This may or may not be better on SuperUser, it's regarding issues with a few workstations failing to cleave to the Enterprise standard. All references here are to Win7 Professional installations.

Essentially, a certain machine is now showing this when the computer is locked:

(Image 1)

Rather than this:

(Image 2)

It's a big change. A different credential provider tile is being displayed, all our branding is ripped out. The normal behaviour is to go straight to the prompt to unlock the PC, but this machine requires you to actually click on the 'User Unlock' tile instead.

When you do, a rather generic prompt, again without branding and without the username pre-populated, is presented. I suspect it may be one of the default providers on a default configuration that comes with the OS.

Unfortunately I no longer have access to the broken system (I suggested the local tech just do a re-image as that is an option in our case, and faster for a rare issue).

Does anyone know good ways to troubleshoot these sorts of problems? Since giving the re-image advice, I've compared the credential provider registry on both systems, and the main difference seems to be the absence of the Novell Credential Provider on the borked system. Apparently when this credential provider is installed, it defines its own filter list. Without the filter in the main credential providers list at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Provider Filters\,

the filter list contains only a generic entry (I think it is {DDC0EED2-ADBE-40b6-A217-EDE16A79A0DE}), so it isn't redirected to the novell list at:

HKEY_LOCAL_MACHINE\SOFTWARE\Novell\Authentication\NCCredProvider\FilterList

This filter list contains some of the more familiar providers like {6f45dc1e-5384-457a-bc13-2cd81b0d28ed}.

My current suspicion for root cause is either something borked in group policy (likely local to the machine as otherwise the entire site should have problems), or a misconfiguration or attempted uninstallation of the novell client interacting negatively with our Enterprise MOE that assumes the novell authentication provider will be present.

---

UPDATE

Having checked my home system, I haven't found any glaring differences in the registry with the borked system. The filter GUID DDC0EED2-ADBE-40b6-A217-EDE16A79A0DE is linked to authui.dll in both cases And the Cred Provider list seems to be mostly the same.

However, my home system goes straight into the default unlock prompt (with my username pre-populated) when the workstation is locked, similar to Image 2 above without the branding, which is unusual because this 'User Unlock' provider appears to be a default fallback, yet it isn't showing up on the home system & I haven't mucked around with the credential provider behaviour on my home system at all. They appear to be presenting different behaviour despite both using the generic filter.

---

However, the difficulty to find any information regarding the administration of credential providers (as opposed to coding them) online makes me wonder if anyone used to dealing with these sorts of issues has a good check-list to go through to track down these sorts of problems quicker.

Things like:

• Does the credential provider service look anywhere other than HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication to get its providers (not counting using the GUID's from here to lookup classes_root)? For instance, does it check the Wow6432node version at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Authentication?
• Is there any form of logging that can be turned on (or turned up, if it logs to the event viewer)? If it shows up in the event viewer either by default or after tweaking a setting, what event ID's should I be looking for in which logs?
• Combining and extending on the above, does anyone have a link to either good existing troubleshooting documents, or even better a full description of how the credential providers are turned from registry entries and CLSID DLL references into the specific tiles the user ends up seeing? (Not the specification or how to roll your own, but the end-to-end process of constructing the various credential provider screens that are shown to the user in various circumstances.)

Answer 1

I've found and solved the issue in this case. After going so far as to compile my own credential provider and scour the registry, the solution was surprisingly simple.

(All troubleshooting and picture editing done on a Win7 machine.)

An SCCM branding application package that was designed for Windows 8/8.1 had been mistakenly deployed to the Windows 7 machine. While most of the effects were merely cosmetic, the

C:\ProgramData\Microsoft\User Account Pictures\user.bmp

file was screwed up just enough to confuse the credential provider (despite being viewable in MSpaint and the Windows Image Viewer.) Instead of displaying a blank tile, the regular logon provider fails completely and displays no tile at all, making regular logon after locking the PC impossible.

In fact, removing the (manually added, designed for administrators to unlock machines) user unlock provider results in a completely blank screen with no logon options at all.

This seems like poor error handling - surely any error in displaying the user tile should cause the credential provider to abandon processing and just display a blank tile, or a default tile pulled from somewhere? That said this must be a special failure case, as by contrast, a totally borked bitmap file (monkeyed around in the hex editor until paint and WIM couldn't open it), successfully fails processing and displays a blank, usable tile:

(Ignore the sudden appearance of the smart card provider. This was a different machine with the same issue, a laptop, and I'm fairly sure it had this provider already.)

There doesn't seem an immediately obvious way to find the bitmap encoding that was used, but fixing the problem for me was as easy as opening the file up in mspaint, changing a single pixel and saving.

Looking at the problem file in a hex editor, there were a bunch of extraneous nulls in the data section in a pattern of three bytes of pixel data + 1 null. By contrast, the version saved by paint has no nulls after the header section. The paint version also has a header roughly 100 bytes shorter.

I will run this again on a Windows 8.1 machine and see if the behavior is different. Perhaps the logon UI in that OS can handle them better (indeed, the image that caused the problem may well have been created and tested on Windows 8/8.1 only).