Develop Reference

32 bit unmanaged dll in 64 bit wrapper

I'm creating a wrapper from loading 32-bit unmanaged dll to execute in 64-bit environment. so my approach used this LegacyWrapper
[LegacyDllImport("ste.dll")]
public interface INativeMethods : IDisposable
{
[LegacyDllMethod(CallingConvention = CallingConvention.Winapi)]
IIntPtr ste_init_with_environment_info(string dirLocation, string language);
}
I'm calling this method as below
public IWrapperConfig Configuration
{
get
{
return _configuration ??= WrapperConfigBuilder.Create().TargetArchitecture(TargetArchitecture.X86).Build();
}
}
using var client = WrapperProxyFactory<INativeMethods>.GetInstance(Configuration);
_steHandle = client.ste_init_with_environment_info(steHomeDirectory, SystemProperties());
it seems works without exception but. When I call the function, as a result, I'm getting 0x0000000000000000 which should be something like 0x0186ad58 what causes the issue?
UPDATE
when I see the source code of LagacyWrapper see the serialization and deserialization as below using System.Runtime.Serialization.IFormatter
public void SendCallRequest(CallData callData)
{
_formatter.Serialize(_pipe, callData);
}
public CallResult ReceiveCallResponse()
{
CallResult callResult = (CallResult)_formatter.Deserialize(_pipe);
if (callResult.Exception != null)
{
throw callResult.Exception;
}
return callResult;
}

I'm not very familiar with LegacyWrapper, so this is based on conjecture.
From the blogpost introducing Legacy wrapper:
Since we can’t load 32bit code into our 64bit process, the idea is to create a separate executable for this task. It would somehow load a library, invoke a specific function and pass the results back to the caller.
Since your library runs in another process, returning a pointer to memory will probably not work. As far as I know there is no general way to know how much valid memory a pointer points to, so how would the wrapper know how much memory to copy? This might be possible to solve for some special cases, but I cannot find any documentation about the details of the serialization-process.
You might be able to define that the pointer should be marshalled to a structure. Otherwise you might want to post an issue at the legacyWrapper project page, to clarify the documentation if nothing else.

How to prevent function pointer created in managed code, and passed to unmanaged code, from getting garbage collected

I am using a library called muParserNET in my application. muParserNET is a function parsing library, and my application is calling it multiple times from different threads.
muParserNET consists of a C++ (unmanaged) dll with a managed C# wrapper. In this wrapper, it passes the pointer to an error handling routine to the unmanaged library on initialisation.
i.e. within the Parser class we have this function:
/// <summary>
/// Error handler. It loads the ParserError exception.
/// </summary>
private void ErrorHandler()
{
IntPtr ptrMessage = MuParserLibrary.mupGetErrorMsg(this.parserHandler);
string message = Marshal.PtrToStringAnsi(ptrMessage);
IntPtr ptrToken = MuParserLibrary.mupGetErrorToken(this.parserHandler);
string token = Marshal.PtrToStringAnsi(ptrToken);
string expr = this.Expr;
ErrorCodes code = (ErrorCodes)MuParserLibrary.mupGetErrorCode(this.parserHandler);
int pos = MuParserLibrary.mupGetErrorPos(this.parserHandler);
// lança a exceção
throw new ParserError(message, expr, token, pos, code);
}
Here is the initialisation of the parser object, in managed code. it happens on the last line of this function:
public Parser()
{
// inicializa o parser
this.parserHandler = MuParserLibrary.mupCreate(0);
// inicializa o dicionário com as variáveis
this.vars = new Dictionary<string, ParserVariable>();
// inicializa as listas de delegates
this.identFunctionsCallbacks = new List<ParserCallback>();
this.funcCallbacks = new Dictionary<string, ParserCallback>();
this.infixOprtCallbacks = new Dictionary<string, ParserCallback>();
this.postfixOprtCallbacks = new Dictionary<string, ParserCallback>();
this.oprtCallbacks = new Dictionary<string, ParserCallback>();
// inicializa o delegate de factory
this.factoryCallback = new ParserCallback(new IntFactoryFunction(this.VarFactoryCallback));
// ajusta a função de tratamento de erros
MuParserLibrary.mupSetErrorHandler(this.parserHandler, this.ErrorHandler);
}
On running this code, sporadically, on calls to evaluate functions (so sometime after initialisation of the object) I get this error:
A callback was made on a garbage collected delegate of type 'muParserNET!muParserNET.ErrorFuncType::Invoke'
ErrorFuncType is the type of this.ErrorHandler passed above using MuParserLibrary.mupSetErrorHandler.
My understanding is that since the error handler function is not used after its pointer is passed to unmanaged code, it gets garbage collected. How can I prevent this from happening?
More information based on the first reply:
The parser object is created inside a calculation routine which may be running simultaneously on up to 8 separate threads, typically. The object is created and disposed of within the calculation routine. For this reason, I didn't want to create the parser object as static as it would limit me to only one thread using the parser at any one time.

