We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you a podcast all about Citrix Workspace, moving to the cloud, and analytics & intelligence. Episode 2 coming soon!Listen Now

x

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

pepr
pepr asked
on
Medium Priority
385 Views
Last Modified: 2010-04-24
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.
Comment
Watch Question

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..

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts
CERTIFIED EXPERT

Author

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.
Done. Added a copy of the comments at the pointer question to claim points.
CERTIFIED EXPERT

Author

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?
CERTIFIED EXPERT

Author

Commented:
Well, the problem seems more nasty. Anyway, your answer may bye useful for those who really search it.
CERTIFIED EXPERT

Author

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.
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!
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.