Secure Boot is not enabled in the BIOS. And Fast Boot is disabled in Windows 10.
Most of the fleet is running on BIOS version GYBSWCEL.86A.0043.2015.0904.1904
The hard part about this is that I haven't figured out how to reproduce the problem even though every Patch Tuesday that requires a double reboot of the systems results in approximately a seemingly random half of them failing to completely shutdown after the 2nd reboot thus requiring manual intervention to complete the update cycle.
It is important to mention that your system has to be updated before Windows® anniversary update, I noticed that the BIOS version you are using is 0043 – 9/4/15. Please try to update the BIOS in this order:
BIOS Update Instructions for Intel® NUC:
After that please install the latest Chipset driver version: https://downloadcenter.intel.com/download/26128/
Hope this helps,
Please let me know the outcome.
Thank you for the suggestion. I would point out that we currently have approximately 600 NUC's deployed and are may eventually have approximately 1,800 deployed. The NUCs that we recently ordered and received are arriving with BIOS 43. Quite honestly, I don't see us performing five sequential BIOS upgrades on all of these NUCs. I'd probably just shut down Windows Updates to avoid the reboot issue because I don't have the manpower to touch each and every NUC by hand.
We have been collecting data on whether or not the systems reboot successfully since about July 11tth. There have been two Windows Update Patch Tuesday events since we have started data collection - July and August. That gives us four sets of results (for systems that reported in both July and August) based on the reboot after Patch Tuesday:
12 systems successfully rebooted in both July and August
17 systems were successful in July but failed in August
7 systems failed in July but were successful in August
23 systems failed both in July and August.
There is no consistency in results since we have systems that worked once then failed and systems that failed once then worked the next time. These are all configured identically because we an image-based setup process. As far as the hardware goes, all the systems were acquired in April and May of 2016. I'm finding that the configuration are the same for any that I have looked at.
Below is a section of a spreadsheet that we put together for tracking. I added the BIOS, Chipset and version info on two systems by hand since we don't currently have an automated way of collecting this. But, what is interesting is that CTCHAI was successful in both July and August while DEWIGS1 failed in both July and August yet both seem to have the same BIOS, Chipset and driver configuration.
Name Serial Jul WU Aug WU BIOS Chipset ReadyMode Bluetooth Graphics ProSet Wireless Security Assist ITE Infrared Trusted Execution Realtek Ethernet Realtek Audio CAORAI G6GY5470005E Success Failed CTCHAI G6GY547002QL Success Success GYBSWCEL.86A.0043.2015.0904.1904 10.1.1.9 22.214.171.1244 17.1.1525.1443 126.96.36.19931 18.11.0 188.8.131.523 1.01.0000 184.108.40.2067 10.2.703.2015 220.127.116.1171 CTRHAS2 G6GY547002ZX Failed Success DEWIGS1 G6GY547002NK Failed Failed GYBSWCEL.86A.0043.2015.0904.1904 10.1.1.9 18.104.22.1684 17.1.1525.1443 22.214.171.12431 18.11.0 126.96.36.1993 1.01.0000 188.8.131.527 10.2.703.2015 184.108.40.20671
My plan is to put the latest BIOS and drivers on the systems that I have direct access to before the next Patch Tuesday update and see what happens.
Thanks for this information, I’ll be waiting for any update on this matter, let me know if there is something else I could do for you.
Are you using wireless keyboard? I've founded in one of my computers that Logitech unified receiver is causing Windows stuck (with swinging dot circle) in endless loop after boot. It happened during update to version 1607. I've switched the PC to OFF, removed this receiver and switched the PC ON again. The was update finished successfully. After the PC was updated, the Logitech receiver is not disturbing the boot process.
We have not been able to resolve the issue. Updating the BIOS and chipset drivers didn't resolve the problem. Nearly every NUC that we have deployed has had the issue of getting stuck on shutdown but it doesn't happen every shutdown. Whatever the root cause might be, it's seems to be related to some unknown variable - I'm wondering now if perhaps power management may play a role in the situation.
I had a theory that perhaps the length of time that the system had been running might play a role and I started to collect data on that topic. An analysis of data collected so far seems to not support that theory though.
The other complicating factor is that we're moving through the update to Windows 10 Anniversary Edition (Build 1607) This is a significant update and involves several reboots any of which may cause the computer to refuse to shutdown.
Let’s do this test with one of the Intel® NUCs, Please try a clean installation of Windows®10, there could be a loss of information on windows. Testing this and updating the Intel® NUCs drivers please let me know it goes.
Here is the order of the drivers update:
Intel® Chipset Device Software for Intel® NUC:
Intel® HD Graphics Driver for Windows® 10 for Intel® NUC Kits NUC5[x]PY/NUC5PGY: