***EVGA Precision X and Windows 7/8/8.1 and especially 10 bricking systems***

It's a cocktail of crap that creates a comedy of errors that can end in tragedy. Precision X does not have to be present, but having it present seems to enhance the likelihood of problems. Precision X does not work for AMD GPUs. It is exclusively for NVIDIA. All reported examples involve systems with NVIDIA GPUs, no AMD examples. My main point is the one thing that is absolutely required to create havok comes from the evil devils in Redmond. The problem never existed before these idiots spread their cheeks and dropped a smelly load on us known as Windows 10. The timeline is too compelling for it to be a coincidence. I didn't brick 3 Alienware screens and 1 Clevo screen as a coincidence and the lowest common denominator is their crappy new OS. That's all I am saying. I'm sure there are technical details and subtle nuances that we do not understand and most certainly will never be willingly disclosed to us. All I know for sure is, nothing was broken before Windows 10 and GeForce drivers designed to support Windows 10.

As a side note--probably related, but I cannot prove it--my 780M GPUs ran flawlessly before NVIDIA started focusing on Windows 10. I cannot use ANY drivers with a version number that provides full Windows 10 support without severe throttling that renders those GPUs worthless on any OS. They only work correctly with driver versions pre-dating Windows 10 support. So, another example of Windows 10 being at the root of the problem. Had Micro$lop not produced such a horribly botched up mess, I doubt we would have any threads like this one.

 

Your machine working flawlessly doesn't mean you are safe. My machine worked flawlessly for 3 months and one day out of the blue I got hit without installing anything special at the time. Also I never used Precision X.

 

Well, mine's been fine for half a year now...

Anyway, the common denominator is Nvidia after all, the way I see it. The new driver updates that offer the low level hardware access came out round about the same time and are still out. Don't forget that when you install a fresh copy of Win10 you also get some sort of a driver already in the OS (otherwise you'd be running at a crappy low res and lagging, like used to be the case with Win XP and even 7 if the card was too new or too obscure). There seems to be no other reason for Win7 or 8 to brick either. I can't imagine the win10 ready updates granting any low level access because even if it needed to do so to tie the OS to the system for activation purposes - you wouldn't need to "upgrade" first (meaning it needs a previous install to determine your activation).
All that and AMD being safe just points to an Nvidia failure somewhere to me, the rest looks like a massive timeline coincidence.
The "Redmond Devils", as brother Fox puts it, may have granted access to more stuff than it needs to, but that does not seem to affect AMD in any way shape or form. You can't take all the Nvidia based computers that crapped out and say "Win10 did it", while ignoring the fact that nothing happened to AMD machines running the same OS and screens and the fact that literally all the machines were running Nvidia hardware and Nvidia drivers...
i know hate for Win10 is strong in you, Fox, but let's think rationally!

 

Maybe the low level access and thus the screen problems are due to how activation in Win10 occurs which is tied to the hardware.

Maybe if Microsoft was giving actual keys to activate we wouldn't have this problem.

 

