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

AW17 and M18x R2 both use CompuTrace and WBPT (presumably to make CT possible). However, the P77xZM doesn't use either. Only thing they have in common is Insyde bios + Secure Boot. That angle can be checked, but not without bios exports.

Other angle, copy/pasted from discussion with andrewsi2012 :
Kinda suspect at this point that it's a pure driver thing, though. One that was made possible with 8.x/10, but not before. Microsoft introduced a low-level I2C access driver starting with 8.x, but nvidia only required low-level panel access when it started to introduce g-sync features. It would make sense for them to use the MS driver to gain that access. Remember the number of steps taken in Linux to find the edid? It's the same for nvidia, unless you make presumptions and blindly use the same address (with consequences, if wrong ...).

Anyway, the MS driver that, presumably, solves all this nitty-gritty is termed ' I2C HID Miniport Driver' (hidi2c.sys on drive). It can both read and write over I2C, btw ... Maybe there's a difference in versions 8.x vs. 10 (check 'Properties', please). Would be interesting to see whether disabling that driver altogether would prevent the issue, but that's no small feat with 10's nefarious auto-install shenanigans. Test sequence would be this:

1. no nvidia driver installed
2. disable I2C HID (Device Manager?)
3. install 353.06+ 'kill' driver

Also, if anyone plans on bricking it again (for science!), then use 8.x and work down the list:

1. 347.88
2. 350.12
3. 352.86
4. 353.06

Last one is know to brick, comparing pre-brick/post-brick driver files will show the driver file (and code) that is to blame. Mod new driver with replaced .dll/.sys from older driver and install; display ok -> culprit found.

 

Ohh yes, this is what I've missed.. This is the sort of thing I like coming on here to see what an interesting find with the low level l2c access. It sounds like such a good lead on the whole thing, unfortunately for test purposes I'm no good as mine hasn't bricked yet.

So nvidia by the looks of things may have seen microshites implementation of the low level l2c and have unintentionally created a bug for some of us. If this is the key to everything I hope nvidia has a long speech prepared.

Not long now hopefully !!!

Sent from my Nexus 6 using Tapatalk

 

1. 352.86 in Win10
2. 353.62 in Win10
3. 345.50 in Win7 (after Win10 was installed then removed)

All confirmed (by me) to brick an M18X R2 LCD.

I don't have any more screens or the ability to (temporarily) fix them to do further testing.

 

i'd be curious if it is the HID miniport driver that's causing this mess.

 

There's no L2C HID driver in my device manager listed?

 

First off, I want to apologise for the off-topic comment but does anyone know how to manually control the damn fans on the 18? I know about hwinfo64 but i don't really know how to properly go about doing it without screwing things up and I also heard that it's part responsible for the whole LCD bricking thing, may be wrong though. Cheers

 

HWinfo64 contributes to screen EDID corruption?

 

I read that somewhere but don't take my word for it

 

I had never had this installed on my AW17 Vishnu -destroyer of screens.

 

Proud owner (or not anymore?) 18x R2 - 3920xm, 32 gb ram, 680m SLI(not anymore), 850 PRO 512 ssd
Hi guyz... im a constant reader of this forum for a lot of issues and problems. I would like to thank you all for your information and advice.
I'd like to think im more of a hardware expert then software but regarding this issue i dont think we are gonna get an answer from MS or Nvidia.
So...here is the situation in my case.

1. Win 8.1 Pro fully-upgraded to latest updates ...ready for Win 10 - install Nvidia driver 355.60 all in good condition
But ...after 4-5 days one night i was watching a movie and suddenly the pc stopped with a strange noise.
I tried to start again... NO response whatsoever.
Take it all apart and started without the gpu's... it started.
Then take one by one the gpu's and test the power on... one DEAD ...one working. One GPU DEAD
Nice...so far... ONE gpu dead. I thought the testing, benchmarking and OC killed it.
2.After 2 days i tried to power on the pc and got 8 beeps...then i was sure wasnt the OC or benchmarking killed the 2nd gpu.
Google-it and find about the issues... LCD DEAD
Start the system with intel gpu...uninstalled all nvidia drivers with DDU- safe mode and turn it off.
Let the system working on one gpu and install the 352.86 driver version. I tried this version cause was the last version without the DSR.
All nice and steady
3. After another 2-3 days... one morning trying to start the pc... another 8 beeps... Ohhhhhhhhh...
From the start i knew it's the LCD DEAD ...put another LCD... but...before that...took all the hdd out and delete win 8.1 partition.
Reinstall Win 8.1 with the new LCD and TURNed OFF the win updates and install nvidia 352.86 version. So far 50 days - NO ISSUES.

