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

bah! my board doesn't have the SW1 switch - raw end has been delivered.

i discovered that the tiny metal contacts on one of the ribbon cables (the one with the latch underneath the ODD bay, started to come off so i trimmed a bit to see what happens. will see if ebay has replacements.

EDIT: if your board doesn't have the SW1 can it be soldered back in?

 

@t456 thanks for all this mate, looks like you have put a ton of effort into it.

You can start a torrent if you like, but your upload is probably far enough along now that it's not worth it.

The instructions look pretty scary with all the warnings and references to irreparable damage on the i2c bus..

Code:

09    sudo i2cdump -r 0-127 6 0x50

result:
######################################
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 ff ff ff ff ff ff 00 4d 10 ff 13 00 00 00 00    ........M?.?....
10: 00 17 01 04 a5 1d 11 78 06 de 50 a3 54 4c 99 26    .??????x??P?TL?&
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 56 5e 00 a0 a0 a0 29 50 30 20    ??????V^.???)P0
40: 35 00 26 a5 10 00 00 18 00 00 00 10 00 00 00 00    5.&??..?...?....
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00    .............?..
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fc    ...............?
70: 00 4c 51 31 33 33 54 31 4a 57 30 32 0a 20 00 b0    .LQ133T1JW02? .?
######################################

In this part what will you see on a bricked screen? will all the hex be 00?

 

Tame answers from the Masters of Puppets:
Does 10 Write Code into a Motherboard Bios Chip for Future Activation?​

Spoiler: thread-krapper

The key is not embedded in the BIOS or anywhere else (nothing is written to your hardware at all). There is no key at all. Instead when you first activate Windows 10 it records the hardware signature (a collection of your PC's hardware device ID's compressed into a numerical identifier) in MS Activation servers as entitled to a free license for the life of the PC. The ability to change hardware without triggering reactivation is explained in the post above mine.

Later when you need to reactivate or if a Genuine check is done, the hardware signature is compared to confirm that the PC is licensed for Windows 10 Upgrade. Because many will use retail copies of Windows 7 or 8.1 to Upgrade to 10, and these licenses are entitled to migrate to other PC's, the Windows 10 Team decided that the Upgrade should likewise be able to change hardware if need be. This is a good explanation of how this is planned to be done: How to Use Your Free Windows 10 License After Changing Your PC’s Hardware . Only OEM copies of Windows are locked to the hardware first installed upon and cannot migrate.

They also decided that the Windows 7 or 8.1 license will not be affected by the Upgrade so that you can go back to the original OS whenever you want, as long as both are not being used at the same time. To uninstall one OS to restore the other its partition should be deleted. The best way to restore an OS is to use a System Image Backup. I hope this helps.

Stevie Vai -The Audience Is Listening​

 

Brother @Cass-Olé - Thanks for the link. Your efforts are appreciated. Those that replied are nothing more misinformed muppets that are repeating a whitewashed message. Micro$haft cannot openly admit what they are doing to hardware because the reaction to their unforgivable stealth actions would be too severe and expose them to litigation. Windows 10 is clearly doing something that causes permanent damage to motherboards. Of course, Micro$haft is never going to fess up to that because the whole concept is unconscionable and unethical. We have multiple machines that are living dead proof of Windows 10's cancer. The fact that some machines seem to be affected adversely and others do not suggests that their stealth tattooing mechanism is still an imperfect work in progress and when their secret mission has a glitch the consequences are tragic.

There is no other logical explanation for the affected machines buggering up multiple LCD panels despite having the system BIOS flashed more than once and going back to known good/flawless operating system and drivers. The only thing left to contribute to the problem after Windows 10 has been replaced by an earlier OS is the motherboard/BIOS and when nothing ever changed until Windows 10 was installed, where else are we going to pin the tail on the donkey? I had Windows 10 installed on my Samsung mSATA and my clean Windows 7 install was on a brand new Neutron GTX SSD that was replaced through RMA from Corsair and it had never been touched by Windows 10.

