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

Awesome information. Thanks again for all of your contributions here. If I am able to fix my bricked LCDs with this device I fully intend to write-protect them using the hardware mod in your example. Had they been properly write-protected from the factory, none of this drama would be happening. We would be wasting all of our calories debating the dangers of Windows 10 telemetry and the folly of forced Windows Updates instead of their hardware-damaging malware.

 

Write protection? I'm so excited! Lol
How much for that bad boy?

 

I am interested in seeing if you can fix a busted panel and get it to work with the write hack.

EDIT: even if this works i doubt that this will convince many of us to switch with win 10's many bug bears. we shouldn't have to resort to hacking panels to get it to work so alienware better fix this and release a new BIOS.

 

Even if it works and even with a new Bios the Drivers/OS needs to be fixed where it will not attempt this again in the future! Just because you can stop a viral payload does not mean you want the virus still there.

 

win 10 must have left this unprotected.

 

Oh, absolutely... 200% agree with that. By no means would the ability to fix it and stop it imply it was OK to begin with. That we would have to put up with this and take corrective steps is absolutely ludicrous and highlights the mistakes that are being driven by technical incompetence, overstepping boundaries and taking liberties where none should exist, or a combination of both.

Yup, you nailed it right there, bubba. Trust factor for Micro$haft right now is a negative value and won't even register on my scale of 1 to 10. While it is a pretty extreme fringe example, this LCD problem is just one among a plethora of issues that make Windows 10 a really horrible product. Although, I think Alienware is in no way responsible for the mistakes of Micro$haft and/or NVIDIA. These machine existed long before Windows 10 was conceived by the wicked imaginations of Redmond Mafia.

 

posted my old AUO panel to @t456 in the hope that it'll help find a solution to this mess.

EDIT: pc still good with 355.82 drivers on 8.1....kinda leaning towards it being a win 10 thing now.

 

If I have a problem I know who I am @ tagging, PMing, begging, bribing to look at the problem. Hanging out in the Clevo forum, I knew this already.

 

Do we happen to have a number of how many Clevos have had their LCD killed by Windows 10? What are the numbers of Clevos vs Alienwares like? This thread is scary, I don't want the 120 Hz panel on my Clevo P377SM-A to die.

 

as far as ive seen the two clevo incidents havent been 100% confirmed yet to be of the same nature as the alienwares, although symptoms are similar (but not identical)

Sent from my Nexus 5 using Tapatalk

 

I think this picture hits the nail squarely on the head......​

 

Got the screen flashed again. Wiped SSD, installed Windows 8.1, flashed BIOS, vbios, secure erased the SSD this time. Installed Windows 8.1 update again, updates turned off, flahed bios and vbios again on fresh installation. Also removed memory and cmos battery and done cmos reset before every bios flash. All drivers up to date, except nvidia driver is not installed yet. I am not sure which one to try so that it would not brick my screen again. Also I want to try and hardware protect the screen from eeprom writing.

 

Use Mr Foxes 345.20 drivers
http://forum.notebookreview.com/thr...d-for-alienware-and-clevo-mobile-gpus.772018/

 

I DON'T THINK SO......​

​

 

there's a dev driver out: 355.84.

 

No, it's a hardware thing.

But, as mentioned before, that alone would not cause the issue. There's so many LVDS panels out there and all of them can be written to, so why just these select few? All they have in common is that they were custom-ordered by Dell, so there might've been a screw-up with the order specifications. If so, then Dell-panel on xyz-system would see the same problem. Or, equally possible, it's because pin/wire #5 is populated on at least one of the affected Dell lcds (can't find spec. sheet for the other three), whereas they're non-connected on every other panel I've seen so far:

Spoiler: LGD02DA, LP173WF1-TLB3, pin configuration

A close look at a Dell lvds cable of an affected system will show whether or not there's a wire on pin #5.

Regardless, write-protecting the eeprom should not be necessary in the first place; writing/updating the edid is perfectly alright (no different from updating bios, ec, me and vbios). One good reason for that would be to change lcd colour coordinates (calibration), that way you wouldn't need specific .icc files and it'd be OS-independent. Also, we could use it to overclock its refresh rate ...

Kind of funny/sad, come to think of it; nvidia would very much like to block its customers from overclocking their gpus, yet they themselves overlock displays:

Preach, but don't practise ...

Yes, we'd have to see their edid-readouts first.

 

so if the LVDS cable has pin 5 it's doomed to fail?

but then it doesn't explain why it's only win 10.

 

You'll be fine with 120Hz display... I believe it's eDP display which haven't been affected... LVDS 60Hz ones are the ones in trouble.. I would stick to 8.1 and 353.06 drivers at most for now till they sort this **** out..

 

