one liner patch to stop crash, everquest2.exe

Chris Ahrendt celticht32 at aol.com
Mon Jul 21 20:20:19 CDT 2008


H. Verbeet wrote:
> 2008/7/21 Andrew Fenn <andrewfenn at gmail.com>:
>> Here's my uneducated idea about what's happening, it's calling the
>> USER_SetWindowPos() in /user32/winpos.c to an x and y of 0 which goes off to
>> SendMessageW.
>>
>> SendMessageW calls send_message which in turn calls call_window_proc. At
>> this point something resets because SendMessageW should log both a "1" and
>> "2\n" which I added to be printed out but as you can see below it only
>> prints out a "1" and then goes on to IWineD3DDeviceImpl_Reset after hitting
>> call_window_proc..
>>
>> fixme:msg:SendMessageW 1sendmsg1
>> fixme:msg:send_message sendmsg2
>> fixme:msg:send_message sendmsg3
>> fixme:d3d:IWineD3DDeviceImpl_Reset HELLO, hr: 0x00000000
>> fixme:d3d_shader:shader_glsl_free FREE SHADER
>> wine: Unhandled page fault on read access to 0x00000008 at address
>> 0x7e452e5c (thread 0009), starting debugger...
>> Unhandled exception: page fault on read access to 0x00000008 in 32-bit code
>> (0x7e452e5c).
>>
>> Does any of that make any sense?
>>
> Ah, so it's essentially a recursive Reset call. My guess would be that
> we don't want to allow that, but it requires some tests on native
> win32 to verify. You could try returning WINED3DERR_INVALIDCALL when
> Reset gets called from inside another Reset call, to see how the
> application reacts to that.
> 
> 

I have been chasing something like this in EQ2 for awhile and I am 
noticing that yes it is recursively calling something that is cycling 
throught the adapter reset.. I also see the following :

trace:d3d_caps:IWineD3DImpl_CheckDeviceFormat (0x18d908)-> (STUB) 
(Adptr:0, DevType:(1,WINED3DDEVTYPE_HAL), 
AdptFmt:(21,WINED3DFMT_A8R8G8B8), Use:(8,WINED3DUSAGE_WRITEONLY,none), 
ResTyp:(3,WINED3DRTYPE_TEXTURE), CheckFmt:(41,WINED3DFMT_P8))
trace:d3d_caps:IWineD3DImpl_GetAdapterCount (0x18d908): Reporting 1 adapters
trace:d3d_caps:CheckTextureCapability [OK]
trace:d3d_caps:IWineD3DImpl_CheckDeviceFormat [FAILED] - Usage=0x000008 
requested for CheckFormat=WINED3DFMT_P8 and RType=3 but only 00000000 is 
available
trace:d3d_caps:IWineD3DImpl_CheckDeviceFormat (0x18d908)-> (STUB) 
(Adptr:0, DevType:(1,WINED3DDEVTYPE_HAL), 
AdptFmt:(22,WINED3DFMT_X8R8G8B8), Use:(8,WINED3DUSAGE_WRITEONLY,none), 
ResTyp:(3,WINED3DRTYPE_TEXTURE), CheckFmt:(41,WINED3DFMT_P8))
trace:d3d_caps:IWineD3DImpl_GetAdapterCount (0x18d908): Reporting 1 adapters
trace:d3d_caps:CheckTextureCapability [OK]
trace:d3d_caps:IWineD3DImpl_CheckDeviceFormat [FAILED] - Usage=0x000008 
requested for CheckFormat=WINED3DFMT_P8 and RType=3 but only 00000000 is 
available
trace:d3d:IWineD3DDeviceImpl_Clear (0x193380) Count (0), pRects ((nil)), 
Flags (1), Color (0x00000000), Z (0.000000), Stencil (0)
trace:d3d:ActivateContext (0x193380): Selecting context for render 
target 0x3a40080, thread 9
trace:d3d:ActivateContext glEnable GL_SCISSOR_TEST call ok context.c / 1099

I went ahead and attached my complete trace on the d3d (I put all of the
d3d flags on in the attached trace).  you can sort of see what I
am seeing with the adapter initializing 2 times I think...

Chris
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wineerror
Url: http://www.winehq.org/pipermail/wine-devel/attachments/20080721/48917dad/attachment-0001.txt 


More information about the wine-devel mailing list