Archive for the 'P/Invoke' Category

You know I don’t like to be an echo blog, but I couldn’t give up on such a fine piece of code.
This is really one of the things I said to myself “How didn’t I think of that before?” 🙂

Mike Stall has a great post and a piece of code that he wrote about using P/Invoke to access unmanaged Windows API code.

He has written a rather generic wrapper that does all the dirty LoadLibrary, GetProcAddress code and you can generically get a function and execute it without thinking twice.
It uses SafeHandles and make all the necessary releases (if you use it correctly) without you having to worry about it.

Check it out (don’t forget to read the disclaimer he wrote there) and have lots of P/Invoke fun.

I bet one of you (or maybe even me if I’ll find some time) can write a code generation utility that will use this code to create a wrapper for most of the unmanaged Windows API code that goes around making it even more type-safe in the sense if not having to pass around strings to get function names and having to deal with a generics deceleration of the function you are using.

Update 13/6/2006: Updated a few typos.

At my day job (which is part of the reason I’m posting less frequently) I’ve had to P/Invoke a bit and gathered some P/Invoke tips that I’ve decided to share.
Today’s tip is about P/Invoking and C style unions.

Let’s take the following union:

union MYUNION {
int number;
double d;
}

This is quite a standard union, which means its memory is contiguous. Its translation in C# would look like this:

[StructLayout(LayoutKind.Explicit)]
public struct MYUNION {
[FieldOffset(0)]
public int number;
[FieldOffset(0)]
public double d;
}

Notice two important things. First, the StructLayout attribute is set to LayoutKind.Explicit, this means that using the FieldOffset attributes we are building the memory layout of the struct and it will look exactly like this. When usually handling C structs in .NET and P/Invoking we usually use LayoutKind.Sequential so that the memory layout will be as described using the layout of the fields as we have put them.

The second important thing is the FieldOffset attribute. Notice that both fields have the same offset. This will tell the P/Invoke layer that these two fields are actually part of the same memory (remember, these two fields were declared inside a union!).

This is how unions will work for you in your P/Invoke code. Enjoy!

Technorati : , , , , , , ,
Del.icio.us : , , , , , , ,
Ice Rocket : , , , , , , ,

One of the big changes in P/Invoke in .NET Framework 2.0 vs. .NET Framework 1.0/1.1 is that you can now pass function pointers from a C API back to .NET.

In previous versions (1.0/1.1) you could pass a delegate as a function pointer to a C API, but could not receive a function pointer from the C API back to .NET.

This technique of passing a pointer from within the API is relatively common in more than a few APIs in Windows, where you have one function that initializes a special struct that simply contains pointers to various functions. This is like an interface for an unobject oriented language like C. It gives the designers of the API the ability to plugin and replace an implementation of a certain function dynamically depending on either the environment or parameters passed to the function that initializes the struct.

Quite cool!

This also means that various other Windows APIs (SSPI, for example) can now be called directly from C# and does not require a bridging C dll or writing a mixed (managed and unmanaged) code in C++ to glue things together.

I’ve previously covered a few of the common problems in P/Invoke code, so be sure to read that if you are facing problems when P/Invoking code!

A couple of weeks ago a reader of this blog approached me via Email (you can always Email me and I’ll do my best to help you if I have the time and if I can 😉 ) with a problem regarding the exception “Attempted to read or write protected memory. This is often an indication that other memory is corrupt” (which is of type System.AccessViolationException).

I immediately asked if there was some P/Invoke (Platform Invoke) code.

“Why?”, do you ask. Because in 90% of the cases, this exception occurs when a call to a P/Invoke function (either calling a Win32 API or some custom native code of your own) returns. It might even be that this piece of code you are calling is purely managed, but in its implementation it uses P/Invoke and you are not aware of it.

The main problem with P/Invoke is that .NET is very sensitive to memory corruption. If you step over some internal GC structure or some of the .NET meta data for a class things get really bad.

