64bit COM Object causes CoCreateInstance to crash

[swhite]

Hi

I created a simple 64bit COM object with one method for testing purposes. When I try to create the COM object using CoCreateInstance_ in PB 6.12 64bit it crashes the debugger and I never receive a result. It works if I use PB 5.73 64 bit. I also works if I compile it as a 32 bit MT dll and use PB 6.12 32bit. So there is something wrong with PB 6.12 64bit.

I can supply all the files needed for testing. The COM object has one method called Test. You call this method with any string and the return value should show you the string you passed to the method.

Code: Select all

Macro DEFINE_GUID(Name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8)
  Global Name.GUID
  
  Name\Data1    = l
  Name\Data2    = w1
  Name\Data3    = w2
  Name\Data4[0] = b1
  Name\Data4[1] = b2
  Name\Data4[2] = b3
  Name\Data4[3] = b4
  Name\Data4[4] = b5
  Name\Data4[5] = b6
  Name\Data4[6] = b7
  Name\Data4[7] = b8
EndMacro
; 
#CLSCTX_INPROC_SERVER  = $01

; COMTest
;
;{CA49C824-2FFA-4AF4-ADA3-D06A3CB9DBC6}
DEFINE_GUID(CLSID_comtest, $CA49C824, $2FFA, $4AF4, $AD, $A3, $D0, $6A, $3C, $B9, $DB, $C6)
;{85A1E677-278F-469C-BAF5-0ADCC3966678}
DEFINE_GUID(IID_comtest,   $85A1E677, $278F, $469C, $BA, $F5, $0A, $DC, $C3, $96, $66, $78)
Interface comTest Extends IDispatch
   Test(String.p-bstr, ReturnValue.i)
EndInterface
 
Global *goVFP.comTest,*ReturnPtr
Debug CoInitializeEx_(0, #COINIT_MULTITHREADED) 
Debug CoCreateInstance_(@CLSID_comtest, 0, #CLSCTX_INPROC_SERVER, @IID_comTest, @*goVFP)
*goVFP\Test("Received",@*ReturnPtr)
Debug PeekS(*ReturnPtr,-1,#PB_Unicode)

Simon

[Fred]

Fixed.

[swhite]

Hi

I reran the code using PB 6.20beta 2 and got the same error.






https://www.dciphercomputing.com/updates/comtest.zip

[infratec]

I tried to test this too, but I don't have such a class installed.

What needs to be installed to test it with your CLSID and IID?

[swhite]

Hi

The files in the zip file need to be placed in the folder with your code and then register the dll using

c:\windows\system32\Regserv32.exe somefolder\comtest.dll.

It actually does not matter where you put the files as long as you register them. Obviously "somefolder" has to be replaced with the path to your actual location. You should get a dialog box that says the registration succeeded.

Simon

[Fred]

Do you have an example in another language which show the comtest.dll lib is properly loaded ? PB 6.10+ use high entropy by default for 64-bit exe so may be the pb is in the dll as well.

[Fred]

You can try with this to see if it change something:

Code: Select all

Import "/dynamicbase:no"
EndImport

Import "/HIGHENTROPYVA:no"
EndImport
 
Macro DEFINE_GUID(Name, l, w1, w2, b1, b2, b3, b4, b5, b6, b7, b8)
  Global Name.GUID
  
  Name\Data1    = l
  Name\Data2    = w1
  Name\Data3    = w2
  Name\Data4[0] = b1
  Name\Data4[1] = b2
  Name\Data4[2] = b3
  Name\Data4[3] = b4
  Name\Data4[4] = b5
  Name\Data4[5] = b6
  Name\Data4[6] = b7
  Name\Data4[7] = b8
EndMacro
; 
#CLSCTX_INPROC_SERVER  = $01

; COMTest
;
;{CA49C824-2FFA-4AF4-ADA3-D06A3CB9DBC6}
DEFINE_GUID(CLSID_comtest, $CA49C824, $2FFA, $4AF4, $AD, $A3, $D0, $6A, $3C, $B9, $DB, $C6)
;{85A1E677-278F-469C-BAF5-0ADCC3966678}
DEFINE_GUID(IID_comtest,   $85A1E677, $278F, $469C, $BA, $F5, $0A, $DC, $C3, $96, $66, $78)
Interface comTest Extends IDispatch
   Test(String.p-bstr, ReturnValue.i)
EndInterface
 
Global *goVFP.comTest,*ReturnPtr
Debug CoInitializeEx_(0, #COINIT_MULTITHREADED)
Debug CoCreateInstance_(@CLSID_comtest, 0, #CLSCTX_INPROC_SERVER, @IID_comTest, @*goVFP)
Debug "*goVFP = "+*goVFP
Debug @*ReturnPtr
*goVFP\Test("Received", @*ReturnPtr)
Debug PeekS(*ReturnPtr,-1,#PB_Unicode)

[swhite]

Hi Fred

The version of code you posted works perfectly in PB 6.20 beta 2.

I also tested the dll in Visual FoxPro Advanced 64bit version and it worked as shown in the screen shot.



Simon

[Fred]

Then it's because your DLL doesn't support ASRL (random memory allocation using all 64-bit range meaning than pointer can be greatly above 32-bit). Visual FoxPro probably create an exe with ASRL disabled as well. If you are the author of the DLL, you should check if you have proper types for pointers/handles (ie: not .l)

[swhite]

It is nice to know there is a solution. Should I assume that I need to set these imports in any 64bit COM dll going forward? Is there some place in the documentation to where this can be documented?

Thanks,
Simon

[Fred]

If your DLL doesn't support ASLR, you will need these flags, but it means that you are disabling a major Windows security feature. So it's actually a problem in your DLL as it's not compiled with ASLR as it should be (PB automatically create ASRL dll since 6.10).

More info here, especially the second answer: https://chatgpt.com/share/6787ca26-5c98 ... 9e7f68e50c

[swhite]

Hi Fred

I will discuss this with the developers of the VFP Advanced to see if they can enable ASLR. Thank-you for this information and all your help.

Simon