Managed Code From Unmanaged Code Issues On Vista

  • Thread starter Thread starter viperx1967
  • Start date Start date
V

viperx1967

We are having an issue with an application we are developing. We have a
Legacy COM DLL in C++ that we have converted to Visual Studio 2008. This COM
DLL has methods that are calling Managed C# assemblies as pass thru to
support legacy applications in an effort to move our code to the new Code
base. Our COM Object can be instantiated on Windows XP in any COM supported
environment using Visual C++, Visual Basic, ASP.NET or ASP and works without
any issues or throwing any exceptions. When we use the object on a Vista
Machine the method fails only when it is used in a Classic ASP page. We are
initializing the Managed code in the Unmanaged code using
gcroot<MYOBJ::FOOBAR^> myObj; on the constructor, when we create an instance
of the object is when it seems to fail. We have attempted creating our
instance by using myObj = gcnew MYOBJ::FOOBAR(); in the constructor but this
caused the object to fail on CreateObject, this was moved into the calling
method. Now the object is created but now fails on the method call. We have
attempted to instanciate it using myOBJ = gcnew MYOBJ:FOOBAR(); and gcnew
MYOBJ::FOOBAR; both work in Windows XP but do not work on Vista. All
assemblies are in the same directory together and have permissions set to
access all the files.
 
HI viperx1967,
We are having an issue with an application we are developing. We have
a Legacy COM DLL in C++ that we have converted to Visual Studio 2008.
This COM DLL has methods that are calling Managed C# assemblies as
pass thru to support legacy applications in an effort to move our
code to the new Code base. Our COM Object can be instantiated on
Windows XP in any COM supported environment using Visual C++, Visual
Basic, ASP.NET or ASP and works without any issues or throwing any
exceptions. When we use the object on a Vista Machine the method
fails only when it is used in a Classic ASP page. We are initializing
the Managed code in the Unmanaged code using gcroot<MYOBJ::FOOBAR^>
myObj; on the constructor, when we create an instance of the object
is when it seems to fail. We have attempted creating our instance by
using myObj = gcnew MYOBJ::FOOBAR(); in the constructor but this
caused the object to fail on CreateObject, this was moved into the
calling method. Now the object is created but now fails on the method
call. We have attempted to instanciate it using myOBJ = gcnew
MYOBJ:FOOBAR(); and gcnew MYOBJ::FOOBAR; both work in Windows XP but
do not work on Vista. All assemblies are in the same directory
together and have permissions set to access all the files.
Click to expand...

What exception do you get? Error code and error message would be of
interest.

My first guess is that the proxy/stub registration is incomplete so that
when
marshaling gets necessary your calls start failing. That could be a wrong
setup
which places the proxy/stub registration into the registry of the installing
user
instead of the machine. It could be a missing registration all together and
your
other workings apps just get along because marshaling does not come into
play.

You might want to debug the line of code which throws the exception and use
ProcessMonitor http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
to see which registry and or file system calls fail at that time. You should
monitor
w3wp.exe which hosts your ASP or ASP.NET app.
 
The only exception that is thrown is from IIS 0x800101805 and this is only
thrown on Vista. In XP everything works as advertised with no issues, we were
able to narrow it down to the line where it creates the managed object
itself. And this only happens in Classic ASP on Vista Only. In visual basic,
visual C++ , Visual C# all execute the code normally without issues. Other
then that I am at a loss, we had a theory it might be related to permissions
to the managed assembly but we have adjusted all permissions for the IIS User
accounts on Vista giving full access rights then was going to back off to
determine what the problem was, but yet when given full Admin rights the
issue still exists.

Will continue troubleshooting today and use the tool you suggested prior to
turning the Vista machine into a boat Anchor....
 
Hi viperx1967,
The only exception that is thrown is from IIS 0x800101805 and this is
Click to expand...

that is not a valid error code. 0x8001 should be followed by 4 digits
only. Could you please post the correct number.

Is it 0x80010108? That translates to "The object invoked has disconnected
from its clients.". For an inprocess COM object it typically tells you that
your object's code crashed..

You could use OutputDebugString in your C++ code and
System.Diagnostics.Debug.WriteLine in your managed code (remember
to build and use the debug configuration to get the Debug-Output working)
to see how far your object's code gets. Use DebugView to catch the output.
Run Debug View "As Admin" and enable Capture Global Win32 to get
output from the IIS processes.

You could attach the VS debugger to w3wp.exe as well and single step
your code. Make sure to run VS "As Admin" and attach with native and
managed debugging to debug both your native and managed code.
...we were able to narrow it down to the line where it creates
the managed object itself. And this only happens in Classic ASP on
Vista Only
Click to expand...

You speak of running IIS on Vista and not of your browser running
on vista, correct?
In visual basic, visual C++ , Visual C# all execute the
code normally without issues. Other then that I am at a loss
Click to expand...

It might be due to some parameter limitations in ASP which are basically
just VBScript files. So all your COM objects are used through IDispatch.
To simulate that you might want to check how your object behaves
when used in a vbs file. Just put your crashing code in a vbs file and
see if it can be executed there.
 
Sorry my bad the error is 0x80004005 which equates to Unspecified error. In
further testing we have created a completely new COM dll and new .NET object
put the most simplistic method that returns only a string. Once again the COM
object creates the .NET assembly calls the method and returns the value
properly to ASP on Windows XP but still fails on Vista. In further research
we thought maybe it might be due to the assembly not being strongly typed and
put in the GAC, so we strongly typed the assembly and then put it in the GAC
with the same result. Works on XP fails on XP. All assemblies were installed
on the Vista Machine with the "Real" Admin not the standard Administrator
that is default. This has not helped, we are now moving to another Vista
machine in case the one we are testing on is corrupt in some manner. To
replicate the issue create a simple COM dll in C++ using ATL add a Simple
Object interface and 1 method parameters and return values not important.
Create a .Net Assembly add a method that returns a value. In the C++ COM dll
use the #using "myassembly.dll" namespace myassembly; to import the assembly
then in your COM method create an instance of the .Net assembly and call the
method on the Assembly. Our sample looks like this:
#using <mscorlib.dll>
#include <vcclr.h>
using namespace System;
#using "MyTestobject.dll"
using namespace MyTestObject;

In my Method I use:
MyTestObject::ImaTesting^ objTest = gcnew MyTestObject::ImaTesting();
System::String^ myString = objTest->ReturnMoFO("This is a Test");
CString str = CString(myString);
*bstrResult = str.AllocSysString();
return S_OK;
My Method is defined as follows:
STDMETHODIMP CTestObject::CallMe(BSTR *bstrResult)


The .NET assembly has no more code than this:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace MyTestObject
{
public class ImaTesting
{
public string ReturnMeMoFO(string strvalue)
{
return "*****" + strvalue + "******";
}
}
}

Not much too it but still cannot get it to work on Vista we broke it down to
the most primary functionality with both objects with no success.
 
Back
Top