Hey Dude, Where’s My Winlogon.log?



AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!

We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!

Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.

If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.

NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!

As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!


Hi this is Michael from the PMC PFE Team, I recently helped a customer during the implementation of their Windows Server 2016 systems.

When checking the Event viewer, we spotted a well-known Event ID:

Log Name:      Application

Source:        SceCli

Date:          08.03.2017 17:49:21

Event ID:      1202

Task Category: None

Level:         Warning

Keywords:      Classic

User:          N/A

Computer:      test2016.mydomain.com


Security policies were propagated with warning. 0x534 : No mapping between account names and security IDs was done.

Advanced help for this problem is available on http://support.microsoft.com. Query for “troubleshooting 1202 events”.

Error 0x534 occurs when a user account in one or more Group Policy objects (GPOs) could not be resolved to a SID.  This error is possibly caused by a mistyped or deleted user account referenced in either the User Rights or Restricted Groups branch of a GPO.  To resolve this event, contact an administrator in the domain to perform the following actions:

  1. Identify accounts that could not be resolved to a SID:
    1. From the command prompt, type: FIND /I “Cannot find”  %SYSTEMROOT%\Security\Logs\winlogon.log
    2. The string following “Cannot find” in the FIND output identifies the problem account names.
    3. Example: Cannot find JohnDough.
    4. In this case, the SID for username “JohnDough” could not be determined. This most likely occurs because the account was deleted, renamed, or is spelled differently (e.g. “JohnDoe”).
  1. Use RSoP to identify the specific User Rights, Restricted Groups, and Source GPOs that contain the problem accounts:
    1. Start -> Run -> RSoP.msc
    2. Review the results for Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment and Computer Configuration\Windows Settings\Security Settings\Local Policies\Restricted Groups for any errors flagged with a red X.
    3. For any User Right or Restricted Group marked with a red X, the corresponding GPO that contains the problem policy setting is listed under the column entitled “Source GPO”. Note the specific User Rights, Restricted Groups and containing Source GPOs that are generating errors.
  1. Remove unresolved accounts from Group Policy
    1. Start -> Run -> MMC.EXE
    2. From the File menu select “Add/Remove Snap-in…”
    3. From the “Add/Remove Snap-in” dialog box select “Add…”
    4. In the “Add Standalone Snap-in” dialog box select “Group Policy” and click “Add”
    5. In the “Select Group Policy Object” dialog box click the “Browse” button.
    6. On the “Browse for a Group Policy Object” dialog box choose the “All” tab
    7. For each source GPO identified in step 2, correct the specific User Rights or Restricted Groups that were flagged with a red X in step 2. These User Rights or Restricted Groups can be corrected by removing or correcting any references to the problem accounts that were identified in step 1.

So, okay Event 1202 Sid-to-Name mapping issue. Sure enough there was some security principal in either one of the settings or at the delegation tab on one of the policies which couldn’t get resolved.

So let’s have a look at the Winlogon.log as called out in the event description. We went to %SYSTEMROOT%\Security\Logs\ and then “Dude, where’s the Winlogon.log!”

We quickly checked if the path may have changed in Server 2016 but couldn’t find the log in any other directory. Then we checked how this was enabled / disabled on earlier OS versions.



Key name: ExtensionDebugLevel
Data: 0x2

Okay, so it is not enabled by default on Windows 10 and Server 2016. We enabled the debug log but still after a “gpupdate / force” and a reboot NO winlogon.log file was present. What’s wrong? Well actually nothing….

Here’s why…

We are talking about a CSE (Client side extension) which is repented by that GUID “{827D319E-6EAC-11D2-A4EA-00C04F79F83A}” ; We did a change in the registry which is only triggers when the CSE is run the next time…. But when there are NO changes to the GPO why should the CSE re-run the respective policy? Exactly,…there is no reason. This has always been the case, the code apparently didn’t change since 2008 but the log just happens to be enabled by default.

So, dude what do we have to do to get the Winlogon.log file back?

There are a few methods available and I’m listing them in the preferred order of applicability:

  1. Use the NoGPOListChanges = 0
    1. This triggers the CSE to re-evaluate and trigger the policy even though there were no changes to the policy.
    2. References:
      1. https://technet.microsoft.com/en-us/library/cc978250.aspx
      2. http://www.thewindowsclub.com/disable-background-processing-registry-policy
  1. Make a change to a policy in the security section, that’s the piece the CSE is responsible for and triggers a re-run which then creates the Winlogon.log

In any case, please make sure you undo the changes you’ve done for troubleshooting!

Winlogon.log is a debugging file which you should enable if needed to find and fix your issues but then disable it later again. Same for the NoListChanges, please make sure that you revert this change back!

Hope you enjoyed the post and it saves you some time in finding the Winlogon.log file now.