From my point of view the DDU didnt uninstall completly all the files and registry entries or some updates modified the entries so the LCD problem persisted after reinstalling the nvidia driver. Since this driver on a fresh win doesnt have any issues and even lower temps... there is something in the win and win updates that messed up our LCD's.
So far i have and 680m dead and 2 LCD's dead as well. Thanks MS and your optimized(shi***) software.
WIn 10 is OUT OF THE QUESTION.

 

I apologize if this has been answered but does this problem affect the newest AW 18 laptops with the 980M on their website? I noticed the are stating it is ready for Win 10.

 

No one has one of these at hand to confirm that but unless they introduced some protection mechanism in these machines new bios I believe they should suffer from the same issue

 

Yes their have been a couple confirmed cases with 980m's. They just aren't as common due to how few people have them compared to 780/880m's.

Also that confirms my hypothesis about it being connected with Windows updates. After mine and @Arestavo bricked after installing windows updates, I thought that was fishy. I'm almost positive it has to do with the last set of 4 updates. I wasn't expecting a brick so I didn't screen shot them but I believe they are for Windows 10 upgrade.

 

Yes, HWiNFO can be ruled out, thankfully.

That is ... disconcerting, that driver is ancient. Wiped the mbr/gpt table? Anyway, it matches Mr. Fox's exhaustive steps, with the same result:

Now, have an 'infected' AW17 A14 bios post-10, thanks to syphear's nifty soldering . If someone can export the A14 from a non-10 system (not 10 once, mind) then we can make a proper compare. Already have pre-flash stock, but the 60kb difference with post-10 can be narrowed down further by using a post-boot version (nvram fluff).

It's possible. Remember the effort necessary to enable write-protect? Apart from the hardware pin on the eeprom, that also required setting the WP-bits in the eeprom itself. Flipping bits is a two-way process; bit set to wp-ON can be set to wp-OFF (and vice versa).

Consider that 'HID over I2C' has write capability and MS themselves mention the trouble with enumeration over I2C:

They'd better re-read that acpi table upon each boot; Intel-mux table ≠ Nvidia-mux table. Oh ... right; having Fast Startup enabled would kill that dead (<- that 'feature' is a seriously bad idea).

Anyway, theory goes;

1. Nvidia creates buggy i2c-capable driver ages ago.
2. Buggy nvidia code can't do much (display wp = on).
3. Install 10 + hidi2c.sys (different version from 8?).
4. Hidi2c.sys flips wp-bit on edid eeprom (intentionally or otherwise?).
5. Buggy nvidia code back with a vengeance.

Since the wp-bit remains flipped; no re-install, re-flash or zero-ing is effective. Edid eeprom remains at-risk as long as nvidia driver rears its ugly head, no matter the OS. Removing hidi2c.sys would have no effect; wp-bit has flipped, driver won't set it back.

So, to verify, we'd need this system ... :

• non-optimus+10+affected display
• hidi2c.sys active
• nvidia driver (optional?)

... and run this check:

• use the write-edid tools with a slightly different, but valid edid

If the new edid doesn't stick, then the eeprom is write-protected and no nvidia driver can touch it, explaining why some can run 10+nvidia with impunity.

Even better would be this system+check ... :

• non-optimus+nvidia+affected display
• windows 7/8 (not 10 or pre-10 once)
• use the write-edid tools with a slightly different, but valid edid

Option A.) New edid sticks? -> wp=off, can stop inquiry now (bummer; lucky bastard ).
Option B.) New edid doesn't stick? -> wp=on, proceed to Test #1 and #2.

Test #1:

• windows 10
• hidi2c.sys prevented from running even once (tricky; remove from install medium)
• nvidia driver (optional?)
• switch igpu/dgpu in bios (optional?)
• use the write-edid tools with a slightly different, but valid edid

Test #2:

• windows 10
• hidi2c.sys installed and active
• nvidia driver (optional?)
• switch igpu/dgpu in bios (optional?)
• use the write-edid tools with a slightly different, but valid edid

If ' #1 -> wp=on' and ' #2 -> wp=off', then Micro root can foot half the bill.

Ah ... testing is so much simpler if you had practically unlimited resources ... like Nvidia, Dell and MS ...