Can't comment with < 50 reputation, but I don't have a clear answer, only hints.
So you are saying there can be multiple threads which all call "MuParserLibrary.mupSetErrorHandler"? That already seems wrong. Do the specs of the library declare mupSetErrorHandler, or in fact any part of the library as "thread safe"?
Imagine this scenario:
Thread A sets the error handler, starts work.
Thread B sets error handler, starts work. The current error handler in the library now has a reference to the error handler for thread-B.
Thread B finishes work earlier than A.
A produces an error.
Library still has a reference to error handler from B, which is now invalid.
From your example it's not clear whether B can stop earlier than A, but if there is another scenario possible getting you into such a state, that's what would happen.
I think you'd need a more global error handler that the library always uses. But if you have no way of tracking the source (thread) of the error, or the library is just not made for multi-threaded use, it won't be of much help.
If this is the typical "static class C# wrapper around native C DLL" library thing, I'm afraid that that's the case.
You'd need several objects of the library state (with its references to error handlers and such), too, i.e. one per thread. If that library can't do that, the way you are doing things now won't work.

I figured this out in the end.
I create two class variables: one for function handler, and one for a GChandle:
private ErrorFuncType ptrErrHandler;
private GCHandle gchErrorHandler;
Then use GCHandle to prevent the function pointer from being garbage collected before passing it to unmanaged code:
ptrErrHandler = this.ErrorHandler;
this.gchErrorHandler = GCHandle.Alloc(ptrErrHandler);
MuParserLibrary.mupSetErrorHandler(this.parserHandler, ptrErrHandler);
Finally in the class destructor you need to free the GCHandle to allow it to get garbage collected:
gchErrorHandler.Free();

Unmanaged code with file access fails in a .NET/C# application

Here's the scenario I am confronted with:
in a simple DLL, written in C, there are functions which access files, for example:
DLL_EXPORT void Virt_Hello(void) {
FILE *f = fopen("Hello_world", "w");
if (f) {
fprintf(f, "Hello world!\n");
}
fclose(f);
}
in the managed code:
[SuppressUnmanagedCodeSecurity]
[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
private delegate void Virt_HelloDelegate();
private IntPtr m_helloPtr;
m_helloPtr = GetProcAddress(m_libraryPtr, "Virt_Hello");
Virt_Hello = Virt_HelloDelegate)Marshal.GetDelegateForFunctionPointer(m_helloPtr, typeof(Virt_HelloDelegate));
and later, this function is called as:
[SecurityPermission(SecurityAction.LinkDemand, UnmanagedCode = true)]
public void Hello()
{
Virt_Hello();
}
I've been reading for the last couple of days pretty much everything I could find on this topic however it still doesn't work: the file is not open, and the calling managed code/process just hangs - no exceptions are thrown either.
Tried StdCall calling convention, changed several parameters on the SecurityPermission attribute - to no avail. I've even made sure all assembly dependencies are signed.
Of course I would prefer to integrate it through C++/CLI instead of PInvoke-ing however the DLL is a blackbox for me.
Any help or suggestion how to go forward would be much appreciated.
I'm pretty sure I'm missing something obvious but right now I just can't see it.
My best regards to the community!

