• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 359
  • Last Modified:

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.
0
pepr
Asked:
pepr
  • 4
  • 3
1 Solution
 
nakul_vachhrajaniCommented:
Yes, Windows 2003 SP1 and above (includes R2) can restrict the access to COM components.
To solve this, here's what you need to do:
You need to provide access rights for Local/Remote access & launch/activiation permissions. Here's how:

1. On the Win2k3 server, go to Start -> Settings -> Control Panel -> Administrative Tools -> Component Services
2. Under Console Root, go to Component Services -> Computers -> My Computer
3. Right Click on My Computer, click on Properties
4. Navigate to the COM Security Tab
5. Click on Edit Limits and Add the list of users who would be accessing the COM Services
6. Allow both 'Local' and 'Remote' access
7. Go back to the COM Security Tab and Click on Edit Limits
8. Add the list of users who would be accessing the COM Services
9. Provide Local & Remote Launch/Activation rights
10. Restart the concerned COM Service by navigating to COM+ Applications -> Your app -> (Right Click) -> Stop -> (Right click) -> Start

You should now be able to access your COM components without any errors..
0
 
peprAuthor Commented:
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
http://www.experts-exchange.com/Programming/Programming_Platforms/Win_Prog/Q_22046535.html

Thanks.
0
 
nakul_vachhrajaniCommented:
Done. Added a copy of the comments at the pointer question to claim points.
0
Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

 
peprAuthor Commented:
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?
0
 
peprAuthor Commented:
Well, the problem seems more nasty. Anyway, your answer may bye useful for those who really search it.
0
 
peprAuthor Commented:
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.
0
 
nakul_vachhrajaniCommented:
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!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now