I'm starting to question NVIDIA's guilt in the matter and tending to believe that the only reason we haven't seen any affected AMD-powered systems yet is only because not all systems manifest problems and NVIDIA's market share, at least among the affected models, dramatically dwarfs the number running AMD GPUs. I'd venture a guess that it is like a 10:1 ratio in NVIDIA's favor. I'd be willing to bet that if I replaced my NVIDIA MXM cards with AMD MXM cards and installed display panel #5 that it would end up broken and unbootable like the first 4 LCDs. If someone wants to loan me a pair of 7970M cards and M18xR2 LCD to hook up to my Windows 10 cancer-metastasized motherboard to test that theory, send me a PM. I'd expect the same outcome now that Windows 10 has permanently hosed my system BIOS. Just don't expect me to pay for a replacement LCD when it ends up screwed up.

 

Thanks, can't try that out right now, but here:

1GB Linux with edid tools (regular boot) (edit: new link)

Yes, only too bad no 75Hz yet ... more effort is required.

Maybe when I get that thing to be smaller; the 1GB should be feasible ... weird thing is that these .img files don't compress ... at all ... ?

It's isn't that bad, actually. All tools, including PowerStrip (and HWiNFO), use the same type of queries to poll the devices. If they make a mistake with their code then you have a problem as well. It's only that with these tools you are the one that can make the mistakes ... don't do this with too much haste, that's all.

Actually, if a normal query causes problems then that really means the hardware manufacturer hasn't build in sufficient safety-measures. I2C in itself is fine, it just needs some thought concerning ' what-if' scenarios.

No, you'd see almost exactly what you're seeing there, except with a few changed bytes. You wouldn't know this without specifically looking for them. So run the export and drop the result (properly formatted) into the Web Based EDID Reader. Checksum should say ' Valid'. If it says that, then there's no need to overwrite the edid; there must be something else amiss then.

This is an example of what you'd paste into the Web Based EDID Reader box (so without the rows and column labels):

Code:

00 FF FF FF FF FF FF 00 4D 10 FF 13 00 00 00 00
00 17 01 04 A5 1D 11 78 06 DE 50 A3 54 4C 99 26
0F 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 56 5E 00 A0 A0 A0 29 50 30 20
35 00 26 A5 10 00 00 18 00 00 00 10 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FC
00 4C 51 31 33 33 54 31 4A 57 30 32 0A 20 00 B0

Green-highlighted is true; it generates a hash (a unique identifier), but this IS hardware-coded into the bios (red). Only, it's not done by Microsoft itself, they leave that to the bios vendor (laptop manufacturer).

 

Why is it only messing things up secondary to the installation of Windows 10? How do we know that Windows 10 is not writing something "extra" to the system BIOS/UEFI tables that, when not executed as gracefully as expected, is causing the problems that started with the introduction of Windows 10?

I replied in that thread. Let's see if they do anything sneaky with my post to avoid bad publicity.

 

@t456 - Some observations and assumptions from my tinkering with my M18xR1 (which is still functional with an unaffected display).

Observations:

• With the wire for pin #5 connected, my display panels are not writeable. I could not upload the EDID .bin file to the panel using PowerStrip and got an error message that the EEPROM is not accessible.
• EnTech softMCCS identifies the M18xR2 LCD as a Samsung SEC5448
• EnTech PowerStrip identifies the M18xR2 LCD as a Seiko-Epson SEC5448 with the same specs
• Hotswapping to a bad display from the M18xR2 the display works fine until reboot (then 8 beeps/no boot) and display does not work resuming from sleep state
• Hotswapping display between POST and prior to Windows loading the bad display works (POST completed) but all of the specifications from softMCCS and PowerStrip are "empty" and an "EDID EEPROM was not found" error message is returned
• The EDID EEPROM is found by the software tools when using a properly functioning LCD
• Hotswapping display after Windows logon softMCCS and PowerStrip report the same information as a good display, so the data seems to originate from a source other than the LCD EEPROM. With a bad LCD there is no "not found" error message except when attempting to read from the bad LCD panel's EDID.