Device Manager doesn't show all devices; check ' Show Hidden Devices' for that (and 'Non-PnP Drivers'). That's how you disable that annoying 'beep', btw. Failing that, if MS has hidden it here, as well, then simply search for ' hidi2c.sys' on drive.

Hmm ... there's also a bug report on this:

Spoiler: HIDI²C Driver Does not Load

If the I²C Controller driver loaded, but the device does not appear in the Windows Device Manager, refer to the following.

The above issue typically occurs if there's an invalid ASL code for the host or the device. To determine whether the problem was due to a failure to match the INF, refer to the setupapi.dev.log file. Another indicator that the problem is due to a mismatch is Error Code 10 in Windows Device Manager.

To resolve this issue, ensure the following.
The _CID value must be PNP0C50.
The I²C controller and device characteristics in the BIOS must be accurate.
The HID descriptor address (for the device) in the BIOS must be accurate.
The GPIO Interrupt must be correctly identified and marked as Exclusive, Level, ActiveLow.

Refer to section 13 of the HID I2C Protocol Spec for more detail. (This specification will be available at a later date.)

So ... in case you were wondering why your system hasn't been affected ... Maybe try fixing that error, getting hidi2c.sys to run and see what happens ?

edit:
Converted by Mr. Fox at last; MS deserved a new name, thanks to their WPBT rootkit ( ??!).

 

if there's a difference between the 8.1 and 10 driver would a simple swap fix it?

 

Has anyone else been seeing screen anomalies on load? Basically only on 10 I get ( for a second or two ) some weird lines that come on screen right before Windows loads but luckily that is it so far aside from an increase in Nvidia driver errors.....

 

does rolling back the drivers do anything?

 

