Closed Bug 601997 Opened 14 years ago Closed 14 years ago

Crashes when igd10umd32.dll version is 8.14.x.y while DriverVersion is 8.15.x.y [@ igd10umd32.dll@0x...... ]

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INVALID
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: bjacob, Assigned: bjacob)

References

Details

Attachments

(1 file)

raw data tab separated set of igd10umd32.dll version, os ver, app notes, crash sig, link to crash report
139.80 KB, text/plain
Details 
We have Intel Graphics driver crash reports at igd10umd32.dll@0x1195c and igd10umd32.dll@0x1e1ba0, see bug 595364. (Direct2D crashes)

This crash seems to only happen with certain GMA X3000 cards, namely these device ids:

    0x2982   IntelG35
    0x2983   IntelG35
    0x2A02   IntelGL960
    0x2A03   IntelGL960
    0x2A12   IntelGM965
    0x2A13   IntelGM965

It happens even with latest Intel driver (we are requiring driver version >= 8.15.10.1930 anyway).

However, what we just realized with Jeff is that the crash only happens when the igd10umd32.dll version starts in 8.14.x.y. In all the crash reports we have for these crash signatures, the driver version is 8.14.x.y. We have a machine here with device 0x2A02, and igd10umd32.dll version 8.15.x.y and it's NOT crashing.

So here is a question: is it abnormal that igd10umd32.dll version is 8.14 while DriverVersion is 8.15 ? Does that explain crashes?

If yes: how did users end up with mismatched versions?