not for clevos but for alienware it has.

after trying out @t456's EDID override for my 120hz panel, i fail to see the difference is colo(u)r reproduction between the stock settings and those in the EDID override. is there an ICC profile i can download?

 

I haven't heard of eDP pannels failing in AW's... We had one fail on Windows 7/8.1 but that was most probably an anomaly...

 

there's one case and it was added to the original post. @Mr. Fox knows who it is.

 

That was @andrewsi2012 , with a SEC5044 panel. Only, it's as of yet unknown which specific panel and whether or not its edid was corrupted.

Doesn't matter then; keep the stock settings.

 

Cool, thanks for letting me know that 120 Hz eDP is fine. What about Clevo LVDS 60 Hz, are they failing too or mostly just Alienwares?

 

I would still avoid it until there's enough evidence to show it doesn't break it.

Sent from my HTC One using Tapatalk

 

It's been four days since I've reinstalled Windows 10.

I'm running an Alienware 17 Ranger with a used 980m that I picked up off of eBay along with a 330w AC adapter taken from an Alienware m18x. Currently vBIOS 84.04.22.00.0A, using modded driver build 353.49. Windows 10 has been upgraded to build 10532, running in Test Mode with Driver Signing disabled so that I can freely upgrade drivers. The 980m is in Optimus mode and will stay that way as a safety precaution.

I initially ran the stock 780m that I overclocked, and ran it in PEG mode. I was running Windows 10 RTM when I swapped to the 980m. I also flashed the Prema stock clocks vBIOS. It was when I tried to run it in PEG mode that I got the 8 beeps and black display. Dumping the CMOS got it to display again, but when I tried to switch back to PEG mode it would kick back the 8 beeps.

After the third attempt, I threw the BIOS into Legacy mode and installed Windows 7. That went off without a hitch as I left the 980m in Optimus mode. I even got games to launch without issue, but they would still driver crash on occasion. It was then that I reflashed the vBIOS to 84.04.22.00.0A. The driver crashing went away. That prompted me to upgrade to Windows 8.1. That went off without a hitch, but I ran into a new error - when I switched to UEFI mode, the boot screen would flicker out once before going to Windows. Often, it was in the middle of the spinning wheel of boot; everything would disappear and the spinning wheel would return but the Alienware logo would not. Disabling Windows 8 Fast Boot solved that issue. It's as if the 980m fails to initialize unless its given time, and if it does that mid-boot then nothing but issues occur. The extra half-second from Fast Boot being disabled does not adversely affect boot time.

Once I was able to boot into UEFI mode, I decided to take it a step further and install Windows 10 RTM. I kept the same vBIOS and driver build number. Two days ago, I made the jump to build 10532 in the Threshold2 build tree. I've played games for hours on end with no ill effects. I've restarted countless times. I had to battle my Logitech G930's software's incompatibilities by DDU'ing Nvidia drivers so that I could get the Logitech stuff to install without a fight, before reinstalling 353.49. Also, however, I will not update my drivers until I know for certain that the newer builds are safe.

All in all, I may very well be suffering from a different issue from all of you. I may have bought a "glitchy" or "broken" 980m from eBay. It's working just fine, cranking out full performance, whether or not it's buggy or broken. Just know that the combination of things that I am running has yet to fail in Windows 10. I know; I say that now, and I'll turn around and regret it tomorrow. I'm playing with fire and am well aware of it, but maybe the information I have provided can help point someone in the right direction.

 

Just make sure you stay in Optimus mode and don't switch to dedicated with these drivers and 10... Then you should be fine most lilkely...

 

or stay away from windows 10 altogether if you have a 120hz panel cos i don't know what will happen.

EDIT: I have had the 355.82 drivers with 8.1 for 3-4 days and i haven't seen any issues. it's feels like it's very specific to the win 10 drivers of the same driver number.

 

I am also running the 355.82 drivers (non-modified) with a non-updated windows 8.1 and all is fine till now, still have to play with it more though.

 

when you mean specific you mean like the actual model number (eg. LTN173HT02-P01 / LTN173HT02-D02)? We know that the LTN173HT02-C01 model has boot issues so it might be that but an analysis of the EDID would be more definitive i think.

 

Hm... I just got Ground Zeroes and am planning on getting Phantom Pain soon... I'm currently on 353.06 but will have to upgrade... Is there any way to get the updated profiles for the games without upgrading driver? I believe you have to let Ge Force Experience apply settings or so correct?

 

i think GZ runs a little bit better than TPP does or it might just be my CPU/GPU combo.

 