Thanks for all the information, right from what can tell Non PNP isn't available on Windows 8+ and show hidden devices still doesn't show the l2c interface (I'm not complaining)

So I follow those steps for the debug and I found out 2 things, 1 hidi2c.sys filth is on my system However, when I check the setupapi.dev.log I cannot find any match for CID neither PNP0c50 and also I have the same error multiple times but rather than one line of code I thought the actual thing that tried to install and failed was interesting as it does have something to do with display.. I think anyway?..

Code:

 dvi:           {DIF_INSTALLDEVICE} 09:26:48.962
     dvi:                Class installer: Enter 09:26:48.962
     dvi:                     {Install DEVICE}
     dvi:                          {Writing Device Properties}
     dvi:                               Strong Name=display.inf:10809047d4324726:MSBDA:6.3.9600.16384:pci\cc_0300
     dvi:                          {Writing Device Properties - Complete}
     inf:                          AddService=BasicDisplay,0x00000002,MSBDD_Fallback_Generic_Service_Inst,  (basicdisplay.inf line 63)
     dvi:                          Add Service: Modified existing service 'BasicDisplay'.
     dvi:                     {Install DEVICE exit (0x00000000)}
     dvi:                     Install Device: Starting device. 09:26:48.978
     dvi:                     Install Device: Starting device completed. 09:26:48.993
!!!  dvi:                     Device not started: Device has problem: 0x1f: CM_PROB_FAILED_ADD.
     dvi:                Class installer: Exit
     dvi:           {DIF_INSTALLDEVICE - exit(0x00000000)} 09:26:48.993
     dvi:           {DIF_NEWDEVICEWIZARD_FINISHINSTALL} 09:26:48.993
     dvi:                Class installer: Enter 09:26:48.993
     dvi:                Class installer: Exit
     dvi:                Default installer: Enter 09:26:48.993
     dvi:                Default installer: Exit
     dvi:           {DIF_NEWDEVICEWIZARD_FINISHINSTALL - exit(0xe000020e)} 09:26:48.993
!    ndv:           Queueing up error report since device has a PnP problem...

I'm poking around Google searches and the system and I come across this in the event logs as a warning:

Code:

The DSM service was delayed by 11 seconds for a driver query/download/install on device 'DISPLAY\SEC5448\1&8713BCA&0&UID0'

I searched for what the error means just for clarification and yeah it states Windows went out its way to find a driver for the mentioned device.. it strikes me initially because SEC5448 is my panel.. but it does go one level further '1&8713BCA&0&UID0' so unless that's my graphics card that could only mean it was downloading something for the panel?


Update again.. that's definitely the panel

 

It does not, neither does a fresh install. I does not seem to be a major issue and it causes no problems once in Windows just though I would see if anyone else has ever had an issue like this.

I have also tried both unlocked and stock vBios and those don't have any effect either.

 

That's what happened to my previous screen a week or two before she died ... I would recommend to do an EDID check

 

Are you using win 10? If yes, how is it so far?

 

I though I will post a quick update:
With Windows (8.1 Pro) updates turned off an no nvidia drivers installed the screen saw it's first month without EDID corruption. Well, 3 weeks without any nvidia drivers and a week with 355.06. Before installing Windows 8.1 Update 1 (latest version on iso from msdn), I secure erased the SSD, installed Windows, then flashed the BIOS from A13 to A10,A11,A12 and A13. I was thinking about installing unlocked BIOS, which is why I wanted to try earlier stock files. Then re-flashed vBIOS to stock and back to slv7. Automatic driver downloads are as always turned off in Device installation settings. Since we have an option to flash the screen in Linux now (thanks a lot @t456) using EFI (R4 is unable to post with any legacy option enabled when the screen is corrupted) pen drive, I decided it's time to test the latest nvidia drivers - 355.98. Intel ME firmware is still on the latest version - 8.1.52.1496, Intel ME drivers were updated from Dell website to 9.5.13.1706, however they updated themselves to 11.0.0.1146 at some point (even though automatic driver downloads are turned off).

nvidia 355.98 drivers seem ok, at least my screen is not corrupted yet. I am still hesitating switching to dedicated mode as this is when the last EDID corruption occurred. Before the last corruption I also installed some Windows updates, just left the ones meant to enable Windows 10 download unchecked. I have a feeling Windows updates are partially to blame as well for these corruptions...

Test results:
http://www.3dmark.com/3dm11/10357104
http://www.3dmark.com/3dm/8766959?

 

Hello,

great log, I noticed a couple of things and one of them being the Intel Management updating itself? Mr. fox did tell me that winshite are so unbelievably sneaky and even with winshite updates turned to off they still will as I first hand seen in the event logs. However you can shut them off completely and to validate this a little more I just compared my Intel Management Engine to yours and mine is well back into the 2012. So first off I'd recommend disabling the updates completely by the group policy

http://windowsitpro.com/systems-management/q-how-can-i-disable-windows-update

Also, have a flick through "View Event Logs" and you'll see dirty Microshite log the updates int he background.. it's so frustrating.

Im running dedicated on Mr. Fox's desktop drivers (version in signature) and I'm having no problems at all, if you see my post a page back in response to T456 I think I've.. I don't know but something that tried to update my monitor failed and I should note it says "writing" not installing so maybe I've done something right to avoid this so far?

 

@t456 - I can't help but poke at that file, this is a large part of it and I'll bold what I think may be relevant.

Code:

>>>
     dvi:           DevDesc      - Microsoft Basic Display Adapter
     dvi:           Section      - MSBDA
     dvi:           Rank         - 0x00fb2006
     dvi:           Signer Score - INBOX
     dvi:           DrvDate      - 06/21/2006
     dvi:           Version      - 6.3.9600.16384
     dvi: {Build Driver List - exit(0x00000000)} 18:26:05.177
     dvi: {DIF_SELECTBESTCOMPATDRV} 18:26:05.177
     dvi:      Using exported function 'DisplayClassInstaller' in module 'C:\Windows\system32\DispCI.dll'.
     dvi:      Class installer == DispCI.dll,DisplayClassInstaller
     dvi:      No CoInstallers found
     dvi:      Class installer: Enter 18:26:05.177
     dvi:      Class installer: Exit
     dvi:      Default installer: Enter 18:26:05.177
     dvi:           {Select Best Driver}
     dvi:                Class GUID of device changed to: {4d36e968-e325-11ce-bfc1-08002be10318}.
     dvi:                {DIF_DESTROYPRIVATEDATA} 18:26:05.207
     dvi:                     Class installer: Enter 18:26:05.207
     dvi:                     Class installer: Exit
     dvi:                     Default installer: Enter 18:26:05.207
     dvi:                     Default installer: Exit
     dvi:                {DIF_DESTROYPRIVATEDATA - exit(0xe000020e)} 18:26:05.207
     dvi:                Selected:
     dvi:                     Description - [Microsoft Basic Display Adapter]
     dvi:                     InfFile     - [c:\windows\system32\driverstore\filerepository\display.inf_amd64_74c972e5eb125870\display.inf]
     dvi:                     Section     - [MSBDA]
     dvi:           {Select Best Driver - exit(0x00000000)}
     dvi:      Default installer: Exit
     dvi: {DIF_SELECTBESTCOMPATDRV - exit(0x00000000)} 18:26:05.207
     ndv: {Core Device Install} 18:26:05.207
     dvi:      {DIF_ALLOW_INSTALL} 18:26:05.207
     dvi:           Using exported function 'DisplayClassInstaller' in module 'C:\Windows\system32\DispCI.dll'.
     dvi:      {DIF_INSTALLINTERFACES - exit(0x00000000)} 18:26:05.387
     dvi:      {DIF_INSTALLDEVICE} 18:26:05.387
     dvi:           Class installer: Enter 18:26:05.387
     dvi:                {Install DEVICE}
     dvi:                     {Writing Device Properties}
     dvi:                          Strong Name=display.inf:10809047d4324726:MSBDA:6.3.9600.16384:pci\cc_0300
     dvi:                     {Writing Device Properties - Complete}
     inf:                     AddService=BasicDisplay,0x00000002,MSBDD_Fallback_Generic_Service_Inst,  (basicdisplay.inf line 63)
     dvi:                     Add Service: Modified existing service 'BasicDisplay'.
     dvi:                {Install DEVICE exit (0x00000000)}
     dvi:                Install Device: Starting device. 18:26:05.387
     dvi:                Install Device: Starting device completed. 18:26:05.950
     dvi:           Class installer: Exit
     dvi:      {DIF_INSTALLDEVICE - exit(0x00000000)} 18:26:05.950
     dvi:      {DIF_NEWDEVICEWIZARD_FINISHINSTALL} 18:26:05.950
     dvi:           Class installer: Enter 18:26:05.950
     dvi:           Class installer: Exit
     dvi:           Default installer: Enter 18:26:05.950
     dvi:           Default installer: Exit
     dvi:      {DIF_NEWDEVICEWIZARD_FINISHINSTALL - exit(0xe000020e)} 18:26:05.950
     ndv: {Core Device Install - exit(0x00000000)} 18:26:05.950
     dvi: {DIF_DESTROYPRIVATEDATA} 18:26:05.950
     dvi:      Class installer: Enter 18:26:05.950
     dvi:      Class installer: Exit
     dvi:      Default installer: Enter 18:26:05.950
     dvi:      Default installer: Exit
     dvi: {DIF_DESTROYPRIVATEDATA - exit(0xe000020e)} 18:26:05.950
<<<  Section end 2015/09/23 18:26:05.950
<<<  [Exit status: SUCCESS]

I couldn't bold what's in the code so I narrowed it down a little. Could be nothing but..

 

mrsweet1991, thanks for the group policy link. I disabled the Windows updates in the group policy as well. Also Update history confirms no updates were installed/failed to install etc. As far as I could see the only option for drivers is called 'Turn off Windows update device driver search prompt', which I enabled now.

 

I double checked the link I sent you and that's not the correct one. Follow this link and at the bottom you'll find the correct path that completely disables the updates

http://www.howtogeek.com/224471/how-to-prevent-windows-10-from-automatically-downloading-updates/

In summary it's:

"Navigate to Computer Configuration\Administrative Templates\Windows Components\Windows Update."

in there Disable both:

• Configure Automatic Updates
• Automatic Updates Detection Frequency

That right there seems to be working wonders so far, not a peep from microshite in terms of updates and event logs are empty for updates

 

Yes, the link referred to XP, so I found where these settings were in Windows 8.1 group policy already and disabled automatic updates. Detection frequency when disabled works the same as not configured. Also, there is a note: 'If the "Configure Automatic Updates" policy is disabled, this policy has no effect.'

 

Good idea, the ' setupapi' logs are perfect to track all drivers installed (inc. nvidia and hidi2c). This might be an interesting find indeed:

Code:

     dvi:                          Add Service: Modified existing service 'BasicDisplay'.
     dvi:                     {Install DEVICE exit (0x00000000)}
     dvi:                     Install Device: Starting device. 09:26:48.978
     dvi:                     Install Device: Starting device completed. 09:26:48.993
!!!  dvi:                     Device not started: Device has problem: 0x1f: CM_PROB_FAILED_ADD.

From my Windows 7 install (file ' setupapi.setup.log'):

Code:

     dvi:                          Add Service: Modified existing service 'BasicDisplay'.
     dvi:                     {Install DEVICE exit (0x00000000)}
     dvi:                     Install Device: Configuring device class. 18:36:09.589
     dvi:                     Install Device: Configuring device class completed. 18:36:09.589
     dvi:                     Install Device: Starting device. 18:36:09.589
     dvi:                     Install Device: Starting device completed. 18:36:09.636
     dvi:                Class installer: Exit

So; compare the same setup log of affected and non-affected systems and we'll know whether this has, in fact, saved your system.

Mind that these installs are automated unless you disable automatic driver install via gpedit (again):

Spoiler: disable automatic driver installation

Without this you run the risk of having it install and run one day ... successfully, this time. One of the triggers for ' BasicDisplay' driver to re-install is gpu driver update or install; a bunch of other devices are 'refreshed' at the same time. Have the Group Policy set like in the example. Disadvantage then is that it'll entail several user interventions to install a 'single' driver. Say a usb stick; that needs about three separate admin-approved device installs now. Of course, there always were three separate installs, but that'd have been quite hard to spot.

 

Thank you for telling me that, I've made the changes now. I was looking through the log again to see if logs about the Display Adapter come up more than once, as we've seen it can take a while before something trigures it and I was curious to see if the display was being accessed more than once (or more to the point after nvidia drivers) however given I had to re-install nvidia drivers again I expected to come across the display adapter being modified again so I did get a little lost.

Anyway, was there no luck with cutting the LCD wires used to write to the EEPROM? it's so frustrating to see illustrations of write protect pins on the chip.. yet it wasn't put on ours :/ when I first seen the illustration I got excited because I thought people where just joining one of the pins to the VCC but the other pin turned out to be a WP pin.

 

Is this something you could use for laptop edid?
http://www.analogway.com/en/products/software-and-tools/aw-edid-editor/

 

@t456 already worked out how to write to the EDID using Linux, the problem is there's code that cycles and keeps changing the EDID so even when the LCD is bricked and you flash the EDID it's only a matter of time before it cycles through again and bricks it.

 

A simple EDID writer for Windows would be nice, but most if not all software solutions have been discontinued years ago...well looks like at least NVIDIA has a "working" one...LOL

 

Haha yeah good point.. I did come across a forum or FAQ where the old version of moninfo used to be able to write to the EDID if it was the paid version

 

Don't know if this is any use but after moving to win10 from win8.1 my Clevo p370sm-a with 980m sli and 355.83 drivers ALWAYS had a short black moment after clicking in the pre-login screen.
Worried about it I did a EDID check and with help from t456 I discovered it was fine.
With win8.1 this black flash didn't happen. But yesterday when windows pushed KB3093266 through it vanished. No more short black screen before entering login screen.
After reading this chain I thought maybe my screen is write protected and something tries to write to EDID during that black period and it won't go through.. ?
Did M$ just pull a fast one on us? And "repaired" the problem?
Again I'm a complete novice when it comes to higher level tech stuff. Just shooting wildly

I pulled the filelist in KB3093266 but don't have the expertise to go through it and see if there is something that would help. It's quite long so I'll link it instead of codeboxing it.

http://download.microsoft.com/download/1/9/F/19F9E46A-0B2A-4007-A280-F517DAB568EF/3093266.csv

 

Not pin#5 only, at least. This was not critical to the function of the display, but didn't prevent writes, either. Trouble is that edid control over LVDS uses three pins; clock, data and voltage. Cut 'data' and no more writes, but reads are impossible too (same pin/wire). With eDP it's the same; single read+write wire (it also lacks its own dedicated clock and voltage wires).

Unknown yet what happens when you cut all three/four edid wires. If bootup sequence doesn't care then you'd have a working display, regardless of whether the edid was corrupted. Anyone with a bricked panel (and no recourse to hotswap, linux boot or external programmer) can test this; clip wires and boot. Easiest fix ever, if that works.

Not sure you've got things straight ...

Write-protect on most eeproms needs two things; properly wired wp-pin (soldering) and the software wp-byte. The 'WP-pin = ON' needs either short to ground/GND or to voltage/VCC (this is eeprom specific). Not all need the wp-byte, though; some can be made read-only with solely the soldered pin. But this hardware+software scenario applies to the two confirmed edid eeproms so far ( Winbond 25X20BLNIG) and most bios/ec eeproms as well:

Spoiler: Winbond 25X20BLNIG - write-protect combinations

Well ... for completeness' sake ... apart from pin-mod-plus-software-mod, there is one other option; if the eeprom is implemented as 'single speed', instead of 'dual', then you could cut the data-in pin of the eeprom. With single-mode it does exactly that; send data into the eeprom (writing). Data-out has its own pin and wouldn't be affected. No software-mod required and edid is bulletproof. Dual mode uses data-in and data-out for both; read +write over the same pin (x2), so it has double read (and write) speed (quite useful for a bios), some even use quad-speed. An edid eeprom has no use for that, though; 256 bytes is hardly worth the effort.

Only thing ... there's just no way of knowing how it was implemented; controller chip (largest IC) determines this and these things are 'closed tech.' (no data available). IF your eeprom is single mode then you don't even need to use software to set the wp-byte (with i2cset):

Spoiler: SEC5044 - two write-protect options

Step 2 of option #2 is optional . But we want to practice as we preach, eh? No need to make the same error Samsung did when building this panel ... (rule is: don't leave pins floating, simple as that).

You can use it to create and modify all edids, laptop, lcd/vga, monitors and televisions. You cannot, however, write these to the eeprom; it's not flash-capable.

Do check it out, though; really nice to get an idea of how the tiny 128 byte edid is structured ('Hexa Viewer' tab). You can also use it to create custom timings (refresh rates) with the 'CVT wizard'. Haven't used that myself; use spreadsheet for this. Also useful for calibration; use calibration tool to find the colour coordinates of your 50" television, adjust these in edid and write back to eeprom (if it doesn't already have a menu setting for this, of course ...).

 