Why cannot I cast my COM object to the interface it implements in C#?

I have this interface in the dll (this code is shown in Visual Studio from metadata):
#region Assembly XCapture.dll, v2.0.50727
// d:\svn\dashboard\trunk\Source\MockDiagnosticsServer\lib\XCapture.dll
#endregion
using System;
using System.Runtime.InteropServices;
namespace XCapture
{
[TypeLibType(4160)]
[Guid("XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX")]
public interface IDiagnostics
{
[DispId(1)]
void GetStatusInfo(int index, ref object data);
}
}
So I created a COM server with such class:
[ComVisible(true)]
[Guid(SimpleDiagnosticsMock.CLSID)]
[ComDefaultInterface(typeof(IDiagnostics))]
[ClassInterface(ClassInterfaceType.None)]
public class SimpleDiagnosticsMock : ReferenceCountedObject, IDiagnostics
{
public const string CLSID = "281C897B-A81F-4C61-8472-79B61B99A6BC";
// These routines perform the additional COM registration needed by
// the service. ---- stripped from example
void IDiagnostics.GetStatusInfo(int index, ref object data)
{
Log.Info("GetStatusInfo called with index={0}, data={1}", index, data);
data = index.ToString();
}
}
Server seems to work fine, and I am able to use the object from a VBScript. But then I try to use it from another C# client:
[STAThread]
static void Main(string[] args)
{
Guid mockClsId = new Guid("281C897B-A81F-4C61-8472-79B61B99A6BC");
Type mockType = Type.GetTypeFromCLSID(mockClsId, true);
IDiagnostics mock = (IDiagnostics)Activator.CreateInstance(mockType);
//var diag = mock as IDiagnostics;
object s = null;
mock.GetStatusInfo(3, ref s);
Console.WriteLine(s);
Console.ReadKey();
}
And it fails with
Unable to cast COM object of type 'System.__ComObject' to interface
type 'XCapture.IDiagnostics'. This operation failed because the
QueryInterface call on the COM component for the interface with IID
'{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}' failed due to the following
error: No such interface supported (Exception from HRESULT: 0x80004002
(E_NOINTERFACE)).
What am I doing wrong?
I have also tried to use InvokeMember, and that kinda worked except that I wasn't able to get the ref-returned data parameter.
EDIT: added STAThread attribute to my Main procedure. This does not solve the issue, but you really should use STAThread with COM unless you're absolutely sure you don't need it. See Hans Passant's answer below.

This exception can be a DLL Hell problem. But the simplest explanation is for what's missing from your snippet. Your Main() method is missing the [STAThread] attribute.
That's an important attribute that matters when you use COM objects in your code. Most of them are not thread-safe and they require a thread that's a hospitable home for code that cannot support threading. The attribute forces the state of the thread, the one you can set explicitly with Thread.SetApartmentState(). Which you can't do for the main thread of an app since Windows starts it, so the attribute is used to configure it.
If you omit it then you the main thread joins the MTA, the multi-threaded apartment. COM is then forced to create a new thread to give the component a safe home. Which requires all calls to be marshaled from your main thread to that helper thread. The E_NOINTERFACE error is raised when COM cannot find a way to do that, it requires a helper that knows how to serialize the method arguments. That's something that needs to be taken care of by the COM developer, he didn't do that. Sloppy but not unusual.
A requirement of an STA thread is that it also pumps a message loop. The kind you get in a Winforms or WPF app from Application.Run(). You don't have one in your code. You might get away with it since you don't actually make any calls from a worker thread. But COM components tend to rely on the message loop to be available for their own use. You'll notice this by it misbehaving, not raising an event or deadlocking.
So start fixing this by applying the attribute first:
[STAThread]
static void Main(string[] args)
{
// etc..
}
Which will solve this exception. If you have the described event raising or deadlock problems then you'll need to change your application type. Winforms is usually easy to get going.
I cannot otherwise take a stab at the mocking failure. There are significant deployment details involved with COM, registry keys have to be written to allow COM to discover components. You have to get the guids right and the interfaces have to be an exact match. Regasm.exe is required to register a .NET component that's [ComVisible]. If you try to mock an existing COM component, and got it right, then you'll destroy the registration for the real component. Not so sure that's worth pursuing ;) And you'll have a significant problem adding a reference to the [ComVisible] assembly, the IDE refuses to allow a .NET program to use a .NET assembly through COM. Only late binding can fool the machine. Judging from the COM exception, you haven't gotten close to mocking yet. Best to use the COM component as-is, also a real test.