TomJGX, actually, it's the other way around

You need the new drivers to run correctly, and with a high end laptop, you can max everything out - so you really don't need the normal fine tuning of GFE, but after upgrading to 355.82 (made for MGStPP) you might as well see what it sets things to for your laptop.

 

Just update your drivers to the latest one, everything's working fine. If you still don't want too then let GeForce apply the correct settings for you.

I have a 4710MQ and I get straight up 60fps now. Testing MGSV TPP was the first thing I did after updating my driver so I was using only 1 GPU. No more weird fps drops or stutterings. Everything is smooth now. It's got nothing to do with CPU, besides this game is more GPU intensive even being an open world game.

 

So, rather that clipping EEPROM leg #7 and soldering it to #8 (as you noted before, quoted below) should snipping the wire for pin #5 write-protect the LCD without having to hard mod the EEPROM chip? I have several spare LVDS cables and that might be the easiest solution once I get the LCD EDID re-flashed. But, I don't want to destroy a good LVDS cable if the EEPROM can still be written to.

 

Precisely.

Due to Samsung's lackadaisical approach to quality control, merely their pnp id is not sufficient to id the panel (it should, though). Their SDC4C48, for instance, can be found in both the Venue 11 and the Alienware 18, which seems a bit of a stretch ...

Interesting. That's also the one panel to avoid if you want 3D, whereas D02, P01 and T01 are alright (there's also a 301). It was bricked, though, and don't think andrewsi2012 has the necessary tools to pull edid from a dead display. But stickers and, especially, good photo of the pcb would be helpful too.

Pure UEFI?

For drivers; I'd stick with 352.xx for now (or older).

With 353.06 there have been some changes that touch upon the issues reported prior to 8-beep (and on non-8-beep, too). Mainly to make G-Sync possible, but also to reduce motion blur (ghosting). These changes can explain higher brightness and higher refresh rate, too. However, 352.xx also rules out 10 ... another benefit, really. Think this was the coincidence; first 10 driver also happens to be the driver that introduced significant low-level display overrides.

Yes, in theory; since every panel so far has 'NC', except the affected SLB3. Don't have spec. sheets of the other three, unfortunately (impossibly hard to find). These would be extremely useful, not only to compare pin configuration, but also to check which specific ICs the compromised panels have used. Anyway, the pin #5 would be moot if there was no wire on the lcd cable as well. So better check an AW cable first and see if #5 is populated or empty.

 

reverted back to the stock settings for my panel as i couldn't tell the difference between it and the EDID override settings....or maybe my eyes are crap (which they are).

 

As best I can tell using a 8x magnification monocle pin #5 is populated. Here is the best photo I could get of the M18xR2 LVDS connector. It appears I could chop the 5th wire from the right and then be write-protected if I am following this correctly. So, program the EDID and confirm the panel works, then snip? Looks like the programmer is going to be on a slow boat from China, LOL. Ordered 3 days ago and still not shipped. Nice!

 

Yes, pure UEFI, never changed boot options since I got my AW. I figured I would give the 355.82 driver a go since windows 10 had been flawless during the first and only week I used it and given that I ran the 355.60 driver with no issues. Maybe luck for all I know. Thanks for your recommendation though. I actually want to give you my monitor details just to see if there's something different about it.

 

let us know if this works

 

Come to think of it; different colour coordinates may not have been in effect. In order to translate colour spaces MS creates 'NIL' displays with scRGB gamut (which uses out-of-bounds/fictitious colours):



These are located in the same registry location as where the display settings for the various graphics drivers are. So it stands to reason that there'll be no new 'NIL' display for the override, until you reinstall the graphics driver. However, doing so causes a bsod on my Optimus system. Nothing serious, but it proved impossible to override display values and have intel HD installed. Need to write to edid, instead.

Exactly. For science!!!

It's populated alright, but do hope we're seeing the same wire as being the 5th pin:



At least Dell did one thing right; colour-coded wires. Black wires on the left are for backlight, btw; 2x gnd, 1x dim, 1x on/off and 3x voltage.

Mind that a wire is easily cut, but also easy to re-attach, if that happens to be necessary. To confirm this works; write to eeprom with edid-rw, only using a slightly different edid. Can change its header to say ' Mr. Fox's 4th panel!!!' or something. That way there's at least a small gain, even if the write happens to succeed . Or, perhaps, a message to Dell/MS/Nvidia?

Think that's what saved you. UEFI has a different approach to I2C bus, which is where the edid eeprom is read (and written to).

 

So did we ever figure out if an m18x R1 can boot with a broken screen through HDMI as long as I was running EUFI?

 

