Share via

Caught in Reboot Loop if Joined to Domain After March Patches

Question

Monday, March 14, 2016 6:08 PM

After the last patch cycle on 03/08/2016, all of the Windows 10 Enterprise x64 (Version 1507-1511, 10.0.10240.16725 and 10.0.10586.164) machines (Dell laptops, different models) began exhibiting the following symptoms after an initial reboot:

  • Reboots after 1-2 minutes.
  • Domain Users cannot login.
  • Local admin account is able to login only once after initial reboot (no matter how many times machine has been rebooted). When allowed in, the Control Panel, Task Manager, and even System Settings fail to initialed and return an error (complains of invalid .lnk). An error pops up almost immediately stating that there was a system error and that the machine is going to reboot after a minute (typical reboot warning). The reboots are "hard", the machine appears to simply power off instead of shutting down processes and such.
  • Upon entering credentials into any account, pressing the "continue" arrow or pressing Enter on the keyboard have no affect. If you tap the power button, it acts like it is going to login, but eventually fails.
  • On some machines, received the following message when attempting to login as a domain user after first initial reboot after patches applied: "Local Session Manager Error - Service failed the sign-in. RPC server unavailable."
  • Able to login via Safe Mode as Administrator to extract event logs (see below for basic analysis).
  • On the initial login screen, when selecting the power button (to shutdown or sleep), only an empty gray menu appeared.
  • Usually the normal domain user profile automatically comes up for login, but, following the initial reboot, the local Administrator profile is the default, with either "Other user" and/or "Password" profiles available as alternatives.
  • The aforementioned "Password" profile has no username field, and no know passwords appear to work.

All of these issues started happening after the last round of patches from Microsoft. They only affect machines that are on our corporate domain. As long as a machine is not on our corporate domain, no errors occur. As soon as a machine that has received all of the most recent patches joins the domain, it immediately begins exhibiting the previously mentioned symptoms. 

The only thing in common with all these machines that we can see is that they are all running Windows 10 Enterprise x64. We are in a corporate environment with AD, WSUS, Exchange, DNS, etc. Some of the affected machines were even running an older build of Windows 10 (10240 vs. 10586), and they exhibited the exact same symptoms.

Here are a couple excerpts from the first two events following the reboot after joining the domain (top one came first, followed immediately by the next event):

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
  <Provider Name="Application Error" /> 
  <EventID Qualifiers="0">1000</EventID> 
  <Level>2</Level> 
  <Task>100</Task> 
  <Keywords>0x80000000000000</Keywords> 
  <TimeCreated SystemTime="2016-03-14T15:56:40.935990600Z" /> 
  <EventRecordID>1606</EventRecordID> 
  <Channel>Application</Channel> 
  <Computer>MyMachine.ad.mydomain.com</Computer> 
  <Security /> 
 </System>
 <EventData>
  <Data>lsass.exe</Data> 
  <Data>10.0.10586.0</Data> 
  <Data>5632d7c6</Data> 
  <Data>schannel.DLL</Data> 
  <Data>10.0.10586.63</Data> 
  <Data>568b20a5</Data> 
  <Data>c0000005</Data> 
  <Data>0000000000005a49</Data> 
  <Data>29c</Data> 
  <Data>01d17e0a009aecdf</Data> 
  <Data>C:\windows\system32\lsass.exe</Data> 
  <Data>C:\windows\system32\schannel.DLL</Data> 
  <Data>1e1928ff-2481-4b0a-bd5f-b435cda48f5f</Data> 
  <Data /> 
  <Data /> 
 </EventData>
</Event>

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
  <Provider Name="Microsoft-Windows-Wininit" Guid="{206f6dea-d3c5-4d10-bc72-989f03c8b84b}" EventSourceName="Wininit" /> 
  <EventID Qualifiers="49152">1015</EventID> 
  <Version>0</Version> 
  <Level>2</Level> 
  <Task>0</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x80000000000000</Keywords> 
  <TimeCreated SystemTime="2016-03-14T15:56:43.706329400Z" /> 
  <EventRecordID>1609</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="0" ThreadID="0" /> 
  <Channel>Application</Channel> 
  <Computer>MyMachine.ad.mydomain.com</Computer> 
  <Security /> 
 </System>
 <EventData>
  <Data>C:\windows\system32\lsass.exe</Data> 
  <Data>c0000005</Data> 
 </EventData>
</Event>

After the previous two events, the secon even appears to occur after every reboot, followed by 90-100 copies of the the following error, each only microseconds after each other:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
  <Provider Name="MsiInstaller" /> 
  <EventID Qualifiers="0">1015</EventID> 
  <Level>3</Level> 
  <Task>0</Task> 
  <Keywords>0x80000000000000</Keywords> 
  <TimeCreated SystemTime="2016-03-14T15:56:53.528698600Z" /> 
  <EventRecordID>1623</EventRecordID> 
  <Channel>Application</Channel> 
  <Computer>MyMachine.ad.mydomain.com</Computer> 
  <Security UserID="S-1-5-18" /> 
 </System>
 <EventData>
  <Data>0x8007042D</Data> 
  <Data>(NULL)</Data> 
  <Data>(NULL)</Data> 
  <Data>(NULL)</Data> 
  <Data>(NULL)</Data> 
  <Data>(NULL)</Data> 
  <Data /> 
 </EventData>
</Event>

The only "fix" we have is to avoid the most recent batch of patches, which is unacceptable since they include critical security patches. We have not deployed Windows 10 to the rest of the company yet, but are looking to do so in the near future. At this point in time, only a couple people in the IT department are testing Windows 10. We have been running it with a minimal number of minor issues since Windows 10 Enterprise was made available.

Does anyone else have this issue? Does anyone have any ideas or suggestions?

All replies (4)

Wednesday, March 16, 2016 7:25 PM âś…Answered | 1 vote

The issue has been resolved. We discovered a GPO that had an invalid setting. The specific GP setting was Computer Configuration>Policies>Administrative Templates>Network>SSL Configuration Setting>SSL Cipher Suite Order.

The order of the SSL Cipher Suites was correct, but what happened was that one of our employees was removing one of the suites and did not delete all of the suite string, leaving a large, malformed cipher suite as the first entry. Here is the first malformed string (error in italics):

TLS_RSA_WITH_AES_128TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384

After correcting the entry, our Windows 10 machines exhibit no more odd behavior. It seems odd that something so small could be so catastrophic to Windows 10.

Monday, March 14, 2016 7:39 PM

Since this ticket we have determined that the issue lies somewhere in a GPO. We determined this by performing the following tests:

  1. Image new Windows 10 machine separate from the corporate network.
  2. Completely updated machine.
  3. Pre-staged the device in an OU with no policies applied.
  4. Joined the machine to the domain.
  5. Logged in as a domain user.

At this point, everything worked as it should with Windows 10. Now, we are systematically applying GPOs to the machine to see which one breaks Windows 10.

Monday, March 14, 2016 8:30 PM

Thanks for the update and troubling shooting. Please keep this updated as may well help others on what findings you come up with.

Tuesday, March 15, 2016 3:02 AM

Hi Reuben,

I am glad to hear that you have fixed your problem, the methods you mentioned can be helpful to other users who have the similar issue, thanks for your sharing.

If you find out which GPO caused problem, I think many people can benefit from this (including us), looking forward to your good news.

Best regards

Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact [email protected].