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 (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)

Mark
Thu Nov 02 09:47:15 CST 2006

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

Bruno
Thu Nov 02 11:32:06 CST 2006

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

Hi,
I don't know FoxPro or Win2003, but you can manage the COM security settings
of a COM object via dcomcnfg
creating instances and calling methods have different security settings, so
that might be a cause of the problem.
Other than messed up settings I would not know what might cause your
problem.

--

Kind regards,
Bruno van Dooren
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"

Tim
Thu Nov 02 23:45:50 CST 2006

"Petr Prikryl" <prikryl at skil dot cz> wrote:
>
>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?
>...
>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.
>....
>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.

No. EXCEPTION_ACCESS_VIOLATION does not refer to privacy or security or
access right. Instead, it refers to a CPU instruction that tries to access
an invalid address. The Intel documentation calls this a "general
protection fault". Dereferencing a null pointer will cause a C0000005
exception.

You need to catch this in a debugger and trace back to figure out which
instruction is failing. You aren't flushing the output to cout, so don't
necessarily know that it hasn't executed that statement.

You're sure everybody is using the same versions? FoxPro runs correctly on
the failing system? All of FoxPro was installed normally?
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Petr
Fri Nov 03 04:49:33 CST 2006


"Tim Roberts" wrote...
> "Petr Prikryl" <prikryl at skil dot cz> wrote:
>>
>>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?
>>[...]
>>SE_exception: code = 0xc0000005 (EXCEPTION_ACCESS_VIOLATION)
>>tstFoxApp -- version -1
>>press Ctrl+C ...
>
> No. EXCEPTION_ACCESS_VIOLATION does not refer to privacy or security or
> access right. Instead, it refers to a CPU instruction that tries to
> access
> an invalid address. The Intel documentation calls this a "general
> protection fault". Dereferencing a null pointer will cause a C0000005
> exception.
>
> You need to catch this in a debugger and trace back to figure out which
> instruction is failing. You aren't flushing the output to cout, so don't
> necessarily know that it hasn't executed that statement.

