You must always use the Marshal.GetLastWin32Error. The main problem is the garbage collector. If it runs between the call of SetVolumeLabel and the call of GetLastError then you will receive the wrong value, because the GC has surely overwritten the last result. Therefore you always need to specify the SetLastError=true in the DllImport-Attribute: [DllImport(“kernel32.dll”, SetLastError=true)] … Read more
The term “unmanaged resource” is usually used to describe something not directly under the control of the garbage collector. For example, if you open a connection to a database server this will use resources on the server (for maintaining the connection) and possibly other non-.net resources on the client machine, if the provider isn’t written … Read more
I had a _cdecl c++ dll that I called without any trouble from Visual Studio 2008, and then the identical code in Visual Studio 2010 would not work. I got the same PInvoke … has unbalanced the stack error as well. The solution for me was to specify the calling convention in the DllImport(…) attribute: … Read more
You don’t need to use Marshal.GetFunctionPointerForDelegate(), the P/Invoke marshaller does it automatically. You’ll need to declare a delegate on the C# side whose signature is compatible with the function pointer declaration on the C++ side. For example: using System; using System.Runtime.CompilerServices; using System.Runtime.InteropServices; class UnManagedInterop { private delegate int Callback(string text); private Callback mInstance; // … Read more
Event Handlers are a very common source of non-obvious memory leaks. If you subscribe to an event on object1 from object2, then do object2.Dispose() and pretend it doesn’t exist (and drop out all references from your code), there is an implicit reference in object1’s event that will prevent object2 from being garbage collected. MyType object2 … Read more
Managed Code Managed code is what Visual Basic .NET and C# compilers create. It runs on the CLR (Common Language Runtime), which, among other things, offers services like garbage collection, run-time type checking, and reference checking. So, think of it as, “My code is managed by the CLR.” Visual Basic and C# can only produce … Read more
This is a good article about the subject. To summarize, Managed code is not compiled to machine code but to an intermediate language which is interpreted and executed by some service on a machine and is therefore operating within a (hopefully!) secure framework which handles dangerous things like memory and threads for you. In modern … Read more
You can embed the unmanaged DLL as a resource if you extract it yourself to a temporary directory during initialization, and load it explicitly with LoadLibrary before using P/Invoke. I have used this technique and it works well. You may prefer to just link it to the assembly as a separate file as Michael noted, … Read more
One easy way to call into C++ is to create a wrapper assembly in C++/CLI. In C++/CLI you can call into unmanaged code as if you were writing native code, but you can call into C++/CLI code from C# as if it were written in C#. The language was basically designed with interop into existing … Read more
Here is a solution. It uses p/invoke, but seems to work well, 32 or 64 cpu: /// <summary> /// A utility class to determine a process parent. /// </summary> [StructLayout(LayoutKind.Sequential)] public struct ParentProcessUtilities { // These members must match PROCESS_BASIC_INFORMATION internal IntPtr Reserved1; internal IntPtr PebBaseAddress; internal IntPtr Reserved2_0; internal IntPtr Reserved2_1; internal IntPtr UniqueProcessId; … Read more