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

I thought my LCD died =O Alienware Logo head popped up but screen was black for a good while until the windows login screen shown. Maybe it has something to do with the samsung magician OS optimization for quick boot.

One other thing, MonInfo Real time says "Data source.............. Real-time 0x0100" where I'm sure just before I shut down it was reading 0x0200

 

Mine is all good at the moment and have been on Winshite 10

 

@Mr. Fox - you where right about Windows Updates, I disabled them via the "control how windows update works" or something and I recently viewed the event logs and behold a long ass list of updates installed in the background. It's really makes you wonder why they do it.. I managed to find a tut and disabled windows updates in the policy and also check for update interval time set to disabled so surely that should do the trick.

Have you installed any of the unlocked BIOS's from Tech Inferno? I was going to do one but some people ran into the 8 beep problem (of course solvable in this case) but that just put me off a little.

 

I feel I should post my config also, just in case.

Alienware 17 - GTX 860m - Purchased May of 2014 - BIOS Version is A14 - Integrated GPU Disabled - UEFI No Legacy, No Secure Boot.
When running Win 10 since it was available on the night of July 28th, I only installed Nvidia's 353.62 but I did installed it multiple times (using DDU to remove all past settings and files) with no issues. I ran it until Sept. 20th when I finally formatted and reinstalled Win 8.1 on my main SSD. I am currently using Nvidia 355.82 with no issues. Have never run HWiNFO on this PC as far back as I can remember. Haven't had any problems what-so-ever with 8-beeps or LCD Panels going out.

 

Can you upload both .roms?

Just to be sure, though. Think we might rule out vbios corruption then. At least, as far as nvidia vbios is concerned; intel vbios is an oprom inside normal bios. We need a bios extract and compare to check that.

Weird, don't have that option. Might be OS or gpu dependent. Could be because the edid bus is hugged by Intel HD (Optimus system).

That's possible; I2C bus number is re-enumerated upon boot.

Spoiler: side-note (off-topic)

Been tracking down the small non-nvram change in my (latent) Secure Boot bios:

Spoiler: pre- and post-flash non nvram change

Turns out the 'FIT' and GUID ( B52282EE-9B66-44B9-B1CF-7E5040F787C1 ) designate the ' Firmware Interface Table', listing address, size and type of the various firmware modules loaded during boot.

Not sure how to read that change; maybe it justs re-routes all option rom addressess to RAM?

Comparing the index of both pre-flash and post-flash (slightly renumbered for ease):

Spoiler: pre- and post-flash changes, Non Critical Blocks

Either MMTool is confused here or this is the SB (or Secure Flash) method in action ... anyway, the padding file (not in image) has shrunk by 128 KB and the Non-Critical-Blocks size has also shrunk by 128 KB. This means there's now an extra 128 KB of critical code injected somewhere, but this snippet can't be located using the index.

Code:

padding pre-flash:  196,608 / 192 KB
padding post-flash:  65,536 / 64 KB
diff:                        -128 KB

NCB pre-flash:      196,608 / 192 KB
NCB post-flash:      65,536 / 64 KB
diff:                        -128 KB

Could simply be the extra 'Firmware Volume : 01' copy; it's 128 KB and it's right in the now non-NBC area. Hmm ... think this may be the potential life-saver on a 'bad flash'; the now-critical copy won't get flashed and remains untouched, permitting a minimum boot, so you can re-flash with a good bios.

Will consider this 'case closed' and simply remove the Secure Boot mod plus its three ' Key databases' and flash that SB-cleansed bios.

 

Mine bricked without installing HWinfo

Extended your warranty, it may be the best $200 you spend

Dam that's lucky, I've tried with to boot with precision LCD's on alienware with no luck.

Yes, me - 120Hz panel

 

I think the option appeasr if you boot after disabling the intel gpu and booting with the nvidia gpu active only.

 

I will share them with you by PM for corruption analysis. My custom vBIOSes are a "private reserve" (a unique variation of a publicly available mod) so I won't post them here in the forum. The video cards that were in a corrupted machine are working without issue in the M18xR1. They were swapped around as part of the trial and error on my end and it appears the vBIOS is either unaffected or not affecting the M18xR1 which has never been molested by Windows 10.

