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

I have two others but I pretty sure they have nothing to do with this as they are in sealed bags

 

can't you plug them in to see if they beep?

 

Also ran windows 10 for a little over a month considering I was in the insider preview. Nothing happened to my display nor any issues encountered with the OS as a whole. Actually thinking of going back to 10 but I don't know if we are lucky or if there's more to it than meets the eyes.

 

Well, the tech preview wasn't the problem. Retail Windows 10 + ANY Windows 10 specific Nvidia drivers is where fit hits the shan.

Your call - if you have a warranty and don't care if you are out of a laptop while it is repaired then go for it. If that isn't the case you'd be certifiable if you did.

 

I can, but I'll have to put it on my "To Do" list.

Both my workbench's are full of older alienware laptops right now, I don't have any AW17's "open"

 

i wonder if having the stock EDID like on my panel will still be screwed?

 

Sorry if it was mentioned before but the thread became quite huge and couldn't find that answer, how to know if the EDID of the monitor isn't corrupt ?

If it simply is working does this mean that it ain't or it could be corrupt but still working and exhibiting strange behavior ?

EDIT: I linked my EDID extract which seems to be identical to a one that was uploaded before in the thread and is supposedly ok. Can anyone give me feedback ? I want to know if I really have a problem with my motherboard or if the screen is dying

EDIT-02: DELL technician came, changed the mobo and screen won't work and we concluded that it is a screen problem.

@Mr. Fox 120Hz Samsung SEC5044 is one of the affected screens even with very old W10 drivers. Please add it to the list of affected screens

 

Does selecting windows 8.1 in the OS drop down menu mean that the driver is for windows 8.1 only? Cause I made sure to do that before downloading driver 355.82. Anyways, I am very fortunate nothing bad happened to my 18 during my time using windows 10.

 

I just remembered something with my system. Early on with it set at 120hz it would go black. This was caused by early drivers and having the backlight at anything other than 100%. Anyone without the beeps and a black or blank screen try getting the backlight adjusted back to 100%. It may not be a fix but it is free to try.

 

this with win 10?

 

Yup and drivers as old as 353.30

 

sigh!

 

Don't know, trigger could be one of the driver's options. As long as these remain inactive it should be fine.

No, don't have an AW system. Would be nice, though; easier testing.

CSM could have a different name; it often takes a bit of thought as to what the bios's writer may have thought the bios's user would think to be an intelligible description ... (if that made sense ). In other words; second-guessing other people's guesses ( more of that ).

Now for something funny from MS's UEFI Summerfest (honest!):

Spoiler: Many new experiences ...

Apart from the 'small issues'; have a deeply-rooted aversion to the the kind of thought that is behind those three words in green. Translated; Form Over Function. Those 'seams' ARE - STILL - THERE! By hiding the process you hide the technology, thereby both complicating problem-solving and, much worse, undervalue the true complexity of the device. The Apple-mindset, in short.

Shouldn't matter with pure UEFI, but would turn it off with any other boot mode.

Fast Boot is a form of hibernation, one that leaves hardware enumeration intact (devices attached and drivers active). This saves time because mapping and driver loading has already been done and, presumably, hasn't changed in the interim. That's a big 'if', hence the recommendations. Frankly, whoever thought this to be ' a good idea' should be sent the accumulated bill. Also; startup scripts run only once.

See Valid Checksum.

It could be corrupt and not even behave any differently. Not all changes are significant; Daniel1983's edid had two unimportant changes and you'd never notice these unless you'd look for them (checksum). Open question is still whether an AW can post with a broken checksum, but so far there's hasn't been a single corrupt edid that didn't came from a bricked system. However, n=2, so ... we need more broken edids to be sure.

It's ok and identical. Thing is; it's registry-export, not a live copy of the current edid in the panel. To do that you might try PowerStrip:

Spoiler: PowerStrip - read edid directly from eeprom

There is a risk associated with that ... Also, it might not work as long as there's a graphics driver present, think they're hugging the control bus for themselves. Will try uninstalling them later and re-run the export.

