been suffering this the same as this guys post https://forums.intel.com/s/question/0D50P00004JiPrHSAV/dch-graphic-drivers-flickervideo-drop-outs-on...
no matter the DCH version of the driver used we got constant screen flicker and video drops out the same as when these NUC's where first released and a special _BN driver was released
well we finally fixed it, we sold 89 of the 90 NUC's to be used and bought something else :) 1 was kept just in case a working driver gets released and he can do legacy testing for other customers
your support on this hardware appears abandoned now :(
Those so-called "special" NUC driver releases were binary identical to the standard driver releases; only a special change in a registry parameter caused the installer to be different and thus made the package unique. Not seeing another "_BN" driver release does not imply that the platform has been abandoned (what a silly statement; it most certainly hasn't). Graphics issues can take a longer time to be addressed; the graphics team is *very* busy. People don't seem to realize that nothing happens over night and that, with time for discovery, analysis, fix implementation and validation across the many possible platforms, it can take literally months for a particular fix to make it into a production driver release. We could wish that it happened faster but it simply cannot be.
I would add that, in more than 90% of all cases where flickering and video drops have been reported to Intel, the problem was fixed with a cable replacement. If you are testing with a cable that came with a Monitor/TV, stop, throw this cable in the garbage and buy yourself a good quality replacement. Those cables that come with monitors are nothing but crap; the cheapest that they can get away with.
Along with Scott's answer, if the previous GFx driver worked for you, why not go back to that version? You don't have to have the latest driver to do your work do you?
A lot of the time, when someone reports an issue with a driver, it may fail for them but not for others. This makes it tough to pinpoint where the failure is and can take a lot longer to fix.
I'm going to bump your reply from well over a year ago.
ALL DCH drivers to date present the same issue. This clearly has not been "worked in" or "took time" to implement as you suggested. They abandoned whatever fix was required for the gfx adapter in the 7i7BNH to fix the dropout/flicker and moved on.
last working driver was 6373 or 6286.
Why do I have to run a 3 year old device specific driver for the "fix" when even the officially "universally" published driver to microsoft from intel does not work properly? The EDRAM reg fix no longer works for these drivers.
Intel support, please invite a developer to take a look at this issue. It has been several years now.
Also, you mention he might have a cable problem. I'm sorry, but if he is testing 90 NUC machines with the exact same issue that is fixed by an old video driver, it is not going to be a video cable issue. That's just common sense.
In theory, the approach you want to take is to install the latest available driver specific to the BN NUCs (i.e. 220.127.116.1186) and then overinstall this driver with the latest available general (and DCH) driver (18.104.22.16836). This should ensure that the customizations that exist in the specific driver are not lost when the latest general driver.
If I was the engineer leading the transition of the driver from non-DCH to DCH, I would do so by branching the database and implementing the DCH specifics on this branch. Once completed, any fixes that had to be implemented in the main branch in the meantime would need to be merged into our branch before it can replace the main branch. If the latter step in this process was not performed, then these fixes would be lost.
You seem to be saying that you believe that fixes *were* lost during this process. This would definitely need to be verified by the engineering team. I hope Intel Customer Support will take care of this.