Side Note: We are on day #2 of running Intel HD Graphics without incident of EDID corruption.

 

Yes, so:

• Nvidia vbios corruption is NOT the issue.
• HWiNFO can be cleared.

Only thing remaining is bios corruption (or ME/EC, as a secondary option). We'll get there, step-by-step.

 

If this is the case would a new motherboard do the trick? I know if thats the case a reflash is the obvious thing to do but I mean in a worse case?

 

I'm going to take an unscientific wild guess that the cancer is in the ME or Compal EC. I'm extremely suspicious of the Intel ME and always have been (since before Windows 10 was invented). I think it is a back door for naughty things and an extra place for "official" malware to be deployed by Intel, Micro$loth, NSA, etc.

Flashing the BIOS does not work. I have blind flashed the M18xR2 at least 5 times since this problem started. I also incrementally flashed from A03 (blind flash) to A07 > A08 > A09 > A10 > A11 > A12 > A11 Unlocked. Doing that didn't phase the EDID corruption problem.

---

There are two contacts on the M18xR2 motherboard (see red box). The Alienware 17 and 18 also have them. The M17xR4 may also (probably does) have them. They are difficult to see on the 17 and 18 because they are partially covered by the chassis. On the 17 the are near the edge of the motherboard near the battery under the chassis. On the 18 they are on the HDD side of the RAM slots under the chassis. You can see them and reach them much easier on the 18. On the M18xR2 these contact are right next to the socket for the CMOS battery wire and easily accessible.

I believe bridging these contacts should reset the CMOS and the ME, but bridging them does not seem to do anything as far as I can tell. I have not tried with AC adapter connected, only with the coin cell battery connected and disconnected. The yellow box is what should be the system BIOS EEPROM on the M18xR2.

 

Do you flash clean me and ec each time you blind flashed the bios?

 

Please explain what you mean and how.

The stock BIOS flash programs the EC as part of the flashing process, when there is an EC update. So, regular stock BIOS flashing has flashed the EC more than once already. I'm not sure where you are getting a Compal EC or how you are flashing it separate from the process. Flashing the incorrect EC can really screw up everything or brick the motherboard if my understanding is correct.

Flashing the ME can be risky and the times I have tried it error out when attempted. Maybe my ME flashing process was not being done correctly.

 

Sorry, I knew flashing the BIOS is something you have done and didn't work. I meant flash those things mentioned IC? I can't remember what they where. I also like the way you went through each and every BIOS.. That's aa long but great way to eliminate things out of the equation

 

I'm used to prema on Clevo. You flash the ec, shutdown, unplug for 30 seconds, boot back to thumb drive, flash me and bios, then reboot, enter bios and set it up. Granted, Prema streamlined the process by including batch files, and at times recommends not performing the reboot in between of flashing to older ec and bios (support issues and will brick the system going to a non supported ec). That was why I mentioned it, not knowing if Dell has an exe that is able to be extracted to reach the individual components (or find the bios versions where the last upgrade occurred to get the individual components) to be able to flash all together.

 

OK, that makes more sense. I know exactly what you are talking about with Clevo. Thank God for @Prema, LOL.

With Alienware, doing one sBIOS flashing process does it all in one procedure.

 

what I'm suggesting is knowing which version of the ec and me that are currently installed with your preferred bios version. Track down which executable bios incorporated the flash programs and files for the ec and me. Then creating a batch file to flash all three without rebooting in between. I know it is convoluted and different from how Dell normally does it, but may work and will clear all three at once... Just a thought.

Edit: I don't know if Dell incorporates the ec and me flash in every sbios they put out is why I suggested it.

 

That's why I flashed all of those versions in a row. You can actually see during the flash process when the EC is being flashed and the ME version shows on the BIOS main screen. So, that being the case we already know for sure that both have been flashed more that once, unless the Windows 10 cancer has deep hooks that make it persistent and resistant to removal by flashing, it should have been cleaned up already by flashing.

 

Fair enough. Just figured I'd suggest it in case, but seems it has been tried...

 