Is on the list already, only unknown which particular one. Can you make some photos of the pcb on the back?

Will re-iterate: safest bet is 352.xx or older. This dis-classifies 10, but not 8.1. Be aware that even 355.83 on 8.1 is NOT safe:

Thank @mariussx for that; excellent work (and brave, to boot) .

 

so should i go back to 353.38/353.49?

edit: might as well revert when i get home though this guy is using win 10.

 

I don't know why people post Youtube vids like that, and I don't know who could bother to sit through them - someone talking at 2mph taking forever to get to the point - reading is so much better - skim it & take it all in quickly! But, what is this 'forced system parity' that is mentioned with the 353.82 driver - (it's working fine on my system)? (I couldn't bare to listen to more than 2 mins of the video - it's 20mins long!)

 

I get ya! i somehow managed to gather as much patience i could to sit through the 20 mins of just incoherent rambling without any substantial, especially when there's no proof to their claims. i haven't seen any issues with 355.82 on 8.1....though others stay that 355.83 is not safe. getting confused as to what's ok to use

is 355.82 working OK for you Robbo?

 

Yep, 355.82 working just as good as the previous drivers for my system, same scores, although Combined Test on 3DMark11 increased by 100 points or about 2%. It might have improved performance on Arkham Knight too, but I've not tested older drivers on the newly patched (a few days ago) Arkham Knight. Haha, you must have lots & lots of patience to get through that Youtube vid!

 

same for me so far. had them installed for nearly a week already for 8.1 with nothing to speak of.

 

I will try to take a photo tomorrow of the panel DELL guy removes ... I hope he lets me after the huge fight I will have with him because for some reason after he changed the motherboard he killed all my FXlighting, power button light and status LEDs. Damn you Nvidia, DELL & Windows for giving me this horrid experience.

 

LOL at Alienware!

I made a tweet about me making Clevo/Sager my next laptop and that I was done with Alienware. Funny thing is that Sager favourited that tweet so LOL

 

Alienware is going down the drain bud. Might get Sager and clevo afterwards (will still get AW though cause I actually like them). As for the driver, your 980m should be fine cause supposedly Nvidia drivers are mainly targeting Kepler and older GPUs and "affecting" their performance.This guy is just rambling on. I have yet to come across a single issue in either MGSV or mad max (yes I own both ). As for the "driver holding back the Kepler GPUs" goes, this **** has been going on for so long, guess what I have a Kepler card and no single performance issue to report. These guys I tell ya

 

Thanks a lot @t456 , so do you still recommend me to turn off "launch csm". Will try to look for it in my BIOS, if I don't find anything, will probably just leave things as they are. As for the driver on win8.1, I know a couple of guys that are supposedly running win 10 with the latest driver and no issues so far. Same rig. Would you reckon this issue to be random as from what I gathered, some are getting major issues while others have yet to experience a single hiccup.

 

Excellent photography! Nice. Really, really useful!

Sad news, though; both are eDP. So, whichever was bricked, this is the situation with the SEC5044:

Spoiler: SEC5044, LTN173HT0*-***

Code:

PnP id  notes   interf  panel nr.
------- -----   ------  -------------
SEC5044 !?A     eDP     LTN173HT01-301
SEC5044 !?A     eDP     LTN173HT02-D**
SEC5044 A       eDP     LTN173HT02-P01
SEC5044 A       eDP     LTN173HT02-T01
-----------------------------------------------------------------------------------------------------
!? = bricked, but unknown which one
*  = unknown part id
A = highly suspect: multiple variants exist, perhaps the others are safe ...

The 301 and D** are quite rare compared to the P01 and T01. Yet there's been no mention of either of those having failed (in fact, your Dxx/301 is the single example). The Dxx and 301 seem identical as far as we're interested in, so consider everything 'Dxx' to apply to the 301 as well.

Now, thanks to the high-resolution, we can make out the edid's eeprom (Winbond 25X20BLNIG):

Spoiler: SEC5044, LTN173HT02-Dxx, eeprom location

This makes things easy; using the spec. sheet we can conduct some research:

Spoiler: Winbond 25X20BLNIG as implemented on the LTN173HT02-Dxx

Analysis:
1.) The write-protect pin is floating. That's a bit like Schrödinger's cat; it's neither on nor off. It's also susceptible to electrical noise, so a poor design choice here.
2.) The WP is not an Überpin; the SRP bit (in non-edid memory) has the final say; 0 = WP-off and 1 = WP-on. For WP-on to be effective, the WP-pin has to be low. Thus; short to ground. This is the opposite of the Atmel AT24C02 example, which needed voltage to enable write-protect. Also, the Atmel pin was a ' The-One-Ring' type of deal (no software override bit).
3.) The remaining question; is the SRP bit set to 0 or 1?