The causes for this error can stem from different reasons:

  • You passed a wrongly referenced pointer.
  • Inside the function there is a bug in the form of “Off-By-One” or some other memory smear or misuse.

There are two main scenarios in P/Invoke code. The first is when you correctly use the various marshaling and P/Invoke type matching simply pass a managed object (such as a string) to the function and the P/Invoke layer takes care of all the rest. In this case, you might get the exception mentioned above if:
The second is when you use IntPtr because you need to pass a pointer to a pointer or you need to receive some kind of a strange memory structure. In this case, make sure that if you pass an IntPtr buffer that you have allocated using something like Marshal.AllocHGlobal or Marshal.AllocCoTaskMem you allocated enough memory.

  • You didn’t define the marshaling attributes correctly (i.e., you should have used native pointer – IntPtr – and you didn’t)
  • You did define everything correctly, but inside the native function there is a memory related bug

If you do start to get this exception try to do the following things:

  • If you are using Marshalling attributes (MarshalAs and friends) make sure they are correct. Make sure the markings for in, out and ref are correct as well. This is a very important step. Take the time to check each and every function argument. It can save you a lot of debugging time.
  • Make sure that you are passing the right type of objects. This is specifically important if you are using IntPtrs. Make sure that you pass the right type of pointer to the function.
  • If you are calling a Windows function, there is a chance (though its usually very slim) that they do have some kind of an allocation bug, but before running to Microsoft Support, make sure you are passing the right type of pointers. If you are still in doubt, write a native sample code that calls this function and run it lots of time with additional checks to see that the integrity of the memory passed is OK.
  • If you are calling your own function, do the same as I have suggested in the point above, but in most cases, it usually a problem within the native function (if the passed pointer types are correct and the marshaling attributes are correct as well).

Remember, P/Invoke is one of .NET’s greatest features. It’s VERY fast (performance wise) and very easy to use, but its also very easy to make mistakes that can crash your whole .NET application. Use it wisely!

In this post, I’ll talk about some issues that one must understand about mixing finalization and P/Invoke Interoping.

Usually, when you have a class that has an IntPtr as a member due to some P/Invoke code you implement a Finalizer and the IDisposable interface in which the necessary cleanup code will be implemented to release the unmanaged resources you have allocated.

The main problem starts when that same class has other member variables that are managed.
These managed member variables will not get collected until our class’ instance is finalized and that can generate memory pressure that is not really necessary if things are implemented correctly.

So, what can we do about it?

There are a few approaches that can help us minimize the effect of P/Invoking and finalizers:

  1. Don’t declare the IntPtr variable as a member variable.
  2. Create a class that wraps the IntPtr and P/Invoke code without declaring managed member variables.

Let’s examine both approaches.

The first approach talks about not declaring IntPtr variables as member variables. This means that if you have some function that needs to interop, delcare the IntPtr variable as a local variable, use it and clean everything up. This is the best approach but will only work if there are no (serious) performance penalties such as calling some heavy P/Invoked Windows API.

The second approach is a more viable one if there is a need to continuously call some unmanaged API such as ReadFile on a socket or file. In this case, writing a dedicated class that holds the reference to the unmanaged resource only and a finalizer and IDisposable would be a great way of making sure that it will not hold back the GC of other resources (not to mention it would be cleaner to have a dedicated class for wrapping such API 😉 ).

That class we have an IntPtr as a member variable and will have additional functions to manipulate the data that is being held behind that unmanaged resource.

By implementing one of the two approaches I’ve discussed above you can, quite easily, ease the memory pressure on your application with little change to your code and functionality.

In .NET Framework 2.0 that will come with Visual Studio 2005 (formerly known as Whideby) there is a new mechanism to handle such issues called SafeHandle. You can read more about it here, in this great post from the BCL Team Blog.

I will talk about SafeHandles in a subsequent post.