OEM Windows installs were always tied to the hardware (Win 7 for sure and probably even earlier). You may have even noticed that starting with Windows 8 you no longer had a Windows activation key printed on a sticker on your PC/laptop if you bought one with Windows pre-installed, for example, as it was not necessary.
If you have a look at some of the OEM activation problems people have - hardware swapping was an issue as far back as Win7 (this is just from my recent experience as I had my OEM Win crap out at me too after adding an SSD, but I'm sure there may be similar problems with older OEM systems like Vista).

I highly doubt it's in any way related as it's not a new thing by any means.

 

@Mr. Fox Hi mate. After reading through a fair bit of the information, I have a question.

Am I correct to say it does not affect those using Optimus + Nvidia gfx card?

 

I believe that is correct. I am not aware of any example of this happening to an Optimus system. There's always a first time for everything, but I think you're probably safe.

 

I called Dell tech support just for fun and inquired about the ongoing issue. He even asked around and nobody there knew anything of the issue. That is tier 1 support but still.

 

Ha i got hold of microsoft support and got this

Good day! Thank you for contacting Microsoft Customer Service.



Microsoft always appreciates it when customers take the time to provide their feedback. It is with great concern we received your email outlining the issue you had with Windows 10 NVIDIA drivers. Please accept my sincere and unreserved apology for the inconvenience this has caused you. I will let our management know about your insight with regards to your service experience. We will make sure that this gets addressed. By taking the time to submit your feedback you've also ensured that it is in the system of record, and available for review by Microsoft.





Sent from my GT-N7105 using Tapatalk

 

One thing that doesnt sit well in win10s favor in the blame game is even on my amd powered m18x my screen quite often will post nothing like it doesnt work at all and i have to turn it off and on again. And this only started as soon as i upgraded to win10. . Also i accidentally disabled my hard disks one time when i reset the bios and win10 got amazingly far into its loading sequence before i realized my hdd was disabled. So 2 things.. why is an operating system even able to effect my pc before it even posts the logo?? Also where in the hell is it storing that loading info when my hard disk was disabled my pc doesn't even have uefi

Just a thought Maybe its the other way around. Maybe its nvidia providing the access through there cards and win10 doing something that causes the damage

Sent from my GT-N7105 using Tapatalk

 

That's really weird. When I f*cked up with my hard drives the laptop loaded a black screen telling me that no boot devices were found...

 

Yer i loaded default bios settings and that changed my hdds to raid mode and as i dont use raid that effectively disabled my hhds

Sent from my GT-N7105 using Tapatalk

 

I've done the exact opposite

 

Fakeraid doesn't disable hard drives. What it does do is cause BSODs when it fails to load the RAID driver. The BIOS still boots the Windows Loader just fine, its when the kernel takes over that it crashes. If you had a RAID0 array, it would be a different story.

As for your display issues, maybe the card is dying as a result of something Windows 10 did. AMD cards aren't exactly the most reliable cards around after all. It's almost like AMD baked an expiration into each one.

 

Like for me I prefere clean instalation

Update all time cause a lot of issues and incompatible

Sent from my SM-G928F using Tapatalk

 

Guys relax. Dell got us covered. lol

 

Yeah. No, they don't. They don't give a rat's ass because it doesn't affect them financially. We should change their way of thinking with a class action lawsuit vs MS, Nvidia, and Dell.

 

Perhaps not on a substantial scale, but having to replace a system because it's not working -- due to their own recommendations -- does involve financial implications.

 

I forgot that some of the newer M18s have warranties still. However many more, and older R1 and R2 systems, do not have any warranty left.

 

Valid point; perhaps it's a calculated risk on their part since they don't have a lot of active Alienware 18 warranties running and can afford a few system replacements, although they are also currently retailing the Alienware 18 with 970M/980M SLi option in the U.S. and Canada. As far as their official line goes, Windows 10 is not supported on either of the M18X (R1 and R2) models, but it is on the Alienware 18, and it would appear that the owners are being encouraged to switch over to the new operating system.

 

I still believe it's something different to just pure Win10 + Nvidia combo. Most likely user error somewhere..?
I mean, I'm still not 100% sure my system won't get bricked now with Prema vbios installed (although I gotta say I am liking it since I'm benching much higher and the framerates are not fluctuating) because I've had some weird stability issues with it.
I'd be inclined to say that a system straight from Dell would most likely not exhibit any of this bricky behaviour, but then flashing and modding and possibly certain monitoring software might f*ck it up. Therefore I wouldn't say that Dell is responsible for the bricks or should refrain from recommending Win10. Mine works fine and has done for the last 6 or so months and so it means that just purely Nvidia + Win10 can't be blamed.

 

Fair enough, but don't get me wrong on this count. My point wasn't to imply that Dell is responsible for actually causing this problem; it is clear from the endorsements to their official position that they don't recognise any risks in terms of upgrading the Alienware 18 to Windows 10, and even if such a risk exists, they are not directly responsible for the causation in question. Nevertheless, the onus is on them if something does go wrong on certain machines because they'll have to deal with the warranty claims that follow. Perhaps they genuinely don't see that happening, or perhaps -- behind the official line -- they have done a risk assessment of the matter and find that it won't be an issue for a majority of individuals who have this system under warranty.

 

@t456, could you add another EDID to your good edid archive please? It's for a 3D 120Hz Samsung SEC5044 - LTN173HT02-D02 (Dell part number DHCG2).

Spoiler: Samsung SEC5044 EDID

00 FF FF FF FF FF FF 00 4C A3 44 50 00 00 00 00 01 16 01 04 95 26 15 78 02 A0 55 8D 51 5A 96 2A 1C 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 5F 39 80 DC 70 38 40 40 30 20 35 00 7E D7 10 00 00 1B 00 00 00 0F 00 00 00 00 00 00 00 00 00 3C 96 10 FE 00 00 00 00 FE 00 47 4E 33 36 54 80 31 37 33 48 54 0A 20 00 00 00 00 00 00 41 21 9E 00 00 00 00 02 01 0A 20 20 01 D1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I am happy to report that after months of testing in Optimus, my LG screen was never bricked again without Precision X installed (also no Windows updates, just basic Windows 8.1 Pro with update 1 iso image). I switched to dedicated and tested it for about 2 weeks successfully with no bricks too. 2 days ago upgraded 1080p LG to 120Hz Samsung screeen and so far so good.

 

Thanks for the edid, but it's already in the archive as ' SEC5044_eDP_dd_2012.bin'. Have updated the ' pnp id - panel nrs.txt' to reflect the specific panel nr. though.

How did you extract that edid, btw? It claims to have an extension block (there's a '01' before the final 'D1' checksum), but the rest is all zeroes. Checked the existing 256-byte SEC5044 and this particular block contains the 100, 110 and 120 Hz timings, so it's fairly important to have these present with this specific model.

To all; this is also something to check before flashing. Using write-edid.sh on a 256-byte edid will work fine and nothing may seem amiss, but that would leave the second 128-byte block as is. If that hasn't been corrupted then all is still good, but otherwise you'd loose part of that information. So ... just to be sure, use the write-edid-256.sh for those panels ('X' in the list):

archive correct edids, v11.7z

Spoiler: pnp id - panel nrs

Code:

pnp id  notes   interf  panel nr.      edid eeprom
------- -----   ------  -------------  -------------------
AUO10ED !       LVDS    B156HW01 V0
AUO12ED         eDP     B156HAN01.2
AUO149D !       LVDS    B173HW01 V4
AUO159D         LVDS    B173HW01 V5
AUO219D !       LVDS    B173HW02 V1
CMO1719         LVDS    N173O6-L02
CMO1720 !       LVDS    N173HGE-L11
LGD01CA         LVDS    LP173WD1-TLA1
LGD0226         LVDS    LP173WD1-TLC2
LGD0285         LVDS    LP173WF1-TLC1
LGD0289         LVDS    LP173WD1-TLA3
LGD02C5 X       eDP     LP173WF2-TPA1
LGD02DA !       LVDS    LP173WF1-TLB3
LGD02FC C       LVDS    LP173WF3-SLB2
LGD0343         LVDS    LP173WF1-TLB5
LGD037E         LVDS    LP156WF4-SLB5
LGD0391         LVDS    LP173WD1-TLE1
LGD03FB         LVDS    LP173WF1-TL**
LGD0469 E       eDP     LP173WF4-SPF1
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 !?AWX   eDP     LTN173HT01-301  Winbond 25X20BLNIG
SEC5044 !?AWX   eDP     LTN173HT02-D**  Winbond 25X20BLNIG
SEC5044 !AX     eDP     LTN173HT02-D02  "" ?
SEC5044 AX      eDP     LTN173HT02-P01  "" ?
SEC5044 AX      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
W  = write-protect possible
X  = 256-byte edid; use write-edid-256.sh instead of write-edid.sh

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

 

I used MonInfo, will try using Linux now.

Spoiler: Edid extracted in Linux

00 ff ff ff ff ff ff 00 4c a3 44 50 00 00 00 00
01 16 01 04 95 26 15 78 02 a0 55 8d 51 5a 96 2a
1c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 5f 39 80 dc 70 38 40 40 30 20
35 00 7e d7 10 00 00 1b 00 00 00 0f 00 00 00 00
00 00 00 00 00 3c 96 10 fe 00 00 00 00 fe 00 47
4e 33 36 54 80 31 37 33 48 54 0a 20 00 00 00 00
00 00 41 21 9e 00 00 00 00 02 01 0a 20 20 01 d1
02 01 04 00 f2 5c 80 a0 70 38 40 40 30 20 35 00
7e d7 10 00 00 1b 3d 66 80 a0 70 38 40 40 30 20
35 00 7e d7 10 00 00 1b 89 6f 80 a0 70 38 40 40
30 20 35 00 7e d7 10 00 00 1b 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 29

 

Hi All,

Back on the Alienware scene again but this time I have an m17x r4 with a 970m, I previosuly had an m18x r2 780m sli using Mr. fox's 345.20 and that system did touch windows 10 for an hour or so and then I stumbled on the thread about winshite killing Alienware's (can imagine my face) but I'd say 4 months in and that m18x is still going.. just thought I'd cheer some people up that it's not all necessarily doom and gloom.

Anyway.. this 970m will I be better protected in optimus mode? I just got the laptop today and when I used FN F7 to go from dedicated to optimus I got 8 beeps. Since then I had to remove 970m put BIOS from Legacy to UEFI re install 970m then I installed Windows 8.1 but this is now in dedicated mode.. scared to change to optimus in case I get those 8 beeps again lol.. The joys of Alienwares

 

No kidding. I won't ever be buying an Alienware, or Dell, again.

 

This is odd. Windows works fine. EFI works fine. Moninfo shows me a registry entry for my LCD that does indeed pass on the EDID checker... But every linux distro I try throws up three empty EDIDs before the splash comes up and then it freezes when it would hand off to the desktop. Let me see if this custom Lubuntu distro @t456 made will boot.

 

Nope. No dice.



Sorry the pic is so bad. It flies by too fast.

Curious that my machine works otherwise though?

Edit: So that's interesting. I'm running Mint 17.3 right now with full nVidia hardware acceleration (albeit on one GPU) and everything. For some reason, Ubuntu and its derivatives are messed up but not Mint. Mint just needed --nomodeset added to GRUB and it works perfectly.

 

Well giving windows 10 another run on my M18Xr2. So far no problems. Finally sorted out the driver issues ive been having the last while as well. Only thing I've noticed is while the computers booting the screen flickers during the late part of the boot sequence just before the login screen shows up. Otherwise no problems so far tho I'll be watching it like a hawk.

 

The flicker happens on mine too. I don't think it's anything to worry about, its the hand off from the Windows Boot Manager to the OS.

 

Might be right about that. Noticed it doing the same thing on a tablet with win10 on it too. Doesnt happen on cold boot and seems settled now. Right now its working extremely smoothly only thing annoyin me is occasional throttling in certain areas on ffxiv. Dunno what causes it because while it was regularly doing it initially I found that the gpu load was 90%+ with uncapped fps and it would throttle quite a bit but the minute i capped it at 60fps it halved and it nearly atopped entirely. Stays stable now in most areas but when it throttles in certain parts i see pwr sli on gpuz but the gpu load is 45ish. Dunno if the card itself is throttling or the game sends a sudden gpu spike that triggers a throttle for about 5 seconds or so most times it happens. This happens on the 359.12 drivers but doesnt happen on the 350.12 drivers under the same conditions. Other games dont seem to trigger it tho further testing is needed. Dual 980m cards as well.

 

Pwr, SLI generally means one of your cards is weaker and drawing too much power and the SLI link slows down to keep the clocks synced between the two cards. Stock 980Ms will hit the power limit when they have heavy AA or DSR thrown at them.

 

Nice to know. Dunno what nvidia changed between 350.12 and 359.12 that triggers this its not happening with the former. Thinking of giving premas clevo 980m mod a go to see if it fixes the issue since he i.d. my stock bios as those from a clevo notebook but im extremely cautious about flashing them incase i brick it x.x

 

Nvidia makes performance optimizations that increase power draw. I understand being apprehensive about flashing the cards. Bricks are pretty rare. I mean we are talking about a process that takes about 30 seconds per card. As long as nothing goes wrong in that 30 seconds, brick risk is minimal. Prema removes the power limit entirely but if downgrading your drivers worked, it may not be a risk worth taking right now, only you can work that out. Honestly nVidia hasn't made a decent driver since 347.88... I'm running 361.43 right now and it's still not totally stable, I'm just too lazy to roll back. Plus since I'm running Windows 10, I haven't actually tested the various drivers that I used on 8.1

 

I'd be using 350.12 if they worked on windows 10 but the earliest is 352.84 and the initial launch build of win 10 + them was twitchy at best. Been using win 8.1 and 350.12 for ages but decided to do an OS wipe and try win 10 again with the newer update. Not touching any overclocking stuff since I know precision x is a lcd killer now. All i got on it is my games, antivirus and spybot and antibeacon, the drivers that work from 8.1 along with the ones for win 10 that installed and the 359.12 drivers. Initially twichy and the osd was sluggish to install but for now seems perfectly stable bar that issue with xiv.

Edit: Waitin on nvidia to release a new driver since 361.60 and its predecessor cause a BSOD with the 980m according to mrfox.

 

I happened to have GPUZ up for this and the 2nd card seems to be a lil weaker on voltage its showing 1.0370 while the primary is showing 1.0680. Switched from DX11 to DX9 as well and so far nothing on perfcap at all even with DX9 settings maxed out and no FPS cap im only getting 50~60 GPU load on FFXIV.

One other thing im noticing now is when i start up the computer from cold boot its freezing and I gotta power it off and on again :/. Dunno whats causing it so I'm disabling the fast boot option under the power settings to make the computer do a complete boot when I start it up. Was doing that before and eventually caused a OS corruption on windows 8.1 :/

 

Sounds like the GPU is doing a lot of tessellation in DX11 mode which is causing the power limit issue. Your secondary card is actually better silicon than your primary based on the voltage it's using. It might be worth trying the mod.

I turn off hibernation entirely - administrative command prompt - powercfg -h off

Seems to fix a lot of problems.

 

Looking now again at the voltages where I can typically trigger this with the FPS cap off and yeah the 2nd card seems to be slacking significantly the 2nd card seems to drop to about 1.01ish volts while the main is up around 1.04~06. With the FPS cap at 60 on im showing 1.0680 on the primary and 1.0370 on the secondary. Dunno why the 2nd card seems to draw less power overall but that seems to explain a good deal why I'm getting throttling.

 

Lower voltage means you have higher quality silicon. It's actually a good thing. The throttle is inevitable with the stock vbios when the cards get pushed unfortunately.

 

Tried Prema's vbios clevo mod. Doesnt seem to solve the issue tho. Only difference I see is with the modified vBios the voltage on the 2nd card remains steady at 1.0620v and the primarys running at 1.0680v. When the throttling occurs the primary drops to the same voltage as the 2nd. FPS drops to around 45 which is annoying. Only thing I can assume is its something to do with the driver itself and no amount of modifying is gonna help since I cant find the root cause of it in the 1st place. One thing I do know is it seems to occur in the exact same places (eg. Start of Pharos Sirius, Area before the 1st boss in arboritum)
.

As for the windows 10 system on the m18x it seems to be fine. Just seems to be that driver issue above that I cant figure out whats causing it other than thinking its something nvidia broke in their driver, Latest drivers seem to be FUBAR on the 9xx series as well so.....

 

@Mr. Fox ,etc.,

My Panther only has a 60 Hz screen the 90% NTSC. I have bricked the screen before using EVGA Precision X, on windows 7. I believe it corrupts the files your talking about flashing. It was when I had the RAM OCed- maxed out and then tried to OC the k5000m's with EVGA, and then i mistakenly clicked launch at start up tab, then tried to OC the crap out of them that is when it bricked. Then I did a blind restore to default from Blank but active BIOS screen.

If you recall I was talking about restoring BIOS settings in the dark. Anyways I wanted people to know that its not just Windows 10 (which I have not installed on the Panther as of yet). I am not sure how this happens, but the signs of the impending screen brick with EVGA precision X is green horizontal trailers/tares when OCing the GPU's. You just have to remember the key sequence to restore BIOS to default. That is how I did it anyway. And DO NOT CLICK launch at start up until you have firmly tested your OC. Noting there are no screen tares or shuttering. I still use EVGA presicion X, I think it is the best one and has the most control. That is it has enough programming to actually push my cards PAST their respective limits....thus corrupting them......not for the average user IMHO. It may be a very good idea to write down your respective startup to BIOS restore to default key sequence before using it. In hind sight that is what I would do. This problem may be more prolific in the 120Hz screens, but I have no first hand knowledge of that.

 

does cutting the LVDS wires make the system windows 10 proof,
i have a m18x R2
windows 8.1 in pure uefi,
970m PEG mode
Samsung 184HT (SEC5448)

(NO EVGA presision x and Never had it)

 

hello,
i have basically read though over 150 pages on this whole windows 10 shabam, and i have yet to understand exactly how this is all playing out.

but back to the more important stuff,

i have a
m18x R2
windows 8.1 in pure uefi,
970m PEG mode
Samsung 184HT (SEC5448)

(NO EVGA presision x and Never had it)

my question is, has there been a solution to all this other then just to avoid win 10,
does cutting the LVDS wires solve the problem on my monitor model, and if so what are the cons

is it safe to clean install windows 10 given you dont have EVGA PX?

 

It is safe to install Windows 10 as long as you don't use Precision X for now. NVidia Inspector has not had a brick report.

 

Cutting certain LVDS cable wires doesn't prevent screen bricking - Mr. Fox, I, and a couple of others that I can't seem to recall atm (sorry!!!) verified that this doesn't help.

For the moment, keeping PrecisionX forever off of your system should be enough (but there have been a few reports to the contrary).

 

The result depends on which edid wires you're going to cut:

Spoiler: SEC5448 (LTN184HT02-S01) - LVDS edid pins

Mr. Fox bravely cut the ' LVDS Self Test Enable' on the theory that that might enable hardware write-protect. This, unfortunately, was not the case and it only disabled the Dell pre-boot lcd test patterns. Which, btw, is harmless, but doesn't help us. Cutting any of the other three will prevent edid corruption simply because there's no longer an edid 'present'. Then again, without lcd-specific parameters the gpu will not know how to drive the lcd (refresh rate, number of pixels and colour space), so that doesn't solve anything either; black screen.

Furthermore, it is the inherent to I2C that it is bi-directional; a single pin (DATA EEDID) suffices for both read and write operations, so we cannot simply cut the 'write' wire, since that would disable the 'read' function also.

However, you can write-protect the edid eeprom itself, but only if its write-protect pin has the final say. This is not always the case; some need both the wp-pin and a software bit set before write-protect is active. For example, the CMN1735 (N173HGE-E11) can be write-protected by merely bridging (shorting, really) the WP and voltage pin, preferably with a resistor in-between:

Spoiler: CMN1735 - N173HGE-E11 - write-protect

The SEC5044 needed a software bit, too, and we never found out which bit. Still, the i2cset tool included in the linux image (write-edid depends on this) can set that bit to wp = on. But you'd need to know the bit and that takes a bit of trial-and-error. You could use a harmless edid mod to test this; if the edid changes then no harm is done, and if it fails then you've found the address of the wp-bit. The pin bridge/short mod has to precede this test, of course.

Don't have a SEC5448 (LTN184HT02-S01), so don't know what's what with this model, but upload some good photos of its pcb and we'll know soon enough.

 

I'm sorry but the sad truth is that there is no true fix as long as nVidia is giving drivers and third party software low level access, even with EFI (and obviously without it too).

 

Too lazy to dig my thread about this but I'm happy to report that my screen was back and functional again. Prema,
aarpcard, Mr. Fox from Techinferno Ethrem and especially t456 thanks for sharing your knowledge with us. I was always hesitant to try the linux image flashing idea but after an hour of doing work my screen was able to obtain the correct EDID for my panel.

The files, tools and bookmarks inside the image are really organized and instructions were made with great clarity. I found my EDID on bus 1, address 50 x-referenced with the online hex edid checker and indeed i got the corrupt edid. Rewrote the correct one with the AUO file, after one restart and a brief ms-dos terminal window my screen was up and running.

You guys rock. Saved my system from costly RMA's.

 

I can second this. As of this time I've had windows 10 installed on my M18Xr2 with the latest drivers available for about a month now. Apart from the occasional hiccup requiring a restart or the odd driver requiring a manual disable and reenable the odd time its working well. Managed to find and isolate the problem I was having with the throttling as well on my 980M's with FFXIV (HBAO enabled + uncapped refresh rate seemed to cause P1/0 tripping) and so far all is good.

Also had to disable the hyboot because it would cause freezing now and again for some reason as well.