You're a man of knowledge t456 I give you that.. you'll have to excuse me while I read over this a few times to try and understand it a little better But your illustrations are great, are those illustrations similar to that of the SEC5448 panel? I may have jumped to the conclusion before when I read about WP not being on this particular panel but maybe it was meant that WP is there but not enabled. If the WP is there, could we do as stated above either joining it to ground or vcc? Do we have a picture of this panel chips like you've provided above to see the layout?

 

I will try clipping those 4 black wires on my bricked M18X R2 to see if it helps or not. I have a spare LVDS cable just in case.

EDIT: Still have 8 beeps. Interestingly though, the backlight is completely off now - whereas before (even after it was corrupted and had 8 beeps) it would have the backlight turn on.

 

@wikileaker

 

Here is my setupapi log from unaffected AW18 with A10 BIOS, Win10 and automatically installed Nvidia drivers v353.62 (I am a bit scared to touch/update them, still alive after >2 months), if this can be useful:

Code:

     dvi:                          Add Service: Modified existing service 'BasicDisplay'.
     dvi:                     {Install DEVICE exit (0x00000000)}
     dvi:                     Install Device: Configuring device class. 22:58:28.964
     dvi:                     Install Device: Configuring device class completed. 22:58:28.964
     dvi:                     Install Device: Starting device. 22:58:28.964
     dvi:                     Install Device: Starting device completed. 22:58:29.042
     dvi:                Class installer: Exit

