GfxInfo queries HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000 for DriverVersion and DriverDate -- apparently with Windows 8 (at least on my AMD machine) the registry entries are no longer present.

This is pretty major because about:support breaks.

I searched through the entire registry for 8.982.0.0000 (my driver version) and couldn't find it except in a couple of AMD-specific locations.

Maybe we should use http://msdn.microsoft.com/en-us/library/windows/hardware/ff551018 -- that seems to contain a driver date and version.

We should perhaps see where SetupDiEnumDriverInfo gets it's information from. In previous versions of Windows it used the same registry keys that we're currently using.

I tried looking but didn't find anything. Why not just use SetupDiEnumDriverInfo?

Note that this is fine in my VMware VM -- the DriverDate and DriverVersion are present where expected. It's only on my physical install that they're missing.

Nominating this for tracking-firefox16 and 17. It would be good to fix this in Firefox 16 so that we have a working about:support before Windows 8 ships to retail.

Assigning to Joe to either take this on or find the right person who will since we're a day away from Beta 3 so tracking this for 16 means we'll want a fix ready for uplift in the next 2.5 weeks

What I'd suggest is that if the driver details aren't present in the registry we should always assume the worst (an epoch date and a 0.0.0.0 version).

This works, but it might confuse anyone looking at about:support.

Comment on attachment 661630 [details] [diff] [review] proposed patch Review of attachment 661630 [details] [diff] [review]: ----------------------------------------------------------------- ::: widget/windows/GfxInfo.cpp @@ +327,4 @@ > mDriverDate = value; > + } else { > + // Again, assume the worst > + mDriverDate = L"01-01-1970"; If you want, append (driver info not found) to this string (it's never parsed by Firefox code, anyways).

To be clear, this is a workaround only: whatever systems are affected by this will be blacklisted from all hardware acceleration. So I suggest we either [leave open] this bug for a permanent fix, or file a follow-up bug for same.

Per an IRC discussion with Joe, I didn't make the (driver info not found) change because of l10n issues. I also switched to AssignLiteral to avoid potential issues with mingw. http://hg.mozilla.org/integration/mozilla-inbound/rev/b9622f2801fc

Comment on attachment 661844 [details] [diff] [review] what I checked in [Approval Request Comment] Bug caused by (feature/regressing bug #): not a regression User impact if declined: hardware acceleration enabled even on machines where it shouldn't be. Testing completed (on m-c, etc.): limited Risk to taking this patch (and alternatives if risky): not risky. However, this could make people we would otherwise allow to have hardware acceleration appear to be "blacklisted" on Windows 8; this is not actually a fix to this bug, but is instead a more correct handling of error cases. String or UUID changes made by this patch: none

Comment on attachment 661844 [details] [diff] [review] what I checked in [Triage Comment] Let's take this in support of bug 783517, given the low risk profile.

(and please land asap today)

https://hg.mozilla.org/releases/mozilla-aurora/rev/ae742d5abf94 https://hg.mozilla.org/releases/mozilla-beta/rev/cdd04249a313

I tried to reproduce the initial issue, but I couldn't. The driver version and date are present in the about:support and also in the registry under: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000 I also see many registry entries (about 20) like HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000. Only one of them has the correct driver version and date. The rest of them have the driver date and version outdated (6-21-2006 and 6.2.9200.16384). I have the same Driver version as the one mentioned in Comment 2 (8.982.0.0). Is there anything I can do to properly set up the environment to verify this?

You can delete DriverDate and DriverVersion at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\0000, then start up Firefox. (Remember to put them back later.)

Mozilla/5.0 (Windows NT 6.2; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0 rc build Verified the fix using the suggestions from comment #20 and it works as expected: Graphics details are listed in about:support with DriverDate 1-01-1970 and Driver Version 0.0.0.0 if their entries are removed from registry. Still, graphics section of about:support remains broken if only the values of DriverDate and DriverVersion are removed (blank value). However, this is an edge case and I think this bug can be marked verified for now. Please let me know if you want to address this in a followup bug.

Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 beta 1 Mozilla/5.0 (Windows NT 6.2; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 Verified the fix on the above builds and it looks ok with the note from comment #21