Re: Can Win2003 restrict the rights to call a COM method? (C++ and simple component created by Visual FoxPro 6)
Petr
I have had the same problem using a Winmgmts object created within Foxpro,
from which you are supposed to be able to run script style queries to amoung
other things create process objects that have information and methods
relating to currently running processes on the machine.if i use one of the
methods on this object within our Terminal server 2003 it works fine for me
as an administrator, but people who sign on as users get the c00005 errors,
i have not tried this with power users yet, as i have found a work around.
(see my previous posts about killing a process). From the responses i got to
these, and my own testing, i am convinced the problem is to do with Security
on the terminal server environment, and in my opinion it's a bug. I hope
this helps, and will be interested to see if you find a solution, as it
caused me a bit of grief as well.
"Petr Prikryl" <prikryl at skil dot cz> wrote in message
news:%23JXADuo$GHA.3836@TK2MSFTNGP02.phx.gbl...
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 (about 120 kB). 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.
pepr
--
Petr Prikryl (prikryl at skil dot cz)