*** Windows 10 + NVIDIA WHQL Drivers are Killing Alienware and Clevo LCD Panels ***

Exactly.

And sure, they can fix it just as we can. Only thing is; wouldn't bet a dime on the chance they'll offer that service.

 

I'm sure they won't either, unless it is proven and made public knowledge that their drivers are solely to blame. While their drivers appear to contribute to EDID corruption, in the absence of any reported incident with AMD GPUs, I am still convinced something Micro$haft has done is the underlying root cause of the problem. It's like adding water to acid instead of adding acid to water. The former can have devastating consequences. Otherwise, my fourth LCD that has never been on a Windows 10 machine would not be dead. Neither would @Arestavo and @Rengsey R. H. Jr. have experienced the same. Using my pre-Windows 10 (uninfected) image of Windows 7 everything was fine, but somehow a clean Windows 7 installation without newer NVIDIA drivers and ZERO Windows Updates installed still managed to somehow corrupt the EDID on my fourth LCD panel.

The only event in the life of these machines that is a clearly identifiable exception since they rolled off the assembly line at the factory is the introduction of Windows 10. Something extremely nasty was introduced to us courtesy of the Redmond Nazis. Since flashing everything didn't permanently fix it, I'm almost to the point of thinking that a motherboard replacement will be required to cure the cancer if snipping the pin #5 LVDS wire connection doesn't work out well.

 

this makes me worry install windows 10 on any of my machine.. especially they are all rare old collectibles dont wanna trash em..

never in my wildest imagination a software combination + 1 typical hardware would cause this, in general terms. if someone had told me this years ago i would laugh at them thinking they were stupid.

here is one thats very different but rather than software i'd think its firmware related. swapping graphics card would damage LCD. http://ridingtheflow.blogspot.ca/2011/04/is-thinkpad-w701-mxm-kind-of.html

 

Is it possible that the windows activation mechanism is the culprit? I'm fairly sure it pokes around in various places to find ways to identify your hardware and create a 'unique' hardware id.

 

Maybe so. It is hard to say since we understand nothing definite about the cause from a technical aspect. We only know about the tragic final outcome that manifests itself by EDID corruption when the machines become unusable.

 

Guys, Windows 10 took out an Asus W90vp dual 4870 GPU's - or screen?:
http://forum.notebookreview.com/thr...-owners-lounge.354885/page-1161#post-10087178

Anybody have any ideas to help him?

 

I still remember disrespectfull face of guy who told me in the past that virus can't destroy hardware because it's SOFTware. On the other hand... there were no Windows 10 by that time.
@Mr. Fox , just saw about your 4-th display. Really sorry for you. Why Nvidia doesn't want to take whole notebook then for testing?

 

well depends, hardware requires software/firmware to run and make it work, a virus destroying firmware would make hardware stop working, but are rare.

 

Then, barring AMD reports, the nvidia driver wrote something to bios or vbios. There was no full flash with this case, right? But, perhaps, a cmos reset was made?

That would fit observations neatly:

Spoiler: off-topic digression

Those are oproms (option roms). It's normal for some (older?) Quadro cards; some lack a vbios (and eeprom) entirely. Bios editor would have worked here; replace one of the four Quadro vbioses with that the HD6970M.

This is quite interesting:

1. nvidia driver installs
2. nvidia driver changes nvidia vbios
3. nvidia vbios writes to edid
4. edid broken
5. new screen + new edid + new os + new driver
6. same vbios (and bios?)
7. edid broken

Would be nice to have those bioses and vbioses. That would confirm bios or vbios corruption (in non-nvram sections). That compare is easily made. Only, how best to approach this?

As an example:
This is my bios as present on the eeprom (afudos.exe /O) compared to the version from before the flash (as download from vendor):

Spoiler: bios pre-flash vs. post-flash and post-boot

So there's 135,890 bytes different. It's non-UEFI (duh), but even then you have nvram for boot options/devices/hdds. A cmos reset should clear these. The bios extracted after cmos-reset ought to be bit-identical to the pre-flash bios. Only; how to extract it? After DOS boot (to get to afudos.exe) those sections have been re-written again. Could desolder and use programmer, but that would be a bit to much to ask of most ... Fortunately, the flash program has an option to write nvram only:

Code:

+---------------------------------------------------------------------------+
|                 AMI Firmware Update Utility  v3.07.00                     |
|      Copyright (C)2014 American Megatrends Inc. All Rights Reserved.      |
+---------------------------------------------------------------------------+
| Commands:                                                                 |
|         /N - Program NVRAM                                                |

That's ... nuts ... but really useful if that works. Consider that nvram is all FF on the pre-flashed bios, so writing this effectively accomplishes the same thing as a cmos reset. Command would be:

Code:

AFUDOS.EXE BIOS_O.ROM /N

And, in the same session, right after the nvram wipe has finished:

Code:

AFUDOS.EXE BIOS_E.ROM /O

Bios O(riginal) and bios E(export) should be identical. If they are not, then some process wrote to non-nvram sections. So this is the result on my Legacy boot system:

Spoiler: bios pre-flash vs. post-flash and nvram cleared

Wait ... what the ... 1,818 bytes different? It's better than 135,890, but still ... let's take a look:

Spoiler: bios pre-flash vs. post-flash and nvram cleared, differences

Okaaaayyy ...

WTF???!

This is Windows 7; haven't once installed 8.0, 8.1 or 10 (or Apple OS, for that matter). And yet, there it is; a Secure Boot rootkit. Really ... WHY? It's not as if I need convincing 'Secure Boot = Evil', thank-you-very-much. Now, do recall rolling-back one or two of the prepare-for-10 updates that slipped by without checking their purpose first (shame on me ). Only, which one? And, far-far-far-faaaaaaaaaaar more serious, how did it prevent itself from being wiped out by the 'clear nvram' procedure (we wouldn't even have noticed otherwise ...)? Does that mean that even pulling cmos battery is useless against this?

Mind that the non-nvram is untouched; it's only that some section that used to be non-volatile are now read-only and no longer part of nvram. There is, however, a single exception to that; a tiny few bits that have changed compared to the pre-flash bios. Perhaps the nvram index? A read/write bit? Or the bit that tells you the total size of the bios, hiding part of it?

Spoiler: bios pre-flash vs. post-flash and nvram cleared, non-nvram written

Next thing is a full bios write; this means war !

It's actually even worse than that; some eeprom implementations accept any I2C data as 'write', including a 'search' query. Will get back to that; it's quite a read and needs some editing.

 

what? a secure boot rootkit? serious or is it just pure speculation? it could possibly mean that any pc that has had win 10 installed is at risk even if there's no visible issues.

i don't mean to fearmonger if people feel that way but it does sound like it to me....though i could be wrong and would be very happy to be.