If no: that would then conclude to a Intel driver bug? How to contact them about that? Meanwhile, we blacklist these devices (since we crash even on latest driver version).
OS: Linux → Windows CE
OS: Windows CE → Windows 7
Chris,
Thanks to show here the results of my request of bug 595364 comment 52.
Blocks: 595364
Severity: normal → critical
blocking2.0: --- → ?
Hardware: x86_64 → x86
Summary: Crashes when igd10umd32.dll version is 8.14.x.y while DriverVersion is 8.15.x.y → Crashes when igd10umd32.dll version is 8.14.x.y while DriverVersion is 8.15.x.y [@ igd10umd32.dll@0x...... ]
(In reply to comment #0)
> However, what we just realized with Jeff is that the crash only happens when
> the igd10umd32.dll version starts in 8.14.x.y. In all the crash reports we have
> for these crash signatures, the driver version is 8.14.x.y.

Sorry, I meant the *igd10umd32.dll* version is 8.14.x.y. The DriverVersion is 8.15.x.y or else we blacklist it anyway.
I have this info from intel:

8.15.10.x    Win7
7.15.10.x    Vista DX10
7.14.10.x    Vista DX9
6.14.10.X    XP

I don't see 8.14.x.y there at all, which is very confusing.
(sent this question off to Intel)
This apparently isn't supposed to happen :-)

Jeff, on your "good" machine, both the dll version and the driver version are 8.15.x?  Or is one of them .14?  I'm not sure if I can interpret the above comments correctly.  If I understand, what's happening is:

GOOD:  dll: 8.15.x  DriverVersion: 8.15.x
 BAD:  dll: 8.14.x  DriverVersion: 8.15.x

right?
(In reply to comment #5)
> This apparently isn't supposed to happen :-)
> 
> Jeff, on your "good" machine, both the dll version and the driver version are
> 8.15.x?

Yes.

> Or is one of them .14?

Not on Jeff's good, non-crashing machine.

>  I'm not sure if I can interpret the above
> comments correctly.  If I understand, what's happening is:
> 
> GOOD:  dll: 8.15.x  DriverVersion: 8.15.x
>  BAD:  dll: 8.14.x  DriverVersion: 8.15.x

Exactly.

Sorry for the unclear explanation above.
I presume we see a number of people with this bug. We should just make sure that the version numbers are equal, and blocklist that machine if they aren't.
Assignee: nobody → bjacob
blocking2.0: ? → betaN+
Yeah, except that we currently don't check the dll version at all.  We can, but then we'd have to figure out what to do when they're different -- do we take the lower version?
This is precisely the kind of question that I would like to hear an answer from Intel on!
Yes, the answer was that "this isn't supposed to happen" -- do we know how users got into the broken state?
That's a question I asked in comment 0 and I still don't have a clue.
(In reply to comment #3)
> I have this info from intel:
> 
> 8.15.10.x    Win7
> 7.15.10.x    Vista DX10
> 7.14.10.x    Vista DX9
> 6.14.10.X    XP

Not sure if this is the case with this specific graphics chipset, but I believe I'm facing somehow related issue (being unable to activate Direct2D with "Mobile Intel(R) 965 Express Chipset Family" bug 594025 comment 30 and beyond) where I'm starting to suspect of a weird OS/DirectX/Driver interference (bug 594025 comment c38).


> I don't see 8.14.x.y there at all, which is very confusing.

AFAIK X.14 is related with DirectX 9 support and I guess Windows 7 came out with Direct 10 or 11 support out-of-the-box so probably we might never see 8.X with X < 15...? :-)
May be we are wrong and the driver and igd10umd32.dll versions are both 8.14.10.1930 and this driver version is not blocked for D2D/DW/D3D features

Suppose for a dedicated deviceID that driver version is w.x.y.z and driver min version is 8.15.10.1930.
How IMPLEMENT_INTEL_DRIVER_BLOCKLIST works when w=8, x=14<15, y=10, z=1930 ?
we started getting some data out of socorro last night that might help understanding this.

attachment shows raw data where ever app notes indicates AdapterDeviceID equal to 2a02, 2912 or 2a12 for any crash report.

from that we can see counts where signature indicates crash in igd10umd32.dll@address

awk -F\t '$1 ~ /igd10/ && $4 ~ /igd10/ {print $1,$2,$3}' foo.txt | sort | uniq -c | sort -nr
  59 igd10umd32.dll 8.14.10.1930 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a02
   9 igd10umd32.dll 8.15.10.1867 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a02
   3 igd10umd32.dll 8.15.10.1912 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a02
   2 igd10umd32.dll 8.14.10.1930 Windows NT 6.1.7601 Service Pack 1, v.178 AdapterVendorID: 8086, AdapterDeviceID: 2a02
   1 igd10umd32.dll 8.15.10.1825 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a12
   1 igd10umd32.dll 8.15.10.1825 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a02
   1 igd10umd32.dll 8.14.10.1930 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a12

and then these counts are for any signature place where igd10umd32.dll version info was available.  

awk -F\t ' {print $1,$2,$3}' foo.txt | sort | uniq -c | sort -nr | grep igd10
 222 igd10umd32.dll 8.14.10.1930 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a02
  64 igd10umd32.dll 8.15.10.1749 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a02
  19 igd10umd32.dll 8.15.10.1867 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a02
  13 igd10umd32.dll 8.14.10.1930 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a02\n
   9 igd10umd32.dll 8.14.10.1930 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a12
   8 igd10umd32.dll 8.15.10.1749 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a02\n
   7 igd10umd32.dll 8.15.10.1749 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a12
   6 igd10umd32.dll 8.15.10.1912 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a02
   6 igd10umd32.dll 8.15.10.1825 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a02
   5 igd10umd32.dll 8.14.10.1930 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a12\n
   3 igd10umd32.dll 8.14.10.1930 Windows NT 6.1.7601 Service Pack 1, v.178 AdapterVendorID: 8086, AdapterDeviceID: 2a02
   1 igd10umd32.dll 8.15.10.1867 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a02\n
   1 igd10umd32.dll 8.15.10.1825 Windows NT 6.1.7600 AdapterVendorID: 8086, AdapterDeviceID: 2a12
   1 igd10umd32.dll 8.15.10.1662 Windows NT 6.1.7100 AdapterVendorID: 8086, AdapterDeviceID: 2a02

We should start getting more data over the next few days.  Let me know if we need to fine tune this or analyze the data in different ways.
looks like about 40% of the time where we are getting DeviceID in the reports there is no igd10umd32.dll version info
in these places where we get deviceID info but no igd10umd32.dll version here are counts for OS and deviceID.  looks like we see a wider variety of OS versions there.  is there another .dll to look for?

grep '^Win' foo.txt | awk -F\t ' {print $1,$2}'  | sort | uniq -c | sort -nr | more
  65 Windows NT 6.0.6002 Service Pack 2 VendorID: 8086, DeviceID: 2a02
  64 Windows NT 6.0.6002 Service Pack 2 VendorID: 8086, DeviceID: 2a02\n
  47 Windows NT 6.1.7600 AdapterVendorID: 8086, DeviceID: 2a02\n
  33 Windows NT 6.0.6001 Service Pack 1 VendorID: 8086, DeviceID: 2a02
  31 Windows NT 6.0.6000 VendorID: 8086, DeviceID: 2a02
  17 Windows NT 6.0.6000 VendorID: 8086, DeviceID: 2a02\n
  13 Windows NT 6.1.7600 VendorID: 8086, DeviceID: 2a02
   9 Windows NT 6.0.6001 Service Pack 1 VendorID: 8086, DeviceID: 2a02\n
   8 Windows NT 5.1.2600 Service Pack 3 VendorID: 8086, DeviceID: 2a02
   7 Windows NT 6.1.7600 VendorID: 8086, DeviceID: 2a12\n
   3 Windows NT 6.0.6002 Service Pack 2 VendorID: 8086, DeviceID: 2a12
   1 Windows NT 6.1.7600 VendorID: 8086, DeviceID: 2a12
   1 Windows NT 6.0.6001 Service Pack 1 VendorID: 8086, DeviceID: 2a12
   1 Windows NT 5.1.2600 Service Pack 3 VendorID: 8086, AdapterDeviceID: 2a12
   1 Windows NT 5.1.2600 Service Pack 2 VendorID: 8086, AdapterDeviceID: 2a02
> these counts are for any signature place where igd10umd32.dll version
> info was available.  
It seems that version 8.15.10.1930 of igd10umd32.dll does not exist.
The only version of igd10umd32.dll with pattern 8.14.10.x is 8.14.10.1930.
I think that when igd10umd32.dll version is 8.14.10.1930, Intel driver version is 8.15.10.1930.

> is there another .dll to look for?
Can we try to find all the Intel dll version (igd10umd32.dll is the only Intel dll in crashes with igd10umd32.dll@address signature), such as : igdumd32.dll, igdumdx32.dll, ig4icd32.dll, ig4dev32.dll
If we have a confirmation of this Intel naming error, there is nothing to do more than what has already been done : blocklisting the 6 deviceID for D2D/DW features to prevent some crashes
> Can we try to find all the Intel dll version (igd10umd32.dll is the only 
> Intel dll in crashes with igd10umd32.dll@address signature), such as : 
> igdumd32.dll, igdumdx32.dll, ig4icd32.dll, ig4dev32.dll

Ok,  I've added those and restarted the script.  It will take a while to run.

I also notice that in cases where there aren't any matches for the intel graphics diver .dlls are found direct3d .dll's are.

some examples are

d3d9.dll 6.1.7600.16385 d3d8thk.dll 6.1.7600.16385 
Windows NT 6.1.7600 
AdapterVendorID: 8086, AdapterDeviceID: 2a12\n 
hang | memcpy | PixelCopy32 
http://crash-stats.mozilla.com/report/index/91cea2c4-8028-4f77-8041-474e02101007

d3d9.dll 6.0.6002.18005 d3d8thk.dll 6.0.6000.16386 
Windows NT 6.0.6002 Service Pack 2 
AdapterVendorID: 8086, AdapterDeviceID: 2a02\n 
NPSWF32.dll@0x38d392 
http://crash-stats.mozilla.com/report/index/724d80b9-f107-4693-bdcb-7b16b2101007

d3d8thk.dll 6.0.6000.16386 d3d9.dll 6.0.6000.16386 
Windows NT 6.0.6000 
AdapterVendorID: 8086, AdapterDeviceID: 2a02\n 
RtlEnterCriticalSection 
http://crash-stats.mozilla.com/report/index/06f0f868-d886-46d4-9aaa-2fdea2101007

d3d10_1core.dll 7.0.6002.18391 d3d10_1.dll 7.0.6002.18391 
Windows NT 6.0.6002 Service Pack 2 
AdapterVendorID: 8086, AdapterDeviceID: 2a02 
js::TraceRecorder::setImpl(void*, nanojit::LIns*, bool) 
http://crash-stats.mozilla.com/report/index/d0777bc0-f1bd-4772-abca-5d5192101007

even then there are still reports with no matches on what we are searching for in the module list so far

Windows NT 6.0.6002 
Service Pack 2 AdapterVendorID: 8086, AdapterDeviceID: 2a02\n 
hang | KiFastSystemCallRet 
http://crash-stats.mozilla.com/report/index/77cdb3c5-0c1b-4ef8-b1fc-de2b32101007

Windows NT 6.0.6002 Service Pack 2 
AdapterVendorID: 8086, AdapterDeviceID: 2a02\n 
NPSWF32.dll@0x182cf0 
http://crash-stats.mozilla.com/report/index/f2404cf0-6
33e-4c95-a098-240902101007
filling in with igdumd32.dll, igdumdx32.dll, ig4icd32.dll, ig4dev32.dll where we can version number for those .dll's the stats look like this:

 222 igd10umd32.dll 8.14.10.1930 Windows NT 6.1.7600 DeviceID: 2a02
  64 igd10umd32.dll 8.15.10.1749 Windows NT 6.1.7600 DeviceID: 2a02
  19 igd10umd32.dll 8.15.10.1867 Windows NT 6.1.7600 DeviceID: 2a02
  13 igd10umd32.dll 8.14.10.1930 Windows NT 6.1.7600 DeviceID: 2a02\n
   9 igd10umd32.dll 8.14.10.1930 Windows NT 6.1.7600 DeviceID: 2a12
   8 igd10umd32.dll 8.15.10.1749 Windows NT 6.1.7600 DeviceID: 2a02\n
   7 igd10umd32.dll 8.15.10.1749 Windows NT 6.1.7600 DeviceID: 2a12
   6 igdumd32.dll 8.14.10.1930   Windows NT 6.1.7600 DeviceID: 2a02
   6 igd10umd32.dll 8.15.10.1912 Windows NT 6.1.7600 DeviceID: 2a02
   5 igd10umd32.dll 8.15.10.1825 Windows NT 6.1.7600 DeviceID: 2a02
   5 igd10umd32.dll 8.14.10.1930 Windows NT 6.1.7600 DeviceID: 2a12\n
   4 \N \N AdapterVendorID: 8086, AdapterDeviceID: 2a02 \N
   3 igdumd32.dll 7.14.10.1409 Windows NT 6.0.6002 Srv Pack 2 DeviceID: 2a02\n
   3 igd10umd32.dll 8.14.10.1930 Windows NT 6.1.7601 Srv Pack 1, v.178 DeviceID: 2a02
   2 \N \N AdapterVendorID: 8086, AdapterDeviceID: 2a02\n \N
   1 igdumd32.dll 7.14.10.1318 Windows NT 6.0.6001 Service Pack 1 DeviceID: 2a02
   1 igdumd32.dll 7.14.10.1253 Windows NT 6.0.6000 DeviceID: 2a02\n
   1 igd10umd32.dll 8.15.10.1867 Windows NT 6.1.7600 DeviceID: 2a02\n
   1 igd10umd32.dll 8.15.10.1825 
   1 igd10umd32.dll 8.15.10.1825 Windows NT 6.1.7600 DeviceID: 2a12
   1 igd10umd32.dll 8.15.10.1662 Windows NT 6.1.7100 DeviceID: 2a02
Comment 19 confirms what it is written in comment 17 : version 8.14.10.1930 of dll files matches version 8.15.10.1930 of Intel driver.
I close the bug as invalid.

Comment 18 shows only that there are a lot of version of Vista (Vista, Vista SP2, Vista SP2 + some MS hotfixes) that have different behavior for D3D feature with a DX10 card. I don't think we can conclude to any bug according to that.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
So, the original point of this bug report was that we had found a machine with device 0x2a02 (blacklisted) where Direct2D was not crashy. So it seemed that our blacklist was wrong to block this device altogether and that a finer blacklist with an additional criterion added into the mix was needed.

I don't understand why in comment 20 you say that comment 19 confirms that "version 8.14.10.1930 of dll files matches version 8.15.10.1930 of Intel driver" ? Doesn't comment 19 confirm, on the contrary, that this mix of 
versions is the top crash configuration?

Moreover, in comment 10, Vlad said (IIUC) that according to Intel this 8,14 vs 8.15 mix isn't supposed to happen.

What comment 19 does prove is that we actually had crashes even with 8.15 versions of the dll, but not with versions >= 8.15.10.1930. Should we require DLL version 8.15.10.1930, in addition to requiring DriverVersion >= 8.15.10.1930 ?
> So, the original point of this bug report was that we had found a machine with
> device 0x2a02 (blacklisted) where Direct2D was not crashy. So it seemed that
> our blacklist was wrong to block this device altogether and that a finer
> blacklist with an additional criterion added into the mix was needed.
Give more details about that : which FF version ? Graphic section of about:support ?

> I don't understand why in comment 20 you say that comment 19 confirms that
> "version 8.14.10.1930 of dll files matches version 8.15.10.1930 of Intel
> driver" ? Doesn't comment 19 confirm, on the contrary, that this mix of 
> versions is the top crash configuration?
Crash analysis in comment 19 are about EVERY crashes where this dll file is present, even in 4.0b6. If you don't have at least some crashes with version 8.15.10.1930 of dll files that means this version of dll files does not exist.

> Moreover, in comment 10, Vlad said (IIUC) that according to Intel this 8,14 vs
> 8.15 mix isn't supposed to happen.
That means that probably the guy at Intel that compiled driver version 8.15.10.1930 made a mistake. Intel won't say that, at least officially.

> What comment 19 does prove is that we actually had crashes even with 8.15
> versions of the dll, but not with versions >= 8.15.10.1930. Should we require
> DLL version 8.15.10.1930, in addition to requiring DriverVersion >=
> 8.15.10.1930 ?
There is nothing more to do, because blacklisting for D2D feature works. You can see that bug 595364 is now in verified status.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: