We need to narrow down the issues, could you please tell me which maintenance jobs you are doing. Also, please run our Intel® System Support Utility and send me the results.
Intel® System Support Utility
I will be waiting your reply.
Just wanted to add that I belleve that we're seeing this same issue. We have about 1,000 NUC5PGYH units in the field (Windows 10 64 bit) and they all seem to have this issue. Specifically when Windows Update has to reboot a 2nd time after installing updates. When Windows Update installs updates and then reboots, it works ok. When Windows Update download updates, reboots, installs updates (e.g. "Don't turn off your computer" then 10%,20% etc messages) and then reboots again is when the issue occurs. The system is in an unresponsive state with no display on the monitor but the power light is on and the fan will run. Keyboard does nothing. Wake On LAN does not wake. The "fix" is to power cycle and then the computer boots just fine.
I assume that when the computer reboots and Windows Update loads the system is running a stripped down kernel. There's something about the Windows Update shutdown process in this state that isn't working quite right.
We're quite anxious to figure out how to address this issue so we're willing to do anything we can to help track it down.
Let me know if you already installed the latest BIOS and NUC drivers from Intel website.
If problem continues, please send to me the results of Intel® System Support Utility
How to attach a file:
-Click on reply
-Click Use advanced editor (upper right side)
-Click Attach (lower right hand)
Thanks for the response. Most of the fleet is running BIOS version 2015.0904.0904 - so not the most recent. Running the Intel Driver Utility suggests that the chipset, trusted execution, wireless and Bluetooth drivers are not current.
The process of attempting to track down the issue may take a while because I haven't figured out how to trigger it reliably. It may take trying something and then waiting a month for the Patch Tuesday updates that typically cause the problem.
I'll post updates as I have them.
Sure, I will be waiting your results.
I suggest you to download and install our latest BIOS and drivers manually from downloadcenter.intel.com instead of using IDUU.
The latest BIOS version is 0054.
Downloads for Intel® NUC Kit NUC5PGYH
Thanks for the tip on where to find drivers. Since the issue seems to occur most reliably after a Patch Tuesday and then next Patch Tuesday is September 13, I may not have much to report until after that event.
From a statistical perspective, we have some data to work with. We have been collecting reporting 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 fairly 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 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 CTRHAS2 G6GY547002ZX Failed Success DEWIGS1 G6GY547002NK Failed Failed GYBSWCEL.86A.0043.2015.0904.1904 10.1.1.9 220.127.116.114 17.1.1525.1443 18.104.22.16831 18.11.0 22.214.171.1243 1.01.0000 126.96.36.1997 10.2.703.2015 188.8.131.5271
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. If you have any other suggestions on what I might do to help troubleshoot I'd be most interested.
I suggest you to update NUC drivers after the BIOS.
Just wanted to pass on some statistics that I developed on the issue where NUCs fail to shut down completely after patch Tuesday updates. I'm trying to see if there is any common factor across the computers that get stuck and those that don't. The first step is to figure out which are getting stuck and which aren't.
The table below shows the number of NUCs that were powered on relative to Patch Tuesday (yellow bkgrd) for the month. We don't power them off so if they're not reporting they're stuck. Also, the number that got through Patch Tuesday without getting stuck and the percent that got stuck.
Num Not Stuck
99 = 36%
188 = 52%
186 = 51%
193 = 50%
We seem to be right around 50% that get stuck – but it’s not the same 50% each Patch Tuesday. Interestingly, some have not gotten stuck yet. 36 out of 450 systems have been on continuously and updating since 6/6/2016. There may be a few more but I cannot distinguish between computers that were
turned off by hand and those that got stuck.
So far, in my investigations, I have not found anything that distinguishes those that never got stuck from those that did. All those that made it through June, July and August to date are using BIOS 43 (9/4/15) and Chipset 10.1.1.9 as well as drivers as documented above.
Thank you for checking in. Updating the BIOS and chipset did not seem to alleviate the issue. I was hoping that perhaps Windows 10 Anniversary edition would help but it still seems to get stuck shutting down.
I'm starting to think that there may be a correlation between the amount of time that the system has been running and reboot success. If I set up a task that reboots the systems every 10 minutes or every hour it works just fine. So I'm trying to collect some data on rebooting daily, every other day, every fourth day etc.
I'm also wondering if there is a power management link. e.g. the system is waiting for a response from a device that has already been powered down. I have no idea how to collect any data on this though.
To reiterate, the challenge here is that there is no consistency. A given system will work fine for a while and then get stuck shutting down once and then work fine again for a while. I haven't figured out anyway to make the systems to stick on shutdown.
I have not received a update from you in regards to random reboots. I am closing your case; if you need further assistance do not hesitate to reply back using this thread.