My Noob Assumptions:

• The issue seems like it could be a problem with the system BIOS not being able to communicate with the affected display. If it can "handshake" with a good display POST will complete. If it cannot "handshake" the system halts with 8 beeps.
• If some Windows 10 installations have a random glitch where wrong data is written to the system BIOS, or data is written to a location where it should not be placed, this may be pushing the same corrupt information from the BIOS out to the display panel during POST, rendering the LCD "unbootable" (yet still functional after POST if a good display is used during POST). LVDS pin #5 is for a display "self test" feature. While it cannot be used for writing EDID information (at least not based on my testing with PowerStrip) the "self test" from the corrupted system BIOS that Windows 10 corrupted may be tripping some sort of failure flag in the LCD firmware. This would also be consistent with @mariussx being able to use an external programmer to temporarily restore functionality, only to have the corrupted system BIOS fail the self test and flag something in the EEPROM as having failed.
• If there is some sort of on/off toggle "switch" in the EEPROM, it might be the system BIOS self-test that "tells" the LCD it is no good and flips the switch off, but if the BIOS self-test passes it flips the switch on, which may explain why the affect display fails when moved to another system. The switch stays off in the EEPROM until an uncorrupted system BIOS flips it back on again by a successful "handshake" event.
• Severing the wire for pin #5 probably will not be beneficial to prevent corruption even with a good LCD and unaffected system BIOS because the self-test will most likely fail and cause the same 8-beep error code.
• The hard mod (leg #7 connected to leg #8) may still be a solution to keep an affected machine functional with a good display and block corruption. My assumption is that would prevent any changes occurring on the EEPROM regardless of what might be corrupted in the system BIOS caused by a random glitch in Windows 10.
• Having already blind crisis recovery flashed the BIOS twice and still having the issue resurface, if the hard mod mentioned in the bullet above is not successful at blocking EDID corruption, a motherboard and LCD panel replacement may be the only permanent solution.
• I have not attempted to program the EDID using edid-rw under Linux. If the hardware is not writeable in Windows using the LVDS cable, I am assuming it will not be writeable through the same LVDS cable under Linux because there is no channel to pass the data to the EEPROM.

Spoiler: Error Message with Bad Display

Spoiler: Difference in Reported Display Information (Good Display)

 

I downloaded both of these, made the flash drive work with that crazy Russian Grub4DosUSB tool then copied the 'disk' and 'multiboot' folders to the root of the USB drive
It boots but looks weird and there is only 2 options, one brings up a dos looking command prompt and I don't know how to use it and the other one shuts the computer off.

You could solder any kinda momentary switch in there, it doesn't have to be the proper one. I have just been shorting the solder blobs with some fine tweezers.

 

@Mr. Fox
What's the ETA on your programmer? Can't wait to hear the news on if you can write protect the display. Almost two months without a computer is killing me!! Lol

 

No information is available from the China Post tracking number other than "in transit" so I have no idea. Sometimes I receive things ordered from China in a week and other times it has taken several weeks. The tracking number seldom provides me with any expected delivery dates.

 

I call dibs on the first rapair

 

i hate china post. if you can always pay for a decent courier service.

 

If that LG screen is LP173WF1 TL B3 and you have it out of the laptop, could you take some photos of the screen pcb please?

 

Let's hope it works. Honestly, I think it's a shot in the dark because there is so much about the cause that we don't understand and without Micro$haft taking responsibility for the mess they have created and actively helping correct it, it's going to be a stroke of luck. If we get lucky it still won't actually be fixed, it will only be a hack to work around their screw-up. It's probably something that could be fixed easily if we knew exactly what they have done. It's obviously some sort of random glitch since it does not happen to every machine. I think the malfunction exists somewhere in the pre-POST LVDS self-test process due to Windows 10 sometimes/randomly corrupting the firmware that controls that process, but that's only a guess on my part. If Micro$lop had kept their filthy control freak mitts off of things they have no authority to to touch this problem probably would not exist.

It is what it is. I've tried paying for the better shipping from China Post a couple of times before and accomplished nothing except spending more money and getting nothing in return. China Post just sucks. But, so does Canada and US Postal Service (although not as bad). With FedEx/Purolator, UPS or DHL such poor service is not likely, but the cost can often be more than the product being shipped.

 

How do you do this to disable automatic updates completely? This has me worried now.. I know you posted this in this thread before but would appreciate if you could point me towards what to do again

 

No problem, bro... you should be worried and I think you'd be nuts not to be. Use Group Policy. See my screen shot in post #17 in the Windows 10 Tweak and Fixes thread. Most of the Group Policy tweaks I use are the same on W7/8/8.1 as what I did with W10. This will allow you to manually check for updates. There is a registry hack that completely destroys any and all Windows Update functionality, including manual updates, but that's overkill.

 

I buy from China all the time, postage is terrible (But at least it's cheap!!).
Items spend more time trying to leave China's domestic network than they do in transit between countries

Let's just hope it arrives - Full stop.
They are also notorious for loosing things

 

Sorry BJ, I seem to be a little slow on the uptake here.
Does this mean your've blown your M18xR2 LCD? That was the new one the other guy sent, right?
%&#% me, time for you to purchase a lottery ticket, your due for a change in luck
I may have another one for you, I'll check.
I think I also have a M18xR2 mobo with a faulty GPU slot, would the BIOS chip off that help you?
I also have a AW18 with two broken USB ports and a faulty LVDS connection, would the BIOS chip off that help too?

 

I don't know. I appreciate all you've already done and are offering to do. Let's wait and see what I can do with the programmer and doing the hard mod @t456 showed us. The LCD panels are actually not damaged (as far as I can tell) just corrupted firmware. If programming the EDID and then blocking any future changes using the hard mod bulletproofs the 8-beep problem that may ultimately be the best approach... hopefully, that will work. I am not going to install any more good display panels and run the risk of messing them up. If that hard mod doesn't work I am probably going to dismantle the machines and sell them off in pieces on eBay to help fund a desktop build or buy a Eurocom X7 Extreme with 6700K and 990M SLI. I'm sick of all of this nonsense and part of the reason I am hanging in there this far along in the process is to try to help others get past this mess. At a personal level, I was ready to part them out when display panel #3 got screwed up.

 

Understood.
There was some mention of BIOS corruption and re-writing.
If you need the chips to bypass this let me know, the mobo's are destined for the recycle bin anyway

 

Here you go, Hopefully usable I didn't want to pull off that plastic protection strip as its glued in lots of places.
Pictures of LG LP173WF1 TL B3 PCB http://s000.tinyupload.com/index.php?file_id=00214875440889057427

 

How much would my m18x be worth parted out? I'd hate to do it, but if this doesn't work then its pretty much perma broken and I can't sell it knowing it will break if I fix it again.
The only other option i see is Steam OS. Maybe that will solve the corruption issues. I'm sure Nvidia will be releasing fresh new drivers and Microshaft won't be able to open the door for the EDID intrusion.

Edit: Steam OS might not be a viable option because almost every game runs slower then it's Microshaft counterpart.

 

This is normal(-ish). They use different lookup tables and, strangely, the Seiko Epson is 'correct' ... At least, in the sense that that is the full name for PnP id 'SEC' in the PnP/ACPI registry:

Spoiler: PnP manufacturer ids of the affected panels

So with all four affected panel manufacturer ids there's something amiss. Has gone fine for years and years regardless, so ... maybe it's not an issue. Except, that is, if you start using those ids for something more significant than mere ' pnp -> name'-matching. Well ... bit of a long shot, that.

My guess: the edid corruption of this panel is in the start header (at minimum).

It would explain all five findings. Remember the bit where ' I2C needs guesstimation'? This is no different for the EnTech tools than it is for the linux-based tools; 'query -> guess -> re-query -> check', etcetera. One way to 'know' with almost (but not perfect) certainty you've actually found the edid location is with the mandated start header:

Code:

00 FF FF FF FF FF FF 00

So you code this sequence of events:

Code:

list all devices
note bus nr. of the device 'panel'
check all addresses of bus nr. 'panel' for data present
note all addresses where 'data = yes'
check all 'data = yes' addresses for '00 FF FF FF FF FF FF 00'
when '00 FF FF FF FF FF FF 00' found -> read edid and calculate checksum
----> if checksum is ok -> proceed
----> if checksum is false -> halt boot (error: edid corrupt)
when '00 FF FF FF FF FF FF 00' not found -> display not found

Or an analogy, if you like, themed ' what computers suck at'.

Mission: deliver package to ...

• Yiannis Kouros
• Denver
• Main street
• ?

Code:

Code:

list all streets in Denver
note location of street 'Main street'
goto 'Main street' and check all houses for occupancy
note all addresses where 'occupancy = yes'
check all 'occupancy = yes' addresses for name plaque 'Yiannis Kouros'
when name plaque 'Yiannis Kouros' found -> ask for id card
----> if id card ok -> deliver package
----> if id card false -> do not deliver package (error: not 'Yiannis Kouros')
when 'Yiannis Kouros' not found -> addressee not found

Now ... let's say an 'N' dropped out, so the plaque reads 'Yianis Kouros'.
Result -> 'addressee not found'.

Most computer code expects absolute truths, whereas, fortunately, not all people think in such absolutes (far too many do, of course, but still ...). WE can still deliver that package and with the linux tools WE can still find that edid, even though the start header may not be a perfect match (the linux i2c tools read all i2c data, not just edids). Recall that I2C = guesswork; we do not know, for a fact, the actual address with absolute certainty. It is often presumed to be nr. 50, but that isn't chiselled in stone and if you take the ' mostly true -> always true' route then bad things happen (EnTech wouldn't do that, fortunately). A package mis-delivered is one thing, but an eeprom mis-read/-written is no less likely, only with more serious consequences. Also remember that the payload (actual data) is completely and utterly unpredictable if you do not know WHERE to start reading. Anything goes if you don't, so to the computer it is just bananas, unless it id's it positively as an edid and begins reading from the 'start' header onward.

Download the edid archive and open a score of the .bin files in a hex editor ( HxD is nice) and you know what patterns and data to expect.

Will get back to this later.

 

' Crazy' sounds about right ...

Upload of the 30GB img is complete and post has an active link now. Also made a (slightly) compressed .7z at 16.8GB ... well ... it's a bit smaller, at least (will drop this as a torrent soon). Making a ~1GB version is not really a top-priority, tbh; this img works perfectly, even if it's a long download, so ... download two Blu-rays or something that will fix your display .

Thing is; would've used a smaller stick, but this 32GB is SLC (!) and crazy-fast, even under extended load. This saved a lot of time and won't suffer data-corruption, even with heavy (re)writes. If there's sufficient interest; might try making a dual boot ( with uefi) on a smaller disk. If it were just for the few ' still-bootable-with-hdmi' systems then probably not, but since the hot-swap proved successful ... perhaps there'll be more candidates willing to give it a go ...

Mostly interested in the vbios of a display-bricked system, but ... might be nice to check a non-cmos-resetted bios of a once-10 system as well. A look at a written SecureBoot section would be interesting; mine were just in pre-setup mode and that's how they'll stay .

In related vein, regarding the MS rootkit: haven't gotten an amen for the bios mod (to remove Secure Boot permanently), but doesn't matter anyway; can reprogram if necessary. So will go ahead and see if this thing can be purged ... don't like the 'call back' or 'unique id' mechanism there, even if dormant for the time being. But those are just questions of privacy/control and have no illusions in that area anyway . Much worse, to me, is the 'persistent nvram'-feature; kinda like that gone, most of all. With a cmos reset, I do expect an actual, honest-to-god, cmos reset. That means 100% factory defaults and not '99% defaults + 1% MS code (or hash)'.

 

This is the vBios from my gtx 860m that was running under windows 10 when it corrupted my new AUO screen.

Side note,
I have just installed win7 on the system that had windows 10 on it. I used the working display (AUO) to get the machine to boot into UEFI with legacy rom. Then Hot-swapped to the afflicted LG screen and proceeded to install Windows 7. Even after all the restarts required to install the drivers the screen is still working as normal. I am currently writing this with it running normally at 1080p.
Obviously the BIOS must remember what the screen is somewhere until you completely shut off the system and have to start again from a cold boot.

I can also put the machine to sleep and resume again with no problems.

This is what my LG display is reporting as still

Code:

Monitor
  Windows description...... Generic PnP Monitor
  Manufacturer............. AUO
  Plug and Play ID......... AUO219D
  Data string.............. P9JNK€B173HW0  [*CP437]
  Serial number............ n/a
  Manufacture date......... 2013, ISO week 0
  Filter driver............ Monitor
  -------------------------
  EDID revision............ 1.4
  Input signal type........ Digital
  Color bit depth.......... 6 bits per primary color
  Color encoding formats... RGB 4:4:4
  Screen size.............. 380 x 210 mm (17.1 in)
  Power management......... Not supported
  Extension blocs.......... None
  -------------------------
  DDC/CI................... n/a

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

Timing characteristics
  Range limits............. Not available
  GTF standard............. Not supported
  Additional descriptors... None
  Preferred timing......... Yes
  Native/preferred timing.. 1920x1080p at 60Hz (16:9)
    Modeline............... "1920x1080" 140.500 1920 1968 2068 2104 1080 1083 1089 1112 +hsync -vsync
  Detailed timing #1....... 1920x1080p at 60Hz (16:9)
    Modeline............... "1920x1080" 140.500 1920 1968 2068 2104 1080 1083 1089 1112 +hsync -vsync

Standard timings supported

Report information
  Date generated........... 13/09/2015
  Software revision........ 2.90.0.1000
  Data source.............. Registry-Active
  Operating system......... 6.1.7601.2.Service Pack 1

Raw data
  00,FF,FF,FF,FF,FF,FF,00,06,AF,9D,21,00,00,00,00,00,17,01,04,90,26,15,78,02,C8,95,9E,57,54,92,26,
  0F,50,54,00,00,00,01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,01,E2,36,80,B8,70,38,20,40,30,64,
  36,00,7D,D6,10,00,00,1A,E2,36,80,B8,70,38,20,40,30,64,36,00,7D,D6,10,00,00,1A,00,00,00,FE,00,50,
  39,4A,4E,4B,80,42,31,37,33,48,57,30,00,00,00,00,00,00,41,02,96,01,11,00,00,02,01,0A,20,20,00,05

 

Looks weird. Base clock is 797 MHz while it should be 954 MHz if bios is unmodified


It's also old vBIOS. Newest version is different but that doesn't matter if gpu is working properly.
This is newest unmodified vBIOS that new 880Ms have:


@Up oh jezz, man...

 

Here's how the EDID compares between affected and unaffected display.

 

Thank you very much, syphear I will add some more pics from my screen.

U2 chip:

U3 chip:


@t456, is this the cable to disconnect in an attempt to write protect the screen eeprom? It does not seem connected anywhere on the screen pcb. I did not put the laptop back together, can take more pics if required.

Strange, my bad EDID looks almost the same as proper one, while yours seem to have no info at all.

 

Think you've just missed it:

Spoiler: B173HW02 V0 - edid

Either that or it's inside the controller IC (AUO part nr.), in which case wp-hack will be next-to impossible; specification sheets of these are pretty much non-existent. This their business after all and they don't tend to share that information. Generic eeproms are different; everyone uses those and for all kinds of purposes.

Thanks, 'U1' too, please . And you can read+google the markings now, so ... . Just let me know what pdf's you've found. Don't mind searching myself, but then it'll have to wait a day or two. If none of them turn up anything then it's either on the other side of the pcb or, indeed, embedded in the large 'LG Display' chip. If the latter then we'll have the ' spec-sheet desert' problem.

You're right, it's disconnected, but cutting the cable itself would be useless then. Seems more likely the pin-mod is a necessity, at this junction.

Thanks, will check later.

Yes, or an extended boot. Don't turn that thing off ! Maybe try tried the extract-edid tools by EnTech? Funny how the LG is running on AUO timings: their values are so close it doesn't matter. Except for slightly different colours, you'd think.

Don't think it has read at all ... complete wipe is possible, but it'd also do this if it simply couldn't find the edid bus.

 

Typical

 

Hey, is everything still working on your end? I might take the plunge and reinstall windows 10. Have you experienced any weird issues till now like screen artifacts and such?

 

Dual Boot DOS + Linux with edid tools

It's a torrent now, but haven't used that for years (and years). Even if you don't intend to use it, can someone check the down-/upload is working?

Also mellowed the exclamation marks a bit; it isn't that serious. Just read the instructions and it'll be fine . Curious where you'll find the edids on the affected systems, btw. Can also test it with a running display, of course; tried it on three systems and it works perfectly.

 

I can't get to U1 unfortunately, the bezel glass is glued (like in most touchscreen laptops); might need to use a heatgun or heatplate I assume to separate the screen properly. @syphear, could you help on this please?

The markings from U2 and U3 do not bring up anything useful so far, will continue searching and update here. I could not see anything underneath the pcb, connecting pin 5 to anything, which is odd. I wonder why does the specs sheet for the screen lists this pin as LCD self test enable...

 

Yea I can, I have that display back in a frame but I can deal with the 6 screws holding it there tomorrow.

Interesting the pinouts for the AUO and the LG screens are different. Especially the pin 5 thing.

 

I have tried to start the torrent but the status is stuck on downloading metadata and won't begin, something is amiss.

 

Hi all.
I'm the first to admit some of this is a little above my skill set, but this post sounded familiar, I found it on Alienware forum in a thread started by a guy installing win 10 on a Aurora

Reading about it some more, this Intel Management Engine Interface is pure creepware that gets kernel access to your PC through hardware, which basically lets big brother connect to your system remotely and get instant kernel/ring 0 level clearance into your PC without a problem (and trust me, I write security and encryption software for a living and have written kernel drivers before, you don't want this *** on your PC). Most BIOS manufacturers have the option to disable Intel AMT entirely . I don't even know why its shipped with Alienware PCs to be completely honest, I don't want this on my PC, and absolutely want the option of disabling it. Especially since, even beyond the privacy issues, it stops my PC from booting into Windows 10. I would highly suggest adding this to the next BIOS release for Aurora PCs, please, this is a huge security risk.

 

For everyone who had their LCDs fail, were you running a stock configuration and vbios?

EX: AW18 with 780m sli or was it 980m sli or 780m sli with modified vbios?

Just curious

Still working, typing on my alienware 18 right now

 

I have been using Win 10 again since they fixed the mail syncing. I reinstalled it around Sept/3 and haven't got any issue with it.

 

Same here, LCD is still alive from win10 release date. Specs are the same as ssj92 except drives.
BTW, I did a BIOS reset after an upgrade (so it is UEFI with Legacy, I think) and after that I did win10 re-installation from USB (yes, an old method to reset Windows ).
But I am scared to update my nVidia drivers from 353.62 to new.

 

I'm running 355.60 atm

 

Ergh ... port forwarding change required reboot of router, unexpectedly. Going to add it to the NAS instead, that'll be easier. Will report back when ready.

And going to make that a 1GB or 2GB version after all, this is unmanageable. Plus, there's a bit too many 'black display' reports around, so there's some motivation involved. Most of these are guided towards buying new gpus, though ... so ... new nvidia business model?

 

I am more than sure that Win10 writes something into the bios.
How can I know this? After I made same stupidness again (decided to install Win10) I had weird boot loads when sometimes HDD with Windows 10 was actually loaded instead of SSD with Seven.
I went to BIOS and in Boot options saw not just usual P0 (P = Sata port) Plextor and P1 Hitachi but also just Plextor and Hitachi. I don't know why I did that but I set first boot option to just Plextor and second to just Hitachi. Save and reboot, aaaand bricked laptop with broken BIOS.

Yes, my only laptop, the one with bullet-proof BIOS (not UEFI) has just bricked (3 hours ago).
I had set RAM timings to unsupported XMP profiles before and it'd just rebooted with Fail-Safe defaults but it appears it was not ready to something like Windows 10. Yes, somehow Win10 tricked my laptop to think it is what... UEFI? That it showed 2 versions of same drive?
I don't know. All I know that I got another huge packet of troubles on myself. Last time my laptop was bricked I spent 9 monthes until I finally fixed it. Ohhhh, why did I try this devil's Windows 10, WHY?!

 

I feel for ya James. Your observations are highly suspicious. 10 writing to a BIOS is just a little FUD we're left to endure until the day reaches & the answer's a simple yes or no. That day isn't today. I too wonder over this & I'm not alone. Several alien desktop owners including me have installed 10 & realize the machine doesn't behave the same way on boot as it did on 7/8. What's SkyNet doing different this time with the bios it never did before? No sense in quoting an old article on the old Preview but the statement: "The new (10) driver isn't fully compatible with all BIOS revisions". This could be the source of my issue here during boot (old driver) or, yes, my 'new' bios revision courtesy of 10. I wanna know if OSX left its digital-DNA on my virgin hardware or not; a level-headed approach is 'no, not until proven otherwise'.

@t456 he's the man of the hour; he's still willing to call it a rootkit & the only person I'm willing to listen to. If 10 writes to a bios? 100 million genies & counting branded by the Mark of the Beast can't go back into the bottle & we'll get a consensus answer on it. If it doesn't? I'm not ashamed if I couldn't personally put it past Redmond not to try out a new demon seed.

Yesterday in Forbes: Microhard needs to be very careful. It took decades to build up user trust, but now it risks tearing everything down in just a few months…

 

Another compelling reason to disable Windows Updates in group policy or by a registry tweak.

Windows 10 Is Automatically Downloading On Windows 7 And Windows 8 | Forbes

 

U1 Chip from the LG Board, unfortunately I don't think its what we are after.

 

Luckily I have Win 8.1 Enterprise version that does not apply to free update and I don't need to do anything

@Up
Looks very similiar to the VBIOS chip on my GPU to be honest.

 

Add a Clevo P150SM-A to the list. This one sounds particularly nasty.

Full post here

http://forum.notebookreview.com/threads/black-screen-on-p150sm-a.781420/#post-10090424

 

count in a P771ZM with a LVDS Chi Mei Panel, looks like my EDID is gone too after updating from 355.60 to 355.84, just noticed it by accident, wanted to clean drivers via DDU and reboot into safe mode, but nothing ... black everywhere black. Weird fact is that i only get a picture when having nvidia drivers installed, so no bios screen and anything before initializing the nvidia drivers. Get's recognized as non-PnP Display too. Just rolled back to 8.1 to read my EDID from the registry and guess what, before DISPLAY\CMO1720 with EDID entrys of course, now DISPLAY\Default_Monitor with an entry BAD_EDID. At least i can get into bios when plugging a HDMI Display in, but still very annoying.

 

So the Clevo failures are picking up steam.

 

It would appear so. I just started a thread in the forum advising people not to mess with 10 and asking for people who have suffered a brick to post and share how the RMA process goes.