It looks same as your Win7 log.

 

Did you flash the EDID back before you clipped the wires?

 

I have no way of doing so.

 

oh right, I was going to say clipping the wires before flashing the good EDID wouldn't have done anything anyway.. ideally flash the EDID so the panel works again then clip the wires to see if it boots and more importantly if it does boot see if the EDID gets written to again.

 

Does anyone know which programmer @Mr. Fox purchased to flash his M18X R2 screens?

EDIT: And can it be used from a desktop computer? Just plug the box into the LCD and the box into the desktop?

 

Didn't you buy a new screen for your Alienware? if you have I'm relatively sure Mr. Fox hot swapped the screen half way through to flash the old one.

 

Yes, and it bricked in Windows 7 with Mr. Fox's 345.50 drivers.

 

Status Update:

Well, I think we can effectively rule out the system BIOS being affected by Windows 10. I replaced my motherboard with another one that never had Windows 10 installed and the LCD/EDID corruption is still happening.

I flashed the GPUs with a stock Dell GTX 780M vBIOS and did a clean install of Windows 8.1 in pure UEFI (no Legacy/CSM support) mode and the problem is exactly the same. I am thinking that Windows 10 did something to the GPUs that was permanent. There was a warning that Windows 10 is not compatible with GTX 780M and maybe this is the result. I don't know what else to do at this point other than possibly replace the video cards or try a hard mod to the EEPROM chip on the LCD to make it read-only. I'm at a loss now.

