[Wine] Re: Wine unhandled exception running PocketFMS

[Duane Clark]

Rob Turk wrote:
> I'm trying to get the PocketFMS flight assistant program to work under Wine. 
> This program is available for free at www.pocketfms.com .
> 
> The installation of PocketFMS works OK with a few 'fixme' warnings, but 
> running the installed program causes an immediate crash. As this program is 
> still in development itself and not designed to run on anything but Windows, 
> I'd like to know if the information below points to a bug in Wine, or a bug 
> in PocketFMS. The host is Slackware 11 with a 2.6.19.1 Linux kernel, and 
> Wine is 0.9.28 compiled from source.
> 
> At the bottom there's information generated with WINEDEBUG=+relay set. It 
> appears something is wrong with a call to gdi32.StretchDIBits() but I'm not 
> enough into Wine debugging to confirm this.

I am not really much of a debugger either, but here is my two cents worth...

> 
> ==============>8===========================
> root at slack11:~# wine "c:\program files\pocketfms\pocketfms.exe"
> wine: Unhandled page fault on read access to 0x0465bf70 at address 
> 0x7e4ec030 (thread 0009), starting debugger...
> Unhandled exception: page fault on read access to 0x0465bf70 in 32-bit code 
> (0x7e4ec030).

So the program crashes on an attempt to read from 0x0465bf70, and the 
relay trace shows that indeed a call was made to StretchDIBits with that 
value for a BITMAPINFO pointer.

 > gdi32.StretchDIBits(00000540,00000000,00000000,000000d0,0000001a,
 > 00000000,00000000,000000d0,0000001a,0465bf70,00af5cf8,00000000,00cc0020)
 > ret=0053eafd

The return value indicates the call was made from within PocketFMS, 
rather than from somewhere in Wine.

 > Module  Address                 Debug info      Name (91 modules)
 > PE      400000-6b8000   Export          pocketfms

I notice that shortly before the crash, the program locks some resources 
near a similar address:

 > 0009:Call kernel32.LockResource(0065bf48) ret=0053e9cf
 > 0009:Ret  kernel32.LockResource() retval=0065bf48 ret=0053e9cf

I find the similarity with the crashing address to be a bit surprising 
to be a coincidence. What it all means though, I have no idea ;) It 
would appear that for some reason, the program is setting a high order 
bit in a pointer address.