Search code examples
windowswinapicredential-providersgina

Can I insert a program between login and explorer shell in Windows?


I was going to ask this in superuser but it is related to C/C++ and Win32 programming so I'll ask it here. I'm looking to add a step between user login and the Windows shell for Windows 7+. These are the things I've researched and tried with limited success:

  1. MSGINA Stub, which seems like it would work perfectly but was discontinued as of Windows Vista so I can't use this.
  2. I've looked at custom Windows Credential Providers but I'm not entirely sure this will do what I want (launch an application after login and before the windows shell).
  3. A (semi) custom shell which would do what I need then launch the normal Windows shell (explorer.exe).

Option 3 has gotten me the closest but my problem is that I can't start explorer.exe as a shell if I've created the HKLM\...\Winlogon:Shell registry value pointing to my program. I could create the Shell value in HKCU then change it to explorer.exe before quitting and launching explorer then restoring the value to my program. This would work but is not as secure as using HKLM. In this case, I can't even use HKLM as my program is being executed in the current user's context and the user does not have write permissions to that key.

Are there any creative ways that I can do this or any other possibilities that I'm missing? Option 2 above didn't seem to be viable but please correct me if I'm wrong.


Solution

  • I like RbMm's answer, but for completeness, another option is a Credential Manager.

    (Note: a Credential Manager is not the same thing as a Credential Provider.)

    Using a Credential Manager might be preferable to using userinit in any of the following scenarios:

    • You want to run code with elevated privileges.

    • Your code needs to run at a very early stage in logon, e.g., before roaming profiles are loaded.

    • You need the user's password.

    Some reasons you might not want to use a Credential Manager:

    • It runs as a DLL inside winlogon so you need to be particularly careful that your code is correct.

    • Depending on what you're doing, it might be too early in the logon sequence. :-)

    • It doesn't run in the user's context. (There is a way around this, but it's pretty hacky.)