I cannot debug it on that computer (customer's server). When running exactly
the same binaries elswhere, it runs fine. Even when the binary is launched
on another computer from that server in the LAN (i.e. the identical binary
that
fails when launched on the server).

Only the "brake" just before then do of program does not flush the buffer.
You can notice using endl that flushes all important.

> You're sure everybody is using the same versions? FoxPro runs correctly
> on
> the failing system? All of FoxPro was installed normally?

The runtime vfp6r.dll was successfully registered. I will think about how
to test it on the server -- without using that component.

Thanks,
pepr

Petr
Fri Nov 03 04:57:47 CST 2006

"Bruno van Dooren [MVP VC++]"
>> 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?
>
> I don't know FoxPro or Win2003, but you can manage the COM security
> settings of a COM object via dcomcnfg
> creating instances and calling methods have different security settings,
> so that might be a cause of the problem.

I know very little about the dcomcnfg. Their administrator used it
to set some COM rights for another application that runs on the server
(specifically SAP Business One). It seems to me that the right are not
bound to specific components. The truth is that the failing one
was installed and registered AFTER the rights were set.

Could you be more specific, where to play with security settings
for creating instances versus the settings for calling?

Thanks,
pepr

Bruno
Fri Nov 03 05:15:28 CST 2006

> I know very little about the dcomcnfg. Their administrator used it
> to set some COM rights for another application that runs on the server
> (specifically SAP Business One). It seems to me that the right are not
> bound to specific components. The truth is that the failing one
> was installed and registered AFTER the rights were set.

Open dcomcnfg, and expand computers->my computer->dcom config.
there you will se a list of all registered COM objects.
rightclick your specific component, and check its different security
settings.

If there are specific settings configured, they will be used.
If default is selected, right-click 'my computer' in the same tree and check
the default settings.
For the meaning of the different settings you best use google to find out
more about each individual setting.

--

Kind regards,
Bruno van Dooren
bruno_nos_pam_van_dooren@hotmail.com
Remove only "_nos_pam"

Leemi
Fri Nov 03 15:53:47 CST 2006

Hi Petr:

Have you looked at Data Execution Protection (DEP) on the Windows 2003
Server?

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
http://support.microsoft.com/default.aspx?scid=kb;EN-US;875352

You might want to exclude the tstfoxapp.exe from DEP on the Windows 2003
Server machine.

I hope this helps.

This posting is provided "AS IS" with no warranties, and confers no rights.

Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell

*-- VFP9 HAS ARRIVED!! --*
Read about all the new features of VFP9 here:
http://msdn.microsoft.com/vfoxpro/

*--Purchase VFP 9.0 here:
http://www.microsoft.com/PRODUCTS/info/product.aspx?view=22&pcid=54787e64-52
69-4500-8bf2-3f06689f4ab3&type=ovr

Keep an eye on the product lifecycle for Visual FoxPro here:
http://support.microsoft.com/gp/lifeselectindex
- VFP5 Mainstream Support retired June 30th, 2003
- VFP6 Mainstream Support retired Sept. 30th, 2003


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

Petr
Mon Nov 06 03:53:39 CST 2006

Firstly, further observation. I have created also the other testing
applications.
One of them used FoxPro runtime directly (vfp6r.dll), the other used
another COM component that did not depend on FoxPro runtime.
Both applications worked fine. The conclusion was that the problem
is caused only by a component created by Visual FoxPro 6.

I was lucky -- Lee Mitchell pointed out the following article/mechanism...

"Lee Mitchell"
> Have you looked at Data Execution Protection (DEP) on the Windows 2003
> Server?
> 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
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;875352
>
> You might want to exclude the tstfoxapp.exe from DEP on the Windows 2003
> Server machine.

So, I have added the application that uses the component to the list
of exceptions for the DEP mechanism AND IT WORKS !!!

Thanks Lee,
Petr


"Petr Prikryl"...
> "Tim Roberts" wrote...
>> "Petr Prikryl" <prikryl at skil dot cz> wrote:
>>>
>>>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?
>>>[...]
>>>SE_exception: code = 0xc0000005 (EXCEPTION_ACCESS_VIOLATION)
>>>tstFoxApp -- version -1
>>>press Ctrl+C ...
>>
>> No. EXCEPTION_ACCESS_VIOLATION does not refer to privacy or security or
>> access right. Instead, it refers to a CPU instruction that tries to
>> access
>> an invalid address. The Intel documentation calls this a "general
>> protection fault". Dereferencing a null pointer will cause a C0000005
>> exception.
>>
>> You need to catch this in a debugger and trace back to figure out which
>> instruction is failing. You aren't flushing the output to cout, so don't
>> necessarily know that it hasn't executed that statement.
>
> I cannot debug it on that computer (customer's server). When running
> exactly
> the same binaries elswhere, it runs fine. Even when the binary is launched
> on another computer from that server in the LAN (i.e. the identical binary
> that
> fails when launched on the server).
>
> Only the "brake" just before then do of program does not flush the buffer.
> You can notice using endl that flushes all important.
>
>> You're sure everybody is using the same versions? FoxPro runs correctly
>> on the failing system? All of FoxPro was installed normally?
>
> The runtime vfp6r.dll was successfully registered. I will think about how
> to test it on the server -- without using that component.
>
> Thanks,
> pepr

Leemi
Mon Nov 06 09:51:59 CST 2006

Hi Petr:

Good morning.

I am glad the DEP suggestion worked for you. This is great news.

By the way, you are using VFP 6.0. This is no longer supported by
Microsoft. You really should consider upgrading to VFP 9.0. While it
would not have made any difference in this issue, you should be using a
supported version.

Call you local subsidiary for purchase information.


This posting is provided "AS IS" with no warranties, and confers no rights.

Sincerely,
Microsoft FoxPro Technical Support
Lee Mitchell

*-- VFP9 HAS ARRIVED!! --*
Read about all the new features of VFP9 here:
http://msdn.microsoft.com/vfoxpro/

*--Purchase VFP 9.0 here:
http://www.microsoft.com/PRODUCTS/info/product.aspx?view=22&pcid=54787e64-52
69-4500-8bf2-3f06689f4ab3&type=ovr

Keep an eye on the product lifecycle for Visual FoxPro here:
http://support.microsoft.com/gp/lifeselectindex
- VFP5 Mainstream Support retired June 30th, 2003
- VFP6 Mainstream Support retired Sept. 30th, 2003

>Firstly, further observation. I have created also the other testing
>applications.
>One of them used FoxPro runtime directly (vfp6r.dll), the other used
>another COM component that did not depend on FoxPro runtime.
>Both applications worked fine. The conclusion was that the problem
>is caused only by a component created by Visual FoxPro 6.

>I was lucky -- Lee Mitchell pointed out the following article/mechanism...

"Lee Mitchell"
> Have you looked at Data Execution Protection (DEP) on the Windows 2003
> Server?
> 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
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;875352
>
> You might want to exclude the tstfoxapp.exe from DEP on the Windows 2003
> Server machine.

>So, I have added the application that uses the component to the list
>of exceptions for the DEP mechanism AND IT WORKS !!!

>Thanks Lee,
> Petr


"Petr Prikryl"...
> "Tim Roberts" wrote...
>> "Petr Prikryl" <prikryl at skil dot cz> wrote:
>>>
>>>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?
>>>[...]
>>>SE_exception: code = 0xc0000005 (EXCEPTION_ACCESS_VIOLATION)
>>>tstFoxApp -- version -1
>>>press Ctrl+C ...
>>
>> No. EXCEPTION_ACCESS_VIOLATION does not refer to privacy or security or
>> access right. Instead, it refers to a CPU instruction that tries to
>> access
>> an invalid address. The Intel documentation calls this a "general
>> protection fault". Dereferencing a null pointer will cause a C0000005
>> exception.
>>
>> You need to catch this in a debugger and trace back to figure out which
>> instruction is failing. You aren't flushing the output to cout, so don't
>> necessarily know that it hasn't executed that statement.
>
> I cannot debug it on that computer (customer's server). When running
> exactly
> the same binaries elswhere, it runs fine. Even when the binary is launched
> on another computer from that server in the LAN (i.e. the identical
binary
> that
> fails when launched on the server).
>
> Only the "brake" just before then do of program does not flush the buffer.
> You can notice using endl that flushes all important.
>
>> You're sure everybody is using the same versions? FoxPro runs correctly
>> on the failing system? All of FoxPro was installed normally?
>
> The runtime vfp6r.dll was successfully registered. I will think about how
> to test it on the server -- without using that component.
>
> Thanks,
> pepr