Yes, unfortunately, without desired results.

I'm amazed that that didn't fix anything. If they can make something that persistent, I can only categorize it as an evil root kit. Nobody should be making their crap that resilient to intentional efforts to remove it. That's extremely evil on their part. They have no right to do that either, in my opinion... a very grievous trespass and overstepping boundaries of acceptability. This is my personal property, and I have been inappropriately violated.

 

I couldn't help but notice, there's a similar thread below this "Windows 10 and nVidia 980M GTX , M17X-R4, without Optimus: Working Great !"

And they're having a hunky dorey time on winshite 10 and new nvidia drivers... I had to comment and ask if non of them have had an LCD problem its just bonkers how we're avoiding 10 like the plague and they're happily using lol?

 

There appears to be an un-Godly connection between this problem and Kepler GPUs. In particular, 780M and 880M account for the majority of people experiencing problems with EDID corruption. Unfortunately, 980M does not work correctly in the M17xR4, M18xR2, AW17 or AW18. They work with functional limitations and somewhat reduced performance due to BIOS compatibility problems. I purchased 980M SLI for my M18xR2 and ended up going back to 780M SLI because everything worked right and I was not willing to tolerate the functional limitations.

 

Well I returned back on Win 8.1 because of this thread, but the 2 days I "played" with Windows 10 was fine and no problems. The only problem I was facing with 10 is this:

http://forum.notebookreview.com/thr...-the-display-will-not-wake-up-turn-on.780879/

I do believe, that this LCD bricking issue is affecting a very little percentage of people. Remember, until everything is good, nobody comes to complain.

 

But then that makes me think back to vbios being ruled out on our 780's.. Different card but no EDID corruption I get confused just thinking about it. Well keep up the good work anyway

 

@t456 ... Brother I followed your instructions through the UBUNTU path and my checksum is valid ... So this means that The new screen didn't get microsofted yet ?

 

yep, but still don't count on that it can come silent and then it hits hart

 

I am currently running W8.1 with Nvidia drivers 347.88 after doing lots of NVROM flushing, Bios & vBios re-flashing ... There is nothing much I can do atm. other than pray to god to relieve me from the Evil that is M$/NVIDIA/AW

 

Which panel did you have? Good idea to make a backup, just in case ... unless it's in the edid archive already:

Spoiler: pnp id - notes - interf - panel nr. - edid eeprom

Code:

pnp id  notes   interf  panel nr.      edid eeprom
------- -----   ------  -------------  -------------------
AUO219D !       LVDS    B173HW02 V1
CMO1720 !       LVDS    N173HGE-L11
LGD01CA         LVDS    LP173WD1-TLA1
LGD0226         LVDS    LP173WD1-TLC2
LGD0285         LVDS    LP173WF1-TLC1
LGD0289         LVDS    LP173WD1-TLA3
LGD02C5         eDP     LP173WF2-TPA1
LGD02DA !       LVDS    LP173WF1-TLB3
LGD02FC C       LVDS    LP173WF3-SLB2
LGD0343         LVDS    LP173WF1-TLB5
LGD0391         LVDS    LP173WD1-TLE1
LGD03FB         LVDS    LP173WF1-TL**
LGD046C E       eDP     LP173WF4-SPD1
MEI96A2         eDP     VVX16T020G00
SDC3654         LVDS    LTN173KT03-W01
SDC4852         eDP     LTN156FL02-L01
SDC4C48 !       LVDS    LTM184HL01-C01
SEC314A         LVDS    LTN184HT03-001
SEC4A4B         LVDS    LTN184KT01-J01
SEC5044 !?AW    eDP     LTN173HT01-301  Winbond 25X20BLNIG
SEC5044 !?AW    eDP     LTN173HT02-D**  Winbond 25X20BLNIG
SEC5044 A       eDP     LTN173HT02-P01  "" ?
SEC5044 A       eDP     LTN173HT02-T01  "" ?
SEC5443         LVDS    LTN170CT08-D01
SEC5448 !       LVDS    LTN184HT02-S01
SEC544B B       LVDS    LTN173KT01-***
SEC544B BD      LVDS    LTN140KT**-***
-----------------------------------------------------------------------------------------------------
!  = known bricked panels
!? = bricked, but unknown which one
*  = unknown part id
A  = highly suspect: multiple variants exist, perhaps the others are safe ...
B  = multiple variants, flash the correct one!
C  = EliteBook 8**0w DreamColor, 10-bit, for fun ^^
D  = 14.0" version for M14x, just in case
E  = G-Sync approved panel (hint ^^)
W  = write-protect possible

