VirtualFree differences between 7 (x64) and Vista (x86) known?

[4C617273H]

Hello,

my application runs fine under Windows Vista Home Premium 32-bit (in a Virtual Machine) and OllyDbg 1.10 also shows that my code works as intended.

Under Windows 7 Home Premium 64-bit the application crashes when calling VirtualFree (it just vanishes). Unfortunately I don't know any 64-bit debugger besides WinDbg who I can't handle.

Thus my question is whether someone knows any differences between 7 x64 and Vista x86 or something else to look for regarding VirtualFree.

I uses MASM32 SDK 10 with EasyCode IDE. It's a 32-bit application.

Here's the link to VirtualFree reference: http://msdn.microsoft.com/en-us/library/aa366892(v=VS.85).aspx
Here's the memory functions reference: http://msdn.microsoft.com/en-us/library/aa366781(v=VS.85).aspx
Here's OllyDbg: http://www.ollydbg.de/

Thanks for any help!

Lars

P.s.: I might post the application (debug version 90 KB). Although the code is small I guess I would have to explain too much regarding my used memory layout even though it's gui code only.

[ToutEnMasm]

Hello,
answer to this is given by the headers of the SDK
First limitations:

__drv_when(((dwFreeType&(MEM_RELEASE|MEM_DECOMMIT)))==(MEM_RELEASE|MEM_DECOMMIT),
    __drv_reportError("Passing both MEM_RELEASE and MEM_DECOMMIT to VirtualFree is not allowed. This results in the failure of this call"))

__drv_when(dwFreeType==0,
    __drv_reportError("Passing zero as the dwFreeType parameter to VirtualFree is not allowed. This results in the failure of this call"))

__drv_when(((dwFreeType&MEM_RELEASE))!=0 && dwSize!=0,
    __drv_reportError("Passing MEM_RELEASE and a non-zero dwSize parameter to VirtualFree is not allowed. This results in the failure of this call"))
WINBASEAPI
BOOL
WINAPI
VirtualFree(
    __in LPVOID lpAddress,
    __in SIZE_T dwSize,
    __in DWORD dwFreeType
    );

second:
SIZE_T can be a QWORD or a DWORD,it is a typedef which value depend of the system and machine you use

[4C617273H]

Hello, the information in the headers is on msdn also. I already took note of them :-)

The second point is interesting: or rather it brings up another question (I use MEM_RELEASE, thus dwSize is 0, which is 0 in both DWords and QWords):

Does VirtualAlloc return a 64-bit pointer on x64? The MASM application is 32-bit only though. Can it still return a 64-bit pointer? If yes, does MASM support 64-bit code at all, ie. can I access the 64-bit register?

Lars

[ToutEnMasm]

Masm can return a qword,no problem.
You have just to make a test.
Rewrite the prototype , put a :qword instead of a dword and if it work,you win

[ecube]

Or use the GoAsm version of Easycode and you don't need ANY protos, 0. Also you don't need any 64bit libs to link too.

[4C617273H]

Hello,

is it possible at all that VirtualAlloc returns a 64-bit pointer to a 32-bit executable on a x64 os? Wouldn't many Win32 applications not run then?

I don't want to derail this topic, thus I'm not going to go far deeper into GoAsm than this: it seems I cannot use typedefs to make it clearer for variables what they are. This would mean making my code barer and possibly more difficult to understand thus I am reluctant to use GoAsm (Assembly doesn't have types, only byte lengths, so I don't quite understand the decision to not support text replacements (which typedefs basically are)). Nevertheless I might switch to GoAsm.

Thanky you!!

Lars

[ToutEnMasm]

Or use the GoAsm version of Easycode and you don't need ANY protos, 0. Also you don't need any 64bit libs to link too.

Did you think really than an IDE can replace ALL the SDK ?

[GregL]

4C617273H,

32-bit programs run under the WOW64 subsystem on 64-bit Windows, WOW64 is an x86 emulator.  32-bit programs cannot access 64-bit registers when running on 64-bit Windows.

If you assembled your program with a 32-bit assembler then VirtualAlloc returns a 32-bit pointer, even if its running on 64-bit Windows.

If you assembled your program with a 64-bit assembler, like ML64, then VirtualAlloc would return a 64-bit pointer when running on 64-bit Windows.

I'm not sure why your program is crashing on Windows 7 64-bit.  Does it crash on Windows 7 32-bit?

[4C617273H]

Hi, thanks for the insight!

I used 32-bit ML (from the MASM 10 SDK). I don't have a 32-bit Windows 7, thus I can't test it there.

Lars

[4C617273H]

I got access to a 32-bit Windows 7 Home Premium and the application runs fine and a VirtualFree works as intended.

This seems to be a x64 issue (of 32-bit code). Anyone who knows the cause or has an idea?

I also converted to a hand-coded gui (no EasyCode resources anymore) and used JWasm and polink (in preparation for a 64-bit version).

[4C617273H]

I had 2 lines commented-out somewhere above the invoke of VirtualFree. Adjusting the line number of the crash properly leads to 2 lines below the invoke of VirtualFree.

This is where the culprit is. I forgot that a register could get scrapped when invoking VirtualFree. 32-bit Windows VirtualFree apparently doesn't touch or saves the register (ecx). 64-bit Windows VirtualFree using fastcall touches the register obviously.

I wrote to the assumed pointer in ecx and the application crashes. Pushing and Popping the register appropriately solved the issue.

Keep calm and thank you to all of you for your help!

Kind Regards

Lars