Access violation reading location 0x00000510
We`ve got this big problem in our game.
Access violation happens only under Win7 + Intel graphics (GMA 3100, GMA 950) and works fine under WinXP or with non-Intel cards so it is definitely not a problem of our 3d engine. Affected both 22.214.171.1249 driver and the latest available 1930.
Call stack right after crash:
[Frames below may be incorrect and/or missing, no symbols loaded for igdumd32.dll]
d3d9.dll!CD3DDDIDX10::DrawIndexPrim() + 0x204 bytes
d3d9.dll!wmt_DRAW_CLIPPED_PRIM() + 0x1be bytes
d3d9.dll!wmt_PVFUNCS::ProcessIndexedPrimitive() + 0x11a bytes
d3d9.dll!CD3DDDIDX8::ProcessIndexedPrimitiveC() + 0x119 bytes
d3d9.dll!CD3DHal_DrawIndexedPrimitive() + 0xa4 bytes
d3d9.dll!CD3DBase::DrawIndexedPrimitive() + 0xc3 bytes
> lzView.exe!lzMesh::Dip(D3DXMATRIX * iTm=0x0abb9b18, int iFrame=0) Line 79 + 0x43 bytes C++
Help to find any workaround as soon as possible. Our customers have Intel graphics, so we need to fix this in some way.
I can make a bug repro, if it helps you dealing with this problem. Or if it is possible you may send to me igdumd32 pdb file, then I can provide more readable report.
As an additional note, I try to describe some logic behind this bug.
We are drawing different object on the scene, using FFP setup. Just SetRenderStates, SetTextures and so on and finally DIPs.
At the some beautiful moment (when tens of objects allready drawn), all crashes after calling DIP.
But it is not the DIP problem by itself I guess. This is something what your dll do behind the scene: changing the shader or it`s constants or something. I think so, because if I alter statechanges before make that killing DIP, all works fine. My expirements shows, that if i.e. I will change D3DRS_SPECULARENABLE to TRUE before that dip nothing crashes.
Also, when I change stages setup (i.e. switch off stage 1 by passing D3DTOP_DISABLE), an address in access violation changes too (it is equals to 0x000003f0).
Don`t know helps this or no, but I tell some more about the program.
- There is a Reset() at the start of the game.
- All works using FFP, no custom shading applied.
- Compiled with DirectX 9c SDK (2004 aug and 2008 aug).
- Works in windowed mode
- ... anything you ask
I found x3000, all works fine. But that was almost obvious, since x3000 is hardly improved and has totally different codepath in the driver I guess. The main problem is that too many casual customers haven`t recent hardware, so we need to deal with that outdated stuff too.
Is it possible to get a pdb file for that dll? Then I can report more readable info about the place where all crashes.
Will some kind of memory dump be helpful?
Or maybe your company has something like "hardware archive" and it is possible to query older generation systems from it for several days?
I've got a similar problem:
Faulting application name:X.vshost.exe, version: 9.0.21022.8, time stamp: 0x47316898
Faulting module name: igdumd32.dll, version: 126.96.36.1996, time stamp: 0x4aeb3b2c
Exception code: 0xc0000409
Fault offset: 0x00014fe6
Faulting process id: 0xbdc
Faulting application start time: 0x01cac63abe14226d
Faulting application path: C:\Projects\X\Debug\X.vshost.exe
Faulting module path: C:\Windows\system32\igdumd32.dll
Report Id: 01ca9c3f-322e-11df-9568-00247edc9161
Basically, whenever I try to run my project in Visual Studio 2008 vshost.exe crashes and the above is in the event log.
My environment is:
Windows 7 Professional
Intel 4 Series Express Chipset - GMA 4500MD
I've tried various 8.15.10.x builds, but none of them helped.
I installed 188.8.131.526 (the latest version 7 build that I could get) and I can run the project in Visual Studio 2008.
The problem now is that the screen will judder below the cursor!
This can be solved to some degree by reducing the resolution on the laptop screen, but not on my external monitor.