If multiple edids exist for one PnP id; flash the most recent edid, unless indicated otherwise.
-----------------------------------------------------------------------------------------------------

Btw ... To all with a bricked panel:

Please check whether yours is marked with a ' !' in that list. May have missed a few, so report back if your bricked display is either non-flagged or missing altogether.

Ditto.

The Win-RAID Forum guide has always worked for me (DOS option). Maybe try that, if you haven't already (and write backup for evidence, of course).

 

Are their any descent screens available for the m18x that doesn't seem to be breaking?

@Mr. Fox - in regards to the 980 not seeming to cause much problem, is it possible to swap to a 980 and avoid at this stage?

 

It is a 3D-120HZ SEC5044-173HT ... I don't know if it is 173HT-01 or 02 though

 

Unknown if it will prevent it - yes, you can swap it if Windows 8.1 is running in pure UEFI mode. The 980M is not bootable in Legacy or UEFI with CSM/Legacy Option ROM on 17 or 18, and with AW M7xR4 and M18xR2 only with unlocked BIOS set to SG/Auto (Optimus) mode, and for M18xR2 that means no SLI. If you try it in Legacy/CSM with PEG mode you will get 8 beeps just like the LCD bricked display. And, 980M will also not work with Windows 7 except for single GPU in Optimus mode (booting from Intel Graphics).

 

There have been quite a few reports of the 980m getting the 8 beeps too. It should be noted that more people use Kepler GPUs rather than the new 970m and 980m which explains the disparity in the number of GPUs being affected. With that being said, the Kepler GPUs have been subjected to many bad things from NVIDIA like drivers gimping them so this issue being geared towards them actually makes a lot of sense. Your best bet would be to sell your m18 and either get a desktop or go with a new laptop.

@Mr. Fox , Any reports of Sager and MSI biting the dust as well or is it only Clevo and Alienware?

 

Clevo is sold under a variety of boutique brand names, including Sager, Eurocom, Falcon Northwest, XoticPC, PowerNotebooks, OriginPC and many others. Those are all Clevo.

I have no idea about MSI. I pay no attention to that brand because they only peddle BGA CPU filth, like Razer, Aorus and ASUS, and nothing they make in a notebook interests me.

 

Oh okay, it's weird we haven't heard of any Sager laptops failing though. On a side note, I heard MSI is working with NVIDIA to fit dual 980s (notebook) in their GT80 Titan. If it is true, that would be insane performance equal to dual 980s (desktop).

 

I see, sounds a tad rubbish. Awesome GPU.. But no I think if I had a 980m I would be happy going back to 780m sli so Ill stick with it for now.

Did you try an AMD card to see if it would reverse the affects?

@PC GAMER yes that would be a sure way, but I remember how I felt when I stumbled upon this thread looking at this 1k machine knowing its on borrowed time.. I don't think I could sell it to someone knowing what I know now.. It would linger on my contious. But we have Mr fox and t456.. I hold my hopes and remain optimistic.

 

No, there's a few CMOs. But these don't count since you mentioned the word ' decent' ... and no guarantee these won't brick, either. The Asus they are used in is an Optimus system.

 

Haha I like the fact you took notice of decent. I may have already asked, but given your knowledge and what you've ruled out.. Doesn't it have to be something stored on the motherboard now? Vbios, hard drive RAM ruled out so wouldn't a new motherboard sort it? I just want to know the worst case, I don't even mind the thought of having to buy something.. But each time in read this thread it gets more confusing with where the root of this lies.. And if I haven't already said.. Great work so far! I don't understand much of what your saying sometimes in respects to the work you're doing but it sounds interesting an keeps hopes up

 

Can someone with an LG D02DA post the following part of the dxdiag output? I want to know if the 60.012Hz value is normal. You just press win+r and then type dxdiag. Oce it opens you click "Save All Information" and save it to a text file.

 

Code:

Display Devices
---------------
          Card name: Intel(R) HD Graphics 4600
       Manufacturer: Intel Corporation
          Chip type: Intel(R) HD Graphics Family
           DAC type: Internal
         Device Key: Enum\PCI\VEN_8086&DEV_0416&SUBSYS_05AA1028&REV_06
     Display Memory: 1696 MB
   Dedicated Memory: 64 MB
      Shared Memory: 1632 MB
       Current Mode: 1920 x 1080 (32 bit) (60Hz)
       Monitor Name: Generic PnP Monitor
      Monitor Model: unknown
         Monitor Id: LGD02DA
        Native Mode: 1920 x 1080(p) (60.012Hz)
        Output Type: Internal
        Driver Name: igdumdim64.dll,igd10iumd64.dll,igd10iumd64.dll,igdumdim32,igd10iumd32,igd10iumd32
Driver File Version: 9.18.0010.3324 (English)
     Driver Version: 9.18.10.3324
        DDI Version: 11
       Driver Model: WDDM 1.1
  Driver Attributes: Final Retail
   Driver Date/Size: 10/8/2013 00:46:44, 8654336 bytes
        WHQL Logo'd: Yes

 

Display Devices
---------------
Card name: NVIDIA GeForce GTX 980M
Manufacturer: NVIDIA
Chip type: GeForce GTX 980M
DAC type: Integrated RAMDAC
Device Type: Full Device
Device Key: Enum\PCI\VEN_10DE&DEV_13D7&SUBSYS_05801028&REV_A1
Display Memory: 16189 MB
Dedicated Memory: 8023 MB
Shared Memory: 8165 MB
Current Mode: 1920 x 1080 (32 bit) (60Hz)
Monitor Name: Generic PnP Monitor
Monitor Model: unknown
Monitor Id: LGD02DA
Native Mode: 1920 x 1080(p) (60.012Hz)
Output Type: Internal
Driver Name: nvd3dumx.dll,nvwgf2umx.dll,nvwgf2umx.dll,nvd3dum,nvwgf2um,nvwgf2um

 

Thank you @syphear and @Maksym Karpov . It solved the mystery why i had 60.01Hz at BF4.

I actually accessed the PROFSAVE_profile file of BF4 and can see the following value:
GstRender.FullscreenRefreshRate 60.012482 which explains why it displays 60.01Hz in the games video options.

 

Samsung and Dell don't know either, they've used the same id for different panels. There's four SEC5044 edids in the archive, if necessary, then use the one with the same checksum as yours (last byte value).

Don't worry about the decimals, as it's hardly ever exactly 60.000000 Hz. The value is calculated from the pixel clock, number of pixels (resolution) and interval period (if any). In other words; the thing we think of as 'refresh rate' isn't actually specified as such.

All we know is that the nvidia driver (perhaps in conjunction with 10) made some changes to (semi-)permanent code. Only question is; which code? RAM cannot be ruled out yet (it has an eeprom with code as well), until:

1. Take infected system with bricked display.
2. Swap with new sticks or sticks from a pre-10 only system.
3. A.) Display re-bricks -> strike RAM and continue search.
4. B.) Display doesn't re-brick -> culprit found.

The same applies to all other eeprom-based code, motherboard-based or otherwise:

• Bios (inc. oproms)
• EC
• Intel ME
• Intel vbios
• wlan firmware
• wifi fw
• raid fw

Maybe there's a few more, but rule out each and the single recurring factor is your answer.

So the reverse, really. With each bit of shared data, shared information and shared experience the closer we get to the lowest common denominator. Would be simpler to have an answer from nvidia, of course, but there's only two possibilities here:

1. Nvidia is to blame.
2. Nvidia is not to blame, but one of their partners is.

With 1.): They won't release that information ... (duh).
With 2.): They won't release that information ... (because they'll have a very angry business partner).

