Integrated graphics controller in D3 low power still crashes the system

[AGreg3]

This looks like an unfortunate redux of long-standing problem with Intel integrated graphics controller.

I've been using a couple of Intel MB and CPU with integrated graphics, running Windows 7 x64, for quite long time (since 2011 or so), and from the beginning, they've been plagued with mysterious crashes. Most often, the box went to some kind of global memory corruption: the screen gets covered with running garbage, then the CPU hits NMI and then SMBIOS shuts the box down to S5, and then turns it back on after a second.

Sometimes, though, it crashed with old good BSOD. In the memory dump you could find that it crashed because of strange memory corruption. I tried to disable C-states in CPU (as someone suggested), but that didn't help much.

Then this thread appeared on OSRONLINE forum:

https://www.osronline.com/showthread.cfm?link=271926 OSR's ntdev List: Memory Corruption Mystery: Any Ideas?

One of the posters found out that the crashes are linked with allowing the display with Intel integrated graphics go to sleep. As long as the display sleep was disabled, the system was OK. I checked an old memory dump and found that the corruption in it matches the description. After that discovery, I simply disabled the integrated graphics and put an add-on graphics card to the system. Crashes stopped.

Then I decided to decommission the big noisy box and replace it with NUC7i3BN, running Windows 10 x64. And now I'm seeing similar crashes again. I come to the box to find the display in low power. Hit a key to wake it up, and instead of that, it simply reboots, without leaving a memory dump. One time, similar reboot happened after S3 sleep. I had to disable display sleep.

So it looks like the problem is still present.

[idata]

alegregoriev, Thank you very much for joining the Intel® NUC communities.

In regard to your comments above, there are no reports or documents stating there is a known issue with the NUC. In this case in order to try to f ix this problem we can try a BIOS update to the latest version:F7 method:http://www.intel.com/content/www/us/en/support/boards-and-kits/000005850.html http://www.intel.com/content/www/us/en/support/boards-and-kits/000005850.html.BIO file needed 0045:https://downloadcenter.intel.com/download/26732/BIOS-Update-BNKBL357-86A-?product=95069 https://downloadcenter.intel.com/download/26732/BIOS-Update-BNKBL357-86A-?product=95069 We can also re-install the drivers below:Chipset:https://downloadcenter.intel.com/download/26330/Intel-Chipset-Device-Software-for-Intel-NUC?product=95069 https://downloadcenter.intel.com/download/26330/Intel-Chipset-Device-Software-for-Intel-NUC?product=95069Management Engine:https://downloadcenter.intel.com/product/95069/Intel-NUC-Kit-NUC7i3BNK https://downloadcenter.intel.com/product/95069/Intel-NUC-Kit-NUC7i3BNKGraphics:https://downloadcenter.intel.com/download/26480/Intel-HD-Graphics-Driver-for-Windows-10-for-Intel-NUC-Kits-NUC7i-x-BN?product=95069 https://downloadcenter.intel.com/download/26480/Intel-HD-Graphics-Driver-for-Windows-10-for-Intel-NUC-Kits-NUC7i-x-BN?product=95069 Another option will be to use start up repair option on the NUC, please enter "recovery options" on the search bar, the choose "restart now" under the "Advanced Startup" tab, then select "Troubleshoot" then "Advanced Options" and then "Startup Repair"

Could you please explain what do you mean with D3 low power, is that a setting of the monitor?

If you set the BIOS to default values, is the problem the same?

Which video port are you using?Do you have the option to use a different video port on the NUC? What is the memory RAM model that you are using?Please let me know the results of trying the steps above. Any further questions, please let me know. RegardsAlberto

[AGreg3]

The BIOS and graphics driver all have been updated to the latest version. I'm using it with 4K monitor on HDMI 2.0.

About S3, S4, S5, D3:

S-states are system power states (in Windows world, at least). D-states are device power states.

D0 is fully functional device state, on full power.

D3 is powered off state. D3cold is when all power is off, and D3hot is when device is put to low power, either on main (VMAIN) or on auxiliary power supply (VAUX). D3hot allows for system wakeup.

D1 and D2 are intermediate reduced power states. Rarely supported.

S0 is fully powered state.

S5 is fully powered off (except for standby power or VAUX). In S5, state of the OS is not preserved.

S4 is hibernation. The system is powered off (possibly with VAUX to some devices), RAM is also powered off, but OS state is preserved on a disk. A variant of it is Windows 10 fast start shutdown.

S3 is sleep state. The system is partially powered on. RAM is still powered on and its state is not lost. CPU may be powered off completely. VMAIN can be off, but VAUX needs to be on to keep RAM contents. A variant of S3 is hybrid sleep, when RAM state is also preserved in hiberfile.sys, to protect against unexpected power loss.

S1 and S2 are placeholders for intermediate reduced power states, but they're not used.

The problem we're talking about is when the graphics controller is in D3hot. Windows will put it in this state when the display is turned off because of user inactivity timeout. Also, the graphics controller will be in D3hot state when the system is in S3. The problem is pretty easy to reproduce in a few tries, and I think you should file a bug with the driver developers. System config report is coming.

[idata]

alegregoriev, Thank you very much for letting us know that information, we really appreciate you took the time to clarify that.

In this case we will try to replicate this scenario in our lab, based on that, could you please provide the specific steps that you do in order for us to apply them and make sure we are following the same procedure that you performed? Any questions, please let me know. Regards,Alberto

[idata]

alegregoriev, I just wanted to check if you saw the information we requested previously and if you need further assistance on this matter?

Any questions, please let me know. Regards,Alberto

[AGreg3]

@Alberto

Sorry, I didn't have time to find the reliable repro scenario. I'll try that some time this week.

[idata]

alegregoriev: Thank you for the update, no problem at all, take your time and once you get the chance please let us know those steps.

Any questions, please let me know. Regards,Alberto R

[idata]

alegregoriev: I just wanted to check if you still need further assistance on this matter? Once you get the chance please provide the steps so we can try to replicate the issue.

Any questions, please let me know. Regards,Alberto R