@t456 - clipping the additional black wires next to pin #5 on the LVDS cable does not work. The screen stays black and the machine fails to post with 8 beeps with that cable mod.

One thing is for certain. Reinstalling any NVIDIA driver, tested all the way back to 327.23 released in September 2013, and that instantly triggers the EDID corruption. As soon as the driver installation is finished and I reboot to complete the driver installation it fails to post with 8 beeps and the EDID corruption is present. I temporarily attach a good LCD, boot up Linux, hot-swap to the bricked LCD and flash a good EDID and everything is OK temporarily. Everything seems fine for a while, but after a few reboots or shutdowns, usually less than 24 hours, something triggers the EDID corruption and the circle continues. Why it happens even with very old drivers we know to have no issues, and never had any issues in the past, is a mystery.

Perhaps Windows 10, in fact, did something to permanently damage the 780M cards, as multiple vBIOS flashes hasn't cleared the issue. So, different motherboard, multiple vBIOS flashes, virtually all versions of GeForce drivers produce the same problem. There's not much left at this point. Everything was fine before Windows 10 cancer literally ruined everything. I don't think I will ever have anything nice to say about Micro$loth for the rest of my days.

The EDID corruption has not returned to the AW18 yet. I thought maybe Windows 8.1 in pure UEFI mode was making it continue to function, so that is why I tried it on the M18xR2 today. But, we see the same corruption pattern. 0x14 is changed to '00' and should be '90' which breaks the checksum and causes 8 beeps.