Well ... for completeness' sake ... there's a 3.), too; third party, but if it's the NSA after all, then the effect is the same. Besides, someone still permitted the f-up, which leads back to 1 or 2 again.

 

Remember what the newer NVIDIA cards do after a crash on massive OC/OV?
That's right they down-clock for some time to new lows:

- vBIOS re-flash won't clear it
- Changing SSD or OS won't clear it
- Reflashing BIOS won't clear it
- Even putting the card into another system won't clear it.

There is some weird communication between driver and MXM card going on, which seems "vBIOS independent" and only clears itself after that communication happened...not saying it is related but it does that since GTX7xxM generation, so maybe @Mr. Fox could try a GTX6xxM and see if it still bricks his screen!?

Just my 2c.

 

Thanks for the detailed reply and wow I had no idea half those things existed (those parts on the motherboard) I can only imagine the happiness if it was one of the cheapest parts like RAM or WiFi Card assuming you didn't already work out how to flash the crap off it.

I do like your methodology of denomination as well, and when the day comes that you do find it do you think its only a matter of time before you can definitely prove it come from either microshite or nvidia? It would be so interesting to see what would happen given the mayhem its caused.

 

Interesting point I wonder if Mr fox or t456 can answer the connection.. Given the attempts at resetting it I don't see how its possible to store the information to keep it downclocked after replacing and reflashing all of those mentioned

Sent from my Nexus 6 using Tapatalk

 

This thread needs a donation link soon in my opinion lol just imagine us normal people and our hope was with microshite or nvidia...

Sent from my Nexus 6 using Tapatalk

 

Interesting notion ...

1. driver crashes
2. driver writes lower clocks to vbios
3. driver mis-ids vbios eeprom and writes to edid eeprom instead

Only thing is ... there should be reports of 8-beeps prior to Windows 10. Or it's a 353.xx+ 'feature' only, which just happened to be the first 10 driver. If so, then systems never been touched by 10 once ought to be affected as well, provided they're using post-10 drivers.

Anyway, this is something that might be checked;

1. switch to iGPU in bios
2. run 'i2cdetect -l' and 'i2cdetect bus#' to find the edid via iGPU (bus A and address B)
3. switch to dGPU in bios
4. run 'i2cdetect -l' and 'i2cdetect bus#' to find the edid via dGPU (bus X and address Y)
5. run 'i2cdump A B' and check if something/anything is there
6. switch to iGPU in bios
7. run 'i2cdump X Y' and check if something/anything is there

If that 'something/anything' happens to be the vbios ...

Don't have an AW, so ... but otherwise; yes, of course.

Failing software for this, there's soldering as a last resort. And just because there's not a flash program available to the public for a specific piece of firmware, that doesn't mean it can't be written to. See the NSA's raid fw flash trick, for example.

 

This throttle is probably a single bit in the GPU core triggered by a crash.

So if the driver finds the bit through the vBIOS, it clocks the GPU down until whatever routine wrote it resets it again.
It gave us a hard time during initial vBIOS development...

What I am saying is:

It won't be an EDID table somewhere hidden in limbo, it'll likely be a trigger bit which makes the driver do it again and again unless its cleared. Low-level screen access in the NVIDIA driver came only with the introduction of g-sync into the Notebooks driver...

 

So, it's exactly as we thought - Windows 10 installs some rootkit in a BIOS table, it only ever affects the laptop after Nvidia drivers are installed - and BAM! Soft bricked LCD EDID.

I, for one, am growing fed up with waiting. I am giving Nvidia until the end of next week until I will be seeing them, Microsoft, and Dell (just to cover all bases) in small claims court. They can explain away there how it isn't their fault while I live demonstrate my laptop's LCD soft bricking.

 

Doing what big business is getting really good at - Arse covering!!!
Nah, not the NSA, the men in BLACK - That's why we can't find the solution, they keep resetting our memory, lolhaha

Mr Fox had a similar thought with using a couple of 7970's - But keeping it NGreedia would probably be better

Are you in AU? Do you want to join us? There is 3 of us in AU so far with LCD issues. More cases together will support our argument and make it harder for "them" to win