Winbond 25X20BLNIG write-protect combinations:



So if we want write-protect, then SRP has to be set to 1. This specific eeprom uses SPI Flash (just like Clevo bios eeproms), but not sure how to read/write to that thing without direct access to the chip (programmer). Anyone knows? Regardless, the WP-pin has to be shorted to ground (pin #4, to its right). No need to cut anything here; it's already disconnected.

Question of the Day:

• Do the other three known panels have their eeprom wired incorrectly as well?

My recommendations would be, in order of preference:

1. Revert to 7 (or 8.1) and stick with driver version 352.86.
2. Revert to 7 (or 8.1) and stick with driver version 352.86.
3. Revert to 7 (or 8.1) and stick with driver version 352.86.
4. Revert to 7 (or 8.1) and stick with driver version 352.86.
5. Revert to 7 (or 8.1) and stick with driver version 352.86.
6. Revert to 7 (or 8.1) and stick with driver version 352.86.
7. Revert to 7 (or 8.1) and stick with driver version 352.86.
8. Revert to 7 (or 8.1) and stick with driver version 352.86.
9. Revert to 7 (or 8.1) and stick with driver version 352.86.
10. Leave bios settings as they are.

 

so if there's no resistor it means it's write protected?

 

No, there's a solder pad right after the pin. Think of that like a break in a wire. A resistor ( even 0Ω) may or may not be present there, but if there isn't any then the wire is cut; the pin is 'floating' (an open circuit). This effectively renders the pin worse than useless, because its function is now unpredictable (due to EMI).

You have to see this in a case-by-case basis; not all eeproms are alike and, even if they were alike, their specific implementation changes the way it operates.

 

in other words no way to be sure...great! i've reverted to the stock settings so all the settings are back to normal.

EDIT: for the LOLz

 

Hey @t456 do you believe a solution is possible or are we doomed?

 

To write-protect the edid eeprom; sure, that's possible. We know how the SEC5044 can be made bulletproof. As for the others; just a good photo would do, as long as the chip's markings can be read.

If it's too late; the displays can yet be fixed. Only you'd have to remove it from the laptop to gain access. Plus either a a hardware tool or, easier, any compatible system that will permit booting with a bricked display. As long as you can boot, you can write the edid (with software only; $0.00). It's no different from a bios brick.

The ultimate cause is the driver and that needs to be fixed as well. Nvidia claims to be working on it ... but, really, they have all resources at their disposal ... :

• Afflicted laptops (from their customers).
• Afflicted panels (from their customers).
• The source code for the display part of their driver.
• Intimate knowledge of exactly what they have changed with the new drivers.

A few test runs and they'd have it nailed in a day or two. A week, at most. You can't convince me they're that incompetent. Nvidia has a small town of employees, so pretty sure they have at least some intelligent people working for them. Unless they've re-delegated all of them to the legal division, that is ... But ' intelligent lawyer' is a contradictio in terminis anyway; even if they once may have had a spark, the mere act of reading law atrophies the brain, leaving only basal functions intact .

Anyway ... my guess would be that they've long found the culprit and that there'll be a new driver soon that has the line ' Fix for generic display instability' in its release notes and that'd be it. No admission, no mea culpa, no explanation, no compensation.

Just to be clear: nvidia cannot fix displays that are already bricked, even if they wanted to. That is up to you, warranty or someone else who can fix them.

 

Wholeheartedly agree with you.
Absolutely impossible for a large multi national company like ngreedia not to have pinpointed the cause by now, and I don't believe for a second they didn't already have some idea as to the cause when first reported, it's their speciality, they tell us how good they are constantly (And up until recently they have been just that)

Just a lot of ass covering from now on I think - Typical multinational.

Maybe this doesn't have any relevance - But then again, maybe it does.
Anyone remember the Movie "Fight Club"?
Remember what Edward Norton said about "insurance" and "compensation" and product "Recalls"
Something along the lines of the company does the maths.
If the cost of a recall is greater than the cost of compensation, then a recall will NOT be issued, even is people are dying (A bit extreme in our case, but you see the resemblance)
We're to small a bunch to take notice of, if the number of panels affect was hundreds or thousands instead of tens then we may have got some action from Micro$haft or NGreedia, as it stands if we want anything from them, I think we'll have to fend for ourselves

 

By "cannot fix" you mean they cannot do it remotely or through a driver update because it is too late, right? They "fixed" the bricked display I sent to them and it's working fine in their lab on another machine, but they need physical access to do that. Fixing the display will not fix the problem though. The EDID will just get re-bricked unless it gets cured by correcting or eliminating the errant or malicious code causing the writing process.

No status updates can be expected from NVIDIA at this point. They are collaborating with fellow engineering partners at Dell/Alienware and hopefully Micro$haft, and those communications are protected by their respective NDAs.

 

Exactly.

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

 

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

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

 

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

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

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

 

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

 

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

 

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

Anybody have any ideas to help him?

 

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

 

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

 

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

That would fit observations neatly:

Spoiler: off-topic digression

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

This is quite interesting:

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

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

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

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

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

Code:

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

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

Code:

AFUDOS.EXE BIOS_O.ROM /N

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

Code:

AFUDOS.EXE BIOS_E.ROM /O

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

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

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

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

Okaaaayyy ...

WTF???!

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

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

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

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

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

 

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

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

 

Not a tin-foil-hat person myself, far from it.

But if physical cmos clear doesn't clean this and the 1,818 bytes difference remains with the original bios, then yes; this is the very definition of a firmware rootkit:

The method it uses might be similar to LoJack's Absolute Persistence Technology. In hindsight ... it makes sense. What we're seeing here could be Windows 10's licensing method:

If it actually is just nvram, then any Windows 10 user who does a cmos reset would have to re-activate. Is this so?

If not, and 10 remains licensed, then the method they have used partitions-off part of the nvram for itself, making it hard-coded in the bios. This would make it part-and-parcel of the true bios, in other words; persistent code. That would be a very nasty rootkit. And dangerous as well; the method it uses could harm other parts of the bios as well, if improperly implemented. Then again, is it possible to properly inject persistent code in firmware?

Anyway, there's a few things to check first:

1. Pull cmos battery and read on first DOS boot (pre-OS)
2. Write bios and read
3. Pull cmos battery, de-solder bios and read in programmer
4. Write fresh bios with programmer
5. Read with programmer
6. Boot to DOS and read

If '1' works; fine, it's still evil, but only a minor evil. Worst scenario is if '4' fails, but '2' wouldn't be much better.

 

Wow, there may be more unethical wickedness to this Satanic piece of digital canine feces (Windows 10) than we had imagined.

 

Ah, that's very interesting, and the Licencing Method theory makes sense to explain the presence of the rootkit. I've been trying to follow discussions here, but does this relate directly to the EDID corruption, or is this a side discussion you're having?

 

Well this is the MonInfo dump from my brand new, but now corrupted AUO B173HW02 v.1 after the first restart under Win10.
I unfortunately only found this thread after I had replaced the screen and windows 10 bricked it for me a few minutes later..

I can only boot the system (AW17r1) in pure UEFI mode and if I try and load any display drivers the screen garbles and is unusable.
Booting under Legacy or UEFI with legacy rom results in the 8 Beeps of death.

My original screen is a LG LP173WF1 (TL)(B3) and it is also bricked, but worse than the AUO




Monitor
Model name............... LS13_LS18
Manufacturer............. ChangHong
Plug and Play ID......... CHD9021
Serial number............ 16777216
Manufacture date......... 2182, ISO week 47
Filter driver............ None
-------------------------
EDID revision............ 1.3
Input signal type........ Digital
Color bit depth.......... Undefined
Display type............. RGB color
Screen size.............. 600 x 340 mm (27.2 in)
Power management......... Not supported
Extension blocs.......... 1 (Unknown type)
-------------------------
DDC/CI................... n/a

Color characteristics
Default color space...... Non-sRGB
Display gamma............ 1.97
Red chromaticity......... Rx 0.640 - Ry 0.341
Green chromaticity....... Gx 0.286 - Gy 0.609
Blue chromaticity........ Bx 0.146 - By 0.068
White point (default).... Wx 0.284 - Wy 0.293
Additional descriptors... None

Timing characteristics
Horizontal scan range.... 24-80kHz
Vertical scan range...... 23-80Hz
Video bandwidth.......... 160MHz
CVT standard............. Not supported
GTF standard............. Not supported
Additional descriptors... None
Preferred timing......... Yes
Native/preferred timing.. 1280x720p at 60Hz (16:9)
Modeline............... "1280x720" 74.250 1280 1390 1430 1650 720 725 730 750 -hsync -vsync

Standard timings supported
640 x 480p at 60Hz - IBM VGA
800 x 600p at 60Hz - VESA
1024 x 768p at 60Hz - VESA
1280 x 1024p at 60Hz - VESA STD

Report information
Date generated........... 9/10/2015
Software revision........ 2.90.0.1000
Data source.............. File
Operating system......... 6.1.7601.2.Service Pack 1

Raw data
00,FF,FF,FF,FF,FF,FF,00,0D,04,21,90,00,00,00,01,2F,C0,01,03,80,3C,22,61,0A,D4,6C,A3,57,49,9C,25,
11,48,4B,21,08,00,81,80,01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,1D,00,72,51,D0,1E,20,6E,28,
55,00,C4,8E,21,00,00,18,00,00,00,FC,00,4C,53,31,33,5F,4C,53,31,38,0A,20,20,20,00,00,00,FD,00,17,
50,18,50,10,00,0A,20,20,20,20,20,20,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,18,01,F3

 

Interesting... it overwrote your EDID with a sample EDID??? I just found the exact same EDID in the program except the Data source says Sample...

 

Sorry just edited, looks like i coped the wrong bit from MonInfo

 

I was wondering.

Jeez... This is just a huge mess.

 

Both.

Don't think this would cause edid-corruption in itself. But what this shows is that MS can inject code into the bios (flashing) and make that change persistent. It's not a big step to consider that NVIDIA can do the same, only this time to change the vbios, which we now know is communicating with the edid eeprom. The I2C bus it uses is two-way; so if something can read, then it can also write, provided there is no hardware write-protect. Which is at least true for two of the SEC5044 panels (the 301 and Dxx).

Information we need:

• Vbios exports from systems with bricked displays.
• Good photos of the back of bricked displays (see @andrewsi2012 's excellent photography).

Most interested in that vbios; that could proof nvidia's culpability.

Fortunately, MonInfo doesn't have that capability. Actually ... that should be ' unfortunately'; it'd be so much easier to fix.

If you could boot in Legacy, then I could show you how to write the edid. Prepared tools to do so and they work fine, but not in pure uefi. Pretty certain they'll work in uefi too, only have to get around to making that image and testing it ... kinda want to get rid of the Secure Boots virus first, though ...

Spoiler: Secure Boots

 

I'll give it a go tomorrow using my only functional display to start they system in Legacy then attempt a hot-swap of a bricked display.

 

Out of curiosity, I'm currently using my AW18 perfectly fine on 10. However, it's running in pure uefi mode (secure boot is off I believe).

Now if I were to switch to legacy boot, would I get the 8 beeps as well?