Skip to content

How to debug a Credential Provider locally

Here is a quick and easy way to debug a Credential Provider running on your development machine, without needing to set up a kernel debugging session with two computers. Before you go down this road, let me tell you a little bit about LogonUI.exe behavior (as seen on Windows 7 ultimate SP1 64 bits) set to require CTRL-ALT-DEL to log on.

  • Every time you type CTRL-ATL-DEL, a new LogonUI process is launched.
  • LogonUI will try to load any registered Credential Providers COM objects.
  • You can run any process on the secure desktop

With that knowledge, it is easy to set up a debugging session for your Credential Provider, right on your development machine. Before I continue, be aware that it might affect the stability of your computer temporarily, as the following illustration shows.


To debug your credential provider, you will need this :

I guess you could also use Visual Studio instead, ymmv. If it works, please drop us a line in the comments.

To start debugging, here is what you have to do:

  1. Start a command shell on the Secure Desktop with this command:
    psexec -dsx cmd.exe
  2. Build a debug version of your Credential Provider and register it.
  3. Type CTRL-ALT-DEL to switch to the secure desktop. That will also launch LogonUI.exe
  4. Hit Alt-Tab to switch to the command prompt you started at step 1
  5. Change to the directory where your source code is
  6. Debug LogonUI.exe and set the source path at once, with this command :

    windbg –pn logonui.exe –srcpath %CD%

That’s it. You might not be very familiar with windbg, so here are a few tips to get you started:

  • When you attached to LogonUI at step 6, the process is stopped. You can enter commands to set breakpoints before resuming it.
  • Verify that your Credential Provider is loaded with the lm command. Look for a string like this one:

    000007fe`f5e80000 000007fe`f5e9b000   SampleCredentialProvider   (private pdb symbols)
  • Just to be sure, verify that a specific symbol is loaded with this command (you should get an address):

    x SampleCredentialProvider!CSampleProvider::SetUsageScenario
  • Set a breakpoint to the same location with this command:

    bu SampleCredentialProvider!CSampleProvider::SetUsageScenario
  • Resume LogonUI with the g command.

You can now lock your workstation and try to unlock it. When LogonUI appears to freeze, ATL-TAB to the debugger. It should be waiting for you with the source file loaded, waiting for your instructions. Type g to resume. Complete the unlock procedure to end LogonUI.

To reattach to logon UI, you can quit windbg and launch it again, but it is easier to list the process with the .tlist command (LogonUI.exe will be the last in the list). Attach to it again with .attach 0n2331 (replace with your PID).

Happy debugging !


Image credits :


  1. Fred Lock wrote:


    Thanks for your tip. I tried running Visual Studio 2010 on the secure desktop using your instructions and it works. I can debug my cred prov using Visual Studio running on the secure desktop.

    Thanks again.

    Guillaume Reply:

    Glad it helped! Although I use WinDbg quite often, I still prefer Visual Studio’s integrated debugger.

    Dat Le Reply:

    Hi FRED LOCK and Guillaume,

    I have successfully opened vs 2005 on the secure desktop. However, I don’t know how to debug the credential provider while it’s running. Could you please tell me how to configure the same?

    Many thanks in advance.

    Guillaume Reply:

    First, use a test program to run it on the normal desktop. You will get the first bugs out of the way. Then, if needed, you can run the same program on the secure desktop. At last, attach the debugger to LogonUI and set a break point in your code.

    Tuesday, April 26, 2011 at 12:51 | Permalink
  2. Alex wrote:

    Wow! This method is fantastic, such a time-saver! I can’t believe it… So much time spent on rebooting, reading logs, etc.

    I was also able to run Visual Studio 2008 from this environment, but it threw an error when clicking File\Open. What I did was to go to the solution file and start the .SLN instead. Visual Studio started and opened the file automagically.

    I ran into a different issue – I am testing my credential provider with domain authentication, this enforces a Ctrl+Alt+Del sequence. As a result, I cannot see my console window – even though the process is still running.

    The problem is solved by running “control userpasswords2” and disabling the feature to enforce Ctrl+Alt+Del, after that – it works.

    This is a wonderful method, thank you very much! Woooohooo!

    Guillaume Reply:

    Thanks for sharing the control userpassword2 tip !

    (edited)The secure attention sequence (SAS, better knonw as CTRL-ALT-DEL) was (and probably still is) nothing more than a Windows Hotkey, a mere shortcut that starts LogonUI which in turn will load your CP. The SAS is there to provide a trusted path to the user. There is no harm disabling it for your tests.

    Thursday, October 27, 2011 at 7:41 | Permalink