Winlogon vs. Minlogon

This isn’t meant to be an all inclusive description
of the pros and cons of Winlogon vs. Minlogon. But there is some
confusion of why they conflict in your configuration and why some
features have behavioral problems with Minlogon.

If you want details on Winlogon and all its responsibilities check out this good description on MSDN, otherwise here’s the condensed description of Winlogon from MSDN:

component of the Windows operating system that provides interactive
logon support. Winlogon is designed around an interactive logon model
that consists of three components: the Winlogon executable, a Graphical
Identification and Authentication dynamic-link library (DLL) referred
to as the GINA, and any number of network providers.

Winlogon.exe has *many* dependencies, hence greater
footprint. Minlogon.exe is a custom version of winlogon.exe with
certain functions removed in order to reduce it’s number of static
dependencies to other features. We took into account the functionality
required by many of our customers and weighed the pros/cons of what to
remove without hobbling the system too much.

You can bet that if there’s a service that leverages
interactive logon, it will *not* function properly under Minlogon.exe.
Take Terminal Services for instance. Of course it needs to authenticate
the remote user (by design for security purposes) therefore if you
force a runtime with TS to also have Minlogon, TS will not operate

It would be unrealistic in most cases to ask Windows
features to take Design Change Requests to support Minlogon for the
purpose of removing security features required by the other 900 Million
Windows PCs out there. So we pick and choose our battles, adding back
some functionality to address overwhelming customer requests when
possible. Take for instance the classic issue in the newsgroup
regarding a regression in some Power Management functionality in
Minlogon.exe that was recently resolved.

At MEDC, a customer asked why TD kept complaining
about Winlogon and Minlogon conflicting when he would disable or delete
Winlogon but the next time he runs “Check Dependency” Winlogon returns
and causes a conflict.

Right, that’s because there’s a feature component in the
config that has a component dependency on Winlogon, if you want to
force Minlogon just turn off “Autoresolve” in Target Designer and
satisfy all other dependencies other than that one. If you’re not
concerned about footprint and some superfluous features winding up in
the runtime, another trick is to leave winlogon in the config, remove
Minlogon, satisfy all other dependencies. But before you build,
disable Winlogon and manually add Minlogon back to the config; don’t run check dep again, just build it.

This way the configuration will build with Minlogon,
the downside is that the configuration will have additional
dependencies from the original Winlogon component left over that
increase the surface attack area of the runtime as well as bloat the

There’s lots more to discuss about Minlogon, but that’ll have to be for later.

Post comments if you have specific Minlogon questions you’d like to see addressed in a future post.


Skip to main content