0

I have a device running Windows 10 Enterprise LTSB (v 1607)

UWF is enabled on this device, but so is the time sync service.

However, I've encountered an issue where if I set the time to, say, year 2018, shortly after the time-sync corrects the time, my application begins to hang, (or loses access to SQL server which I'm guessing is a symptom of the overall problem), and soon enough I have to power off the device.

Then, when I power it back on, the boot sequence gets as far as a blue screen saying "Please Wait" and with spinning dots and stays there for a long time. I eventually give up and power down the device and turn it back on and then the system enters auto repair mode.

When the repair is finally completed, it appears the registry has reverted to a previous state.

A clue:

One thing I have noticed is that when the time updates to the correct time 2020, it begins to download Windows Updates. This can potentially fill up the UWF overlay causing it to run out of storage. However I don't think this is the main problem because if I don't change the time and turn off the time sync, and then force a Windows Update download using usoclient (or just let it happen naturally), then while I do get a crash, it reboots normally without the system repair being invoked.

More Info

When I view the contents of the repair log (srttrail.txt) I see...

Root cause found:
--------------------------
Registry is corrupt.

Repair action: Registry roll back
Result: Completed successfully. Error code = 0x0
Time taken = 3078
komodosp
  • 245
  • 1
  • 5
  • 17
  • I would not expect a deterministic behavior and "outcome" (like a necessary repair) when Windows crashes. If something gets corrupted may or may not be caused by the way when and how Windows crashes. – Robert Sep 29 '20 at 11:22
  • Why are you seeing to set your system time to 2018 exactly? What practical purpose is there for doing that? – Ramhound Sep 29 '20 at 11:37
  • Hmmm... I was wondering if there were a number of things written to the registry as a result of the time change, but because some were saved after the reboot (being excluded from uwf) while others weren't, the result was a "corrupt" registry. – komodosp Sep 29 '20 at 11:39
  • @Ramhound - Users do need to do this for several reasons (e.g. testing, demonstration, and more), and obviously the "right" thing would be for them to turn off the automatic time adjustment if they are doing this, and they'll be advised of this. However we still need to try prevent the system from melting down should they forget, or at least find out exactly why this is happening. In any case I can't be certain it won't happen during more "honest" time corrections - setting to 2018 is just a way I've found of reliably reproducing the issue. – komodosp Sep 29 '20 at 11:51
  • System date is used for a variety of very important things, I am not shocked, setting your system time to 2018 causes a problem – Ramhound Sep 29 '20 at 11:53

0 Answers0