Thanks @t456 , so does that mean I am sorta immune to Windows 10 or am I still at risk? Just wondering, are you a genius or something, I literally can't make two words of what you are saying without my head turning into mashed potatoes

My monitor details:
Monitor
Manufacturer............. SDC
Plug and Play ID......... SDC4C48
Data string.............. XJY7J€184HL [*CP437]
Serial number............ n/a
Manufacture date......... 2012, ISO week 0
Filter driver............ None
-------------------------
EDID revision............ 1.4
Input signal type........ Digital
Color bit depth.......... 6 bits per primary color
Color encoding formats... RGB 4:4:4, YCrCb 4:4:4
Screen size.............. 410 x 230 mm (18.5 in)
Power management......... Not supported
Extension blocs.......... None
-------------------------
DDC/CI................... Not supported

Color characteristics
Default color space...... Non-sRGB
Display gamma............ 2.20
Red chromaticity......... Rx 0.620 - Ry 0.340
Green chromaticity....... Gx 0.330 - Gy 0.570
Blue chromaticity........ Bx 0.150 - By 0.060
White point (default).... Wx 0.313 - Wy 0.329
Additional descriptors... None

Timing characteristics
Range limits............. Not available
GTF standard............. Not supported
Additional descriptors... None
Preferred timing......... Yes
Native/preferred timing.. 1920x1080p at 60Hz (16:9)
Modeline............... "1920x1080" 138.650 1920 1944 1960 2080 1080 1082 1087 1111 +hsync -vsync

Standard timings supported

Report information
Date generated........... 07/09/2015
Software revision........ 2.90.0.1000
Data source.............. Real-time 0x0021
Operating system......... 6.2.9200.2

Raw data
00,FF,FF,FF,FF,FF,FF,00,4C,83,48,4C,00,00,00,00,00,16,01,04,90,29,17,78,0A,C8,95,9E,57,54,92,26,
0F,50,54,00,00,00,01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,29,36,80,A0,70,38,1F,40,18,10,
25,00,99,E6,10,00,00,1A,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,1A,00,00,00,FE,00,58,
4A,59,37,4A,80,31,38,34,48,4C,0A,20,00,00,00,00,00,00,41,01,A3,00,00,00,00,02,01,0A,20,20,00,F8

 

Your panel is at risk ... even if the edid is ok for now. You might be fine as long as you don't change anything that will or may change boot mode from pure uefi to uefi-compatible:

You could try, of course, and see what happens ... jk.

However, a cmos reset or full bios flash (inc. nvram) would disable pure UEFI. Even that may not cause harm yet, until the nvidia driver is loaded and does its thing. To prevent that; go into bios right off and make the necessary changes. Take care that there's more settings possible that would enable compatible-uefi and these may not be clearly marked as such; you could be booting csm and not know it.

Besides, that's also an as-of-yet-untested theory only. Wouldn't take any chances and uninstall nvidia 353.xx (that also means no Windows 10). Can recover/rewrite eeprom myself, but if you don't have the tools to do this; don't gamble ! Well ... unless you want to make use of that warranty, of course . Say ... because the screen's dirty and you're too lazy to clean it.

 

I ran windows 10 for over a month and just recently went back to windows 8.1. Then I clean installed windows 8.1, disabling win updates at the same time, just for good measure and went with the 355.82 driver. No issues up until now, if I had to be infected and my screen blown off, it would already have happened by now, no?
Actually I don't think the option to "launch Cms" exists in my BIOS. Do you have an M18XR2 by any chance? Should I leave "fast boot" on or off, cause it was always set to fast never tweaked that.

 

Alienware 18 and sli 860M also at risk? (Samsung panel which is in such good shape I don't want to harm it)

 

Have an AW18 as well and according to @t456 , we can be at risk though not 100% sure as the most affected machine is the M18XR2. Only one or two cases were reported for the 18 but that can just be due to totally unrelated issues so nobody will give you a "definite" answer if that's what you are looking for. Nvidia and dell are still trying to replicate the issue and isolate it.

 

Fair enough. Thanks. I'll stay conservative and stay 8.1 until we learn more. Grateful for the response

 

so after a month after installing W10 and downgrading back to W7 2 days later.
my LCD is still good.
however some residual W10 crapware is still on my system.
i did like the looks and feels of W10 and i eventually upgrade to it, when this issue is resolved.

Sidenote:
the only problem for now is my HDMI-port not working anymore.

I will update my screen info.(if this may help the cause)

 

Hi t456, sorry I've been very busy.
Here are some photo's, only problem is I didn't mark which panel was the faulty one so not sure which out of the two is the culprit. I think it's this one.

 

But it could be this one.....