Corrupted EDID:

Code:

00: 00 ff ff ff ff ff ff 00 4c a3 48 54 00 00 00 00    ........L?HT....
10: 00 14 01 04 00 29 17 78 0a c8 95 9e 57 54 92 26    .???.)?x????WT?&
20: 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01    ?PT...??????????
30: 01 01 01 01 01 01 29 36 80 a0 70 38 1f 40 18 10    ??????)6??p8?@??
40: 25 00 99 e6 10 00 00 1a 1c 24 80 a0 70 38 1f 40    %.???..??$??p8?@
50: 18 10 25 00 99 e6 10 00 00 1a 00 00 00 fc 00 4c    ??%.???..?...?.L
60: 54 4e 31 38 34 48 54 30 32 53 30 31 00 00 00 fe    TN184HT02S01...?
70: 00 4d 72 2e 20 46 6f 78 27 73 20 6c 63 64 00 b8    .Mr. Fox's lcd.?

Valid (Flashed) EDID:

Code:

00: 00 ff ff ff ff ff ff 00 4c a3 48 54 00 00 00 00    ........L?HT....
10: 00 14 01 04 90 29 17 78 0a c8 95 9e 57 54 92 26    .????)?x????WT?&
20: 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01    ?PT...??????????
30: 01 01 01 01 01 01 29 36 80 a0 70 38 1f 40 18 10    ??????)6??p8?@??
40: 25 00 99 e6 10 00 00 1a 1c 24 80 a0 70 38 1f 40    %.???..??$??p8?@
50: 18 10 25 00 99 e6 10 00 00 1a 00 00 00 fc 00 4c    ??%.???..?...?.L
60: 54 4e 31 38 34 48 54 30 32 53 30 31 00 00 00 fe    TN184HT02S01...?
70: 00 4d 72 2e 20 46 6f 78 27 73 20 6c 63 64 00 b8    .Mr. Fox's lcd.?

 

Omg! Then we need focus on gpu. I got 2 Dell 780 with stock vbios Windows 10 and problems 0.

 

@Mr. Fox glad to see you've returned! However I was expecting good news I must admit. Anyway, something you mentioned.. you seem to follow the pattern of bricking within 24 hours.. or a short time at that. I can't understand why people like me are avoiding it for a much longer period of time, I've been pretty static in keeping the system with the same configuration and settings, but a new motherboard and brick straight away? There's got to be a reason why there's time differences, I know for me I would have been a little unique in the sense that I was on Windows 10 for a very small space of time, hours in fact with no drivers installed at all (nvidia, dell) but I can confirm I did install windows updates but only the first batch.

Hard mod sounds great! but is it possible?

 

Where did you get the modified 355.98 drivers? I was looking at those because there's no SLI profiles for some games I have witht he versions I have. Also if we're assuming it's the GPU's then I may as well instlal the newest lol