So, the problem was that my DLL with IDiagnostics interface was generated from a TLB, and that TLB never got registered.
Since the DLL was imported from the TLB, RegAsm.exe refuses to register the library. So I used the regtlibv12.exe tool to register the TLB itself:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\regtlibv12.exe "$(ProjectDir)\lib\Diagnostics.tlb"
Then everything magically started to work.
Since regtlibv12 is not a supported tool, I still don't know how to do this properly.

Error calling an unmanaged windows DLL from a C# WPF application

I am working on a project that requires implementing am unmanaged windows DLL. The DLL is used to communicate with a USB device. My code is in C# and WPF.
To initialize the DLL I call a function called:
InitTimerDll(Int32 wHandle, ref dllInitParams initParams);
When calling this function I have to pass a struct called dllInitParams and the Handle that the control is bound to.
I am using DllImport for function pointer as such:
[DllImport("myDll.dll")]
public static extern void InitTimerDll(Int32 wHandle, ref dllInitParams initParams);
Here is my struct:
public struct dllInitParams
{
public UInt16 simp;
public UInt16 simt;
}
All of the above are in a separate class called myDllInterface.cs. Here is how I call the InitTimerDll function from my WPF form:
public IntPtr Handle
{
get { return (new System.Windows.Interop.WindowInteropHelper(this)).Handle; }
}
private void initTime_Click(object sender, RoutedEventArgs e)
{
myDllInterface.dllInitParams initParams = new myDllInterface.dllInitParams();
initParams.simp = 0;
myDllInterface.InitTimerDll(this.Handle.ToInt32(), ref initParams);
}
The first part of the above code explains how I get the handle and the initTime_Click shows how I initialize the struct, call the initTimeDll function by passing the handle and the struct to it. I have copied the dll file in the directory that the code runs in. My code compiles just fine but it creates an error when I click on the initTime button.
Error:
An unhandled exception of type 'System.AccessViolationException' occurred in ProbeCTRL.exe
Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Why is this happening?

Without knowing exactly what the InitTimerDll() function does with the 'this' pointer, I would focus on the params structure. Try adding a structure layout markup like the following:
[StructLayout(LayoutKind.Sequential, Pack=1)]
public struct dllInitParams
{
public UInt16 simp;
public UInt16 simt;
}
Also, double check that your structure is complete and accurate.

I found the problem. The code is fine the problem was the dll file, which was corrupted. A proper copy of the dll file took care of the problem. When using dll in your codes it is quite important to make sure you have accurate information, function calls, data types to passed and so on.
Thanks everyone for your help.

Have a look at the PInvoke tutorial: http://msdn.microsoft.com/en-us/library/aa288468%28v=vs.71%29.aspx
as Jim Gomes points out:
[StructLayout(LayoutKind.Sequential)]
or something similar is definitely important.
Also, you're only initializing one of the variables in your struct.