Link to home
Start Free TrialLog in
Avatar of pepr
pepr

asked on

Can Win2003 restrict the rights to call a COM method? (C++ and simple component created by Visual FoxPro 6)

Sorry, if it is not the right channel. However, I need someone who knows Windows, C++, COM and possibly FoxPro...

Summary: We have observed a situation, when the application can create instance of the component but it fail when a method of the component is called. It happens when the application is executed on one specific Windows 2003 R2 Small Business Server. However, it runs on another Win2003 SBS without problems. Are there any rights that could restrict calling methods of components?

Our application is written in C++ (MS VC++ 7.1, but does not use .NET extensions) and it calls a COM component that was created using Visual FoxPro 6. Both the application and also the component are compiled from our sources. The component is registered using regsvr32 utility in the simplest possible way. The application need not to be installed in any special way -- just executed.

Here are the important lines from the C++ source:

long GetAPSfoxVersion()
{
    FOX::ItstfoxclassPtr spTstFox;    // The instance was not created yet.
    long result = -1;                        // The value to be obtained by calling the component -- init.
    HRESULT hr = spTstFox.CreateInstance( __uuidof(FOX::TSTfoxClass) );   // THIS SUCCEEDS!
    ...
            _variant_t v(spTstFox->dllversion());                                              // THIS FAILS
            result = v.lVal;   // remember the result
    ...
    spTstFox = NULL;  // i.e. Release() the instance
    return result;
}

To reproduce the problem, I have created the bare-bone component (FoxPro) that contains only the called method, and the console application (C++), that calls the method and checks for the success/catch exceptions.

The FoxPro source contains just the following lines.
------------------
DEFINE CLASS TSTfoxClass AS CUSTOM OLEPUBLIC
    PROCEDURE DllVersion()
        RETURN 1
    ENDPROC
ENDDEFINE
------------------

The complete FoxPro/C++ sources and compiled binaries can be downloaded from URL http://www.skil.cz/test/tstFoxDll.zip.

I did not include the FoxPro 6 runtime and text dll (vfp6r.dll and vfp6renu.dll) to make the zip smaller. The tstFox.dll must be placed to the directory where the vfp6r.dll is and then registered. You can use the regTstDll.bat for the registration. Then execute the tstFoxApp.exe. If it works, you will observe this:

D:\Tools\tstFoxDll>tstFoxApp.exe
tstFoxApp: Before the call.
tstFoxApp: After the call.
tstFoxApp -- version 1
press Ctrl+C ...

However, on the nasty computer, you would observe the following:

tstFoxApp: Before the call.
tstFoxApp: Unhandled exception.
SE_exception: code = 0xc0000005 (EXCEPTION_ACCESS_VIOLATION)
tstFoxApp -- version -1
press Ctrl+C ...

It seems that Windows 2003 can restrict calling the component somehow. However, I am completely stupid in this area. We run such component and the application several years on say hundreds computes (servers and desktops) and nobody reported the problem. It could be the case that the problem is well known and they have better administrators to set the rights. Could you help, please?

Thanks for your time and experience.
ASKER CERTIFIED SOLUTION
Avatar of nakul_vachhrajani
nakul_vachhrajani

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of pepr
pepr

ASKER

nakul_vachhrajani: Thanks for the extremely fast answer. I cannot try it now, but if it works, I am going to accept it immediately. Add you comment also to another link to claim your points
https://www.experts-exchange.com/questions/22046535/Can-Win2003-restrict-the-rights-to-call-a-COM-method-C-and-simple-component-created-by-Visual-FoxPro-6.html

Thanks.
Done. Added a copy of the comments at the pointer question to claim points.
Avatar of pepr

ASKER

Well, but it does not work. The discussed rights were already set by their administrator because a client-server application that uses COM is already installed there. Please, could you explain better your point

10. Restart the concerned COM Service by navigating to COM+ Applications -> Your app -> (Right Click) -> Stop -> (Right click) -> Start

Our application is not client-server. The component is only used by the client to access some functionality. We try to run the application directly on the server through Terminal services access. But it is likely that it would behave the same if it were launched being physically present on the server. Can you reproduce the failure that I observe using the sample application that can be downloaded from our site?
Avatar of pepr

ASKER

Well, the problem seems more nasty. Anyway, your answer may bye useful for those who really search it.
Avatar of pepr

ASKER

I did solved my original question using the http://support.microsoft.com/?kbid=875352 "A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003". The problem was not observed with other components, only with the one created by Visual FoxPro 6. It seems that the resulting dll was the teaser for the DEP mechanism.
Hello, pepr!
Thanks for the updates on your problem. Sorry for not responding earlier as I was tied up with other assignments.

Anyway, thanks for posting the link to the solution of your problem - that would be added to my knowledge bank!

And, thanks for the points :)

Best of luck!