Wine64 debugger

[Peter Urbanec]

Hi,

I'm trying to get a fairly complex Win64 application to work with wine. 
I'm seeing crashes in FindNextFileW/FindNextFileA due to what looks like 
a 64 bit HANDLE value being truncated to 32 bits. I thought that I would 
employ winedbg to help me, but I can't get very far. I don't have any 
luck with winedbg even on a simple x64 Win32 app.

For my simplified test, I used MSVC2005 to generate an x64 executable 
created from the standard MSVC2005 template Win32 application. This is a 
simple app that just creates an empty window. As simple as one could get 
for a Win32 test and it executes correctly when run as "./wine 
Test1.exe". When I try to execute this test app under winedbg, I get an 
assert failure:

./wine winedbg Test1.exe
WineDbg starting on pid 001a
./programs/winedbg/memory.c:37: be_cpu_linearize: Assertion `addr->Mode 
== AddrModeFlat' failed.
wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting 
debugger...
Unhandled exception: assertion failed in 64-bit code (0x00007fec2fa657c5).

Any ideas about why I can not use winedbg to run Win32 x64 code?

Thanks,

Peter Urbanec

[Marcus Meissner]

On Wed, Aug 18, 2010 at 01:00:35AM +1000, Peter Urbanec wrote:
> Hi,
>
> I'm trying to get a fairly complex Win64 application to work with
> wine. I'm seeing crashes in FindNextFileW/FindNextFileA due to what
> looks like a 64 bit HANDLE value being truncated to 32 bits. I
> thought that I would employ winedbg to help me, but I can't get very
> far. I don't have any luck with winedbg even on a simple x64 Win32
> app.

Check if your code uses "int" in its FindNextFile or findfirst things.

I fixed ioquake3 for this for instance.

The Wine code is correct as-is, but perhaps the Windows win64 code generates
only handles with 32bit.

Ciao, Marcus

[David Laight]

On Tue, Aug 17, 2010 at 05:51:55PM +0200, Marcus Meissner wrote:
> The Wine code is correct as-is, but perhaps the Windows win64 code generates
> only handles with 32bit.

That it very likely.
There are windows #defines/inline functions that convert HANDLE <=> long.
Remember there are some functions that return handles as long (not void *)

Also, when the windows kernel generates a HANDLE it is unlikely to know
whether the app is 32bit or 64bit - so will only generate 32bit values.

I also remember reading somewhere that the kernel handle table is
limited to 2^24 entries - even in 64bit mode.

David

[Peter Urbanec]

On 18/08/10 01:51, Marcus Meissner wrote:
> On Wed, Aug 18, 2010 at 01:00:35AM +1000, Peter Urbanec wrote:
> > I'm seeing crashes in FindNextFileW/FindNextFileA due to what
> > looks like a 64 bit HANDLE value being truncated to 32 bits.
>
> Check if your code uses "int" in its FindNextFile or findfirst things.

I had a good look at the wine source code as well as those parts of the 
application source code that I can get access to and it all looks good 
as far as correctly using HANDLE type to store HANDLE values. 
Unfortunately, the application in question also makes use of FLEXlm 
libraries from Macrovision and these binary blobs appear to be buggy. 
All the symptoms point to the FLEXlm code storing the 64-bit HANDLE 
value in a 32-bit int - this is evidenced by sign extension on some of 
the values.

Of course, the initial cause and the issues with the debugger are 
essentially unrelated. I have sent some sample test binaries to Eric, to 
reproduce the debugger issue.

The buggy Win64 application is another story. It looks like Win64 must 
most of the time return HANDLE values that fit within 31 bits, because 
from what I hear, Windows users go through thousands of invocations of 
this app without seeing any issues.

I wonder if there is a way of making wine allocate the memory for the 
object pointed to by the HANDLE somewhere in the lower part of the 
address space. That ought to mitigate this particular application bug 
and bring the compatibility a little closer to what's observed under Win64.

[Eric Pouech]

the assertion `addr->Mode == AddrModeFlat' failed is likely an address
returned by dbghelp which is not properly initialized.
Could you send me off line the .exe (and associated DLL if any) so that I
can check it
TIA

2010/8/17 Peter Urbanec
> Hi,
>
> I'm trying to get a fairly complex Win64 application to work with wine. I'm
> seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64
> bit HANDLE value being truncated to 32 bits. I thought that I would employ
> winedbg to help me, but I can't get very far. I don't have any luck with
> winedbg even on a simple x64 Win32 app.
>
> For my simplified test, I used MSVC2005 to generate an x64 executable
> created from the standard MSVC2005 template Win32 application. This is a
> simple app that just creates an empty window. As simple as one could get for
> a Win32 test and it executes correctly when run as "./wine Test1.exe". When
> I try to execute this test app under winedbg, I get an assert failure:
>
> ./wine winedbg Test1.exe
> WineDbg starting on pid 001a
> ./programs/winedbg/memory.c:37: be_cpu_linearize: Assertion `addr->Mode ==
> AddrModeFlat' failed.
> wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting
> debugger...
> Unhandled exception: assertion failed in 64-bit code (0x00007fec2fa657c5).
>
> Any ideas about why I can not use winedbg to run Win32 x64 code?
>
> Thanks,
>
> Peter Urbanec