We Keep Coding

Get list of all open windows in .Net Core running on macOS (via NSApplication?)

Getting a list of open windows in .Net Framework on Windows was relatively easy. How can I do the same in .Net Core/.Net 5 or later on macOS?
To clarify, I'm looking for a way to retrieve a list of all open windows owned by any running application/process. I don't have much experience of macOS development - I'm a Windows developer - but I've tried to use the NSApplication as suggested by this answer.
I created a .Net 6.0 Console application in VS2022 on macOS Monterey (12.2), added a reference to Xamarin.Mac and libxammac.dylib as described here - which describes doing this in Xamarin rather than .Net, but I don't see any other option to create a Console application. With the simple code:
static void Main(string[] args)
{
NSApplication.Init();
}
I get the output
Xamarin.Mac: dlopen error: dlsym(RTLD_DEFAULT, mono_get_runtime_build_info): symbol not found
I've no idea what this means. I'm not even sure this approach has any merit.
Does anyone know if it's possible to use NSApplication from a .Net Core/6.0 application, and if so whether NSApplication will give me the ability to read a system-wide list of open windows? If not, is there another way to accomplish this?
This is only for my own internal use, it doesn't need to be in any way portable or stable outside of my own environment.

In the link you refer to, there is an important note:
... as Xamarin.Mac.dll does not run under the .NET Core runtime, it only runs with the Mono runtime.
Because you try to run Xamarin.Mac.dll under .net-core, you get this dlopen error.
No System-wide List via NSApplication
The linked answer with NSApplication.shared.windows is incorrect if you want to read a system-wide list of open windows. It can only be used to determine all currently existing windows for the application from which the call is made, see Apple's documentation.
Alternative solution
Nevertheless, there are several ways to access the Window information in macOS. One of them could be a small unmanaged C-lib that gets the necessary information via CoreFoundation and CoreGraphics and returns it to C# via Platform Invoke (P/Invoke).
Native Code
Here is example code for a C-Lib that determines and returns the names of the window owners.
WindowsListLib.h
extern char const **windowList(void);
extern void freeWindowList(char const **list);
The interface of the library consists of only two functions. The first function called windowList returns a list with the names of the window owners. The last element of the list must be NULL so that you can detect where the list ends on the managed C# side. Since the memory for the string list is allocated dynamically, you must use the freeWindowList function to free the associated memory after processing.
WindowsListLib.c
#include "WindowListLib.h"
#include <CoreFoundation/CoreFoundation.h>
#include <CoreGraphics/CoreGraphics.h>
static void errorExit(char *msg) {
fprintf(stderr, "%s\n", msg);
exit(1);
}
static char *copyUTF8String(CFStringRef string) {
CFIndex length = CFStringGetLength(string);
CFIndex size = CFStringGetMaximumSizeForEncoding(length, kCFStringEncodingUTF8) + 1;
char *buf = malloc(size);
if(!buf) {
errorExit("malloc failed");
}
if(!CFStringGetCString(string, buf, size, kCFStringEncodingUTF8)) {
errorExit("copyUTF8String with utf8 encoding failed");
}
return buf;
}
char const **windowList(void) {
CFArrayRef cfWindowList = CGWindowListCopyWindowInfo(kCGWindowListOptionOnScreenOnly, kCGNullWindowID);
CFIndex count = CFArrayGetCount(cfWindowList);
char const **list = malloc(sizeof(char *) * (count + 1));
if(!list) {
errorExit("malloc failed");
}
list[count] = NULL;
for(CFIndex i = 0; i < count; i++) {
CFDictionaryRef windowInfo = CFArrayGetValueAtIndex(cfWindowList, i);
CFStringRef name = CFDictionaryGetValue(windowInfo, kCGWindowOwnerName);
if(name) {
list[i] = copyUTF8String(name);
} else {
list[i] = strdup("unknown");
}
}
CFRelease(cfWindowList);
return list;
}
void freeWindowList(char const **list) {
const char **ptr = list;
while(*ptr++) {
free((void *)*ptr);
}
free(list);
}
CGWindowListCopyWindowInfo is the actual function that gets the window information. It returns a list of dictionaries containing the details. From this we extract kCGWindowOwnerName. This CFStringRef is converted to a dynamically allocated UTF-8 string by the function copyUTF8String.
By convention, calls like CGWindowListCopyWindowInfo that contain the word copy (or create) must be released after use with CFRelease to avoid creating memory leaks.
C# Code
The whole thing can then be called on the C# side something like this:
using System.Runtime.InteropServices;
namespace WindowList
{
public static class Program
{
[DllImport("WindowListLib", EntryPoint = "windowList")]
private static extern IntPtr WindowList();
[DllImport("WindowListLib", EntryPoint = "freeWindowList")]
private static extern void FreeWindowList(IntPtr list);
private static List<string> GetWindows()
{
var nativeWindowList = WindowList();
var windows = new List<string>();
var nativeWindowPtr = nativeWindowList;
string? windowName;
do
{
var strPtr = Marshal.ReadIntPtr(nativeWindowPtr);
windowName = Marshal.PtrToStringUTF8(strPtr);
if (windowName == null) continue;
windows.Add(windowName);
nativeWindowPtr += Marshal.SizeOf(typeof(IntPtr));
} while (windowName != null);
FreeWindowList(nativeWindowList);
return windows;
}
static void Main()
{
foreach (var winName in GetWindows())
{
Console.WriteLine(winName);
}
}
}
}
The GetWindows method fetches the data via a native call to WindowList and converts the C strings to managed strings, then releases the native resources via a call to FreeWindowList.
This function returns only the owner names, such as Finder, Xcode, Safari, etc. If there are multiple windows, the owners will also be returned multiple times, etc. The exact logic of what should be determined will probably have to be changed according to your requirements. However, the code above should at least show a possible approach to how this can be done.
Screenshot

IMetaDataEmit::DefineUserString returns HRESULT: -2147024882 (0x8007000E E_OUTOFMEMORY)

I'm playing around with the unmanaged Profiling interfaces for the CLR.
When running with a netcoreapp3.1 or net5.0 console application, in ICorProfilerCallback::JITCompilationStarted or in ICorProfilerCallback::ModuleLoadFinished, any call to IMetaDataEmit::DefineUserString to store a string literal in the console app module and return an mdString token, returns a HRESULT of -2147024882 (0x8007000E E_OUTOFMEMORY). The call returns this same HRESULT no matter what values are passed to IMetaDataEmit::DefineUserString.
The .NET application is super simple
using System;
namespace dotnetapp
{
class Program
{
static void Main(string[] args)
{
WriteEnvironmentVariable("CORECLR_ENABLE_PROFILING");
WriteEnvironmentVariable("CORECLR_PROFILER");
WriteEnvironmentVariable("CORECLR_PROFILER_PATH");
Console.WriteLine("Hello World!");
}
static void WriteEnvironmentVariable(string name)
{
var value = Environment.GetEnvironmentVariable(name);
Console.WriteLine($"{name} = {value}");
}
}
}
and is built and run with
dotnet build -c Debug dotnetapp.csproj
dotnet bin/Debug/net5.0/dotnetapp.dll
With the relevant Core CLR profiling environment variables set when running the application
CORECLR_ENABLE_PROFILING=1
CORECLR_PROFILER={PROFILER CLSID}
CORECLR_PROFILER_PATH=clr_profiler.dll
The profiler is written in Rust using com-rs, and the call to IMetaDataEmit::DefineUserString is defined as
impl IMetaDataEmit {
pub fn define_user_string(&self, str: &str) -> Result<mdString, HRESULT> {
let mut md_string = mdStringNil;
let mut wide_string = U16CString::from_str(str).unwrap();
let len = wide_string.len() as ULONG;
let ptr = wide_string.as_ptr();
let hr = unsafe { self.DefineUserString(ptr, len, &mut md_string) };
if FAILED(hr) {
log::error!("define user string '{}' failed. HRESULT: {} {:X}", str, hr, hr);
return Err(hr);
}
log::trace!("md_string token {}", md_string);
Ok(md_string)
}
}
where the unsafe call is to comr-rs generated function
com::interfaces! {
#[uuid("BA3FEE4C-ECB9-4E41-83B7-183FA41CD859")]
pub unsafe interface IMetaDataEmit: IUnknown {
// functions ordered by IMetaDataEmit layout
fn DefineUserString(&self,
szString: LPCWSTR,
cchString: ULONG,
pstk: *mut mdString,
) -> HRESULT;
}
}
I'm using U16CString to create a *const u16 pointer in other places in the profiler to pass LPCWSTR to interface functions, such as IMetaDataImport::EnumMethodsWithName, so I don't think this is an issue, but thought I'd mention it.
The log for the failed call is
TRACE [imetadata_emit] wide_string UCString { inner: [71, 111, 111, 100, 98, 121, 101, 32, 87, 111, 114, 108, 100, 33, 0] }, len 14
ERROR [imetadata_emit] define user string 'Goodbye World!' failed. HRESULT: -2147024882 8007000E
where UCString.inner is the Vec<u16> to which a pointer is passed to IMetaDataEmit::DefineUserString.
IMetaDataEmit is retrieved from the stored ICorProfilerInfo passed to the profiler on initialize using ICorProfilerInfo::GetModuleMetaData, using the CorOpenFlags ofRead and ofWrite
impl ICorProfilerInfo {
pub fn get_module_metadata<I: Interface>(
&self,
module_id: ModuleID,
open_flags: CorOpenFlags,
) -> Result<I, HRESULT> {
let mut unknown = None;
let hr = unsafe {
self.GetModuleMetaData(module_id, open_flags.bits(), &I::IID as REFIID, &mut unknown as *mut _ as *mut *mut IUnknown)
};
if FAILED(hr) {
log::error!("error fetching metadata for module_id {}, HRESULT: {:X}", module_id, hr);
return Err(hr);
}
Ok(unknown.unwrap())
}
}
where GetModuleMetaData is defined on the ICorProfilerInfo generated with com::interfaces! macro
com::interfaces! {
#[uuid("28B5557D-3F3F-48b4-90B2-5F9EEA2F6C48")]
pub unsafe interface ICorProfilerInfo: IUnknown {
// functions ordered by ICorProfilerInfo layout
fn GetModuleMetaData(&self,
moduleId: ModuleID,
dwOpenFlags: DWORD,
riid: REFIID,
ppOut: *mut *mut IUnknown,
) -> HRESULT;
}
}
It seems like I'm missing something in Rust somewhere. Retrieving data from ICorProfilerInfo, IMetaDataImport, IMetaDataImport2 work, as does getting and modifying IL function bodies (changing existing instructions). A thought I had is whether IMetaDataEmit might need to be mutable, but I don't think that needs to be the case, as changes to metadata occur on the C++ runtime side of the FFI boundary.
EDIT
I put together a simple C++ profiler that calls IMetaDataEmit::DefineUserString in ICorProfilerCallback::ModuleLoadFinished and that works as expected on the sample .NET application, so this indicates that the issue is in the Rust code somewhere.
Looking through the runtime code, I think RegMeta::DefineUserString is the implementation of DefineUserString and tracing the code paths, I think the E_OUTOFMEMORY is coming from StgBlobPool::AddBlob.

The issue was (apparently) due to an incorrect definition of the IMetaDataEmit interface.
Whatever the target language is, a COM interface definition must match the original binary layout exactly: all methods in same order (don't trust MSDN visual order on this), starting with derived interfaces methods (IUnknown, etc.), and exact binary-compatible signature for each method.

ofstream.open() set failbit in DLL called by UWP application

I've looked up on Internet to see if someone encountered that problem, but haven't found anything.
So I'm trying to use a C++ DLL in a C# UWP application. This DLL has a log file which is opened at the beginning of the code with the following function:
#include <string>
#include <iostream>
using namespace std;
int Logger::set(string file_name, bool clear_log) {
_file_stream.exceptions(ofstream::failbit | ofstream::badbit);
try {
_file_stream.open(file_name, ios_base::out | (clear_log ? ios_base::trunc : ios_base::app));
}
catch (ofstream::failure) {
return -1;
}
_file_stream << "";
return 0;
}
Here is the code of the Logger class:
class Logger {
private:
std::ofstream _file_stream;
public:
Logger() {};
~Logger() { _file_stream.close(); };
int set(std::string file_name, bool clear_log);
}
Now, this code works fine when I use the DLL in standalone mode. But when called via the UWP app, the open() function throws an ofstream::failure exception saying:
ios_base::failbit set: iostream stream error
I first thought this was due to UWP's weird access rights policies, but after debugging, file_name points to the correct package folder in AppData, so it should be okay to write a file here.
What could be the problem?
EDIT: I found out that for some reason, the C file API works as expected. That is, the following code successfully creates the file:
#include <iostream>
using namespace std;
int Logger::set(string file_name, bool clear_log) {
FILE* test = fopen(file_name.c_str(), clear_log ? "w" : "a");
if(!test)
{
return -1;
}
fprintf(test, "");
return 0;
}

I figured out myself after some more active debugging. Somewhere before in the code this similar (indirect) call to ofstream::open didn't fail:
ofstream out("out.txt", ios_base::trunc);
And by putting breakpoints on the right place, I was able to determine that in that case, the value of the open mode (the ios_base::trunc argument) resolved to 18 (the expected value), whereas it resolved to the weird value 1594 in the problematic case, when using the ternary operator.
Replacing the ternary operator by a if-else block resolved the problem:
int Logger::set(string file_name, bool clean_log) {
_file_stream.exceptions(ofstream::failbit | ofstream::badbit);
try
{
if (clean_log)
_file_stream.open(file_name, ios_base::trunc);
else
_file_stream.open(file_name, ios_base::app);
}
catch (ofstream::failure)
{
return -1;
}
return 0;
}

AppDomain support is dead in UnityEngine, any way to unload dll?

I am kinda stuck on not being able to dispose .NET 3.5 dlls from the process.
AppDomain support is off in unity, there is no way to unload a dll from the process using the .NET api, because the C# functions are not implemented.
Anyone could get me some hints on how / where should I start to remove the dll from the memory / process somehow, so I can re-load the dll whenever I want?

Alright, after this time I thought that this is some sort of heavy research, and there are no publications related to this. So here is what you have to do. First head over to https://github.com/mono/mono/branches/all and determine which mono version you are going to require. In my case I was doing this for an old game, and I needed the 2014 version of mono.
My project is discontinued so there is no point for me to keep this as a secret. The following examples will show you a way, but It probably won't be enough for you to get what you want on a newer mono version.
Using this way, you are able to unload every dll in a new AppDomain. You can extend It to create multiple appdomains, or unload only a specific dll. If It is working on a newer mono version then please let me know! Credits go to me, and 4g3v.
Once you have done that you are going to need exactly the same environment, and compilers for that version. In my case that was the Visual Studio 2010 compilers, and I didn't need to refactor most of the things.
You will need more than just following my instructions, you will have to play with mono, and get to know how the project works.
So hence as stated: C# API doesn't support AppDomains, but mono by default does. You just need to make some improvements, and extensions for It. Here is what you need to do:
Define two new functions in mono.def for example
mono_rb_create_domain and
mono_rb_unload_domain
The above two functions will be responsible to create, and dispose a domain.
Head over to: mono/metadata/object.c
Find function mono_runtime_unhandled_exception_policy_set and add (We will create the function later below):
mono_add_internal_call("YourDLLNameSpace.Icalls::mono_rb_load_plugin", ves_icall_mono_rb_load_plugin); //Last mono function unity calls before adding their own icalls (mono_runtime_unhandled_exception_policy_set). Adding them at runtime doesn't work, so this should be a pretty good place.
The above code will define a C# function that will be able to handle the loading of a custom DLL loaded in our own AppDomain. Make sure that your C# class, and function is public. Reminder: This should be somewhere in your unity project already. (For example Assembly-CSharp or whatever). It is crucial, because this will be handling the loading of your new dlls, and they will go to a new appdomain.
[MethodImpl(MethodImplOptions.InternalCall)]
public extern Assembly mono_rb_load_plugin(IntPtr data, uint dataLen);
Alright, we have to add some additional checks to avoid crashes in unity/unity_liveness.c Look for function mono_add_process_object and make it look like the following. This might differ in newer mono versions. =) What we have done here is basically ensuring that the received object has a VTable (which should be the class), and It isn't null.
static void mono_add_process_object (MonoObject* object, LivenessState* state)
{
gboolean has_references = 0;
MonoClass* klass; // Define the class
if (object && !IS_MARKED(object))
{
klass = GET_VTABLE(object)->klass; // Get the VTable
// Ensure that the class isn't f***ed up. Read: https://en.wikipedia.org/wiki/Hexspeak
if(klass == NULL || klass == 0xBAADF00D || klass == 0xFEEEFEEE)
{
return;
}
has_references = klass->has_references;
if(has_references || should_process_value(object,state) != LIVENESS_DONT_PROCESS)
{
if (array_is_full(state->all_objects))
array_safe_grow(state, state->all_objects);
array_push_back(state->all_objects, object);
MARK_OBJ(object);
}
// Check if klass has further references - if not skip adding
if (has_references)
{
if(array_is_full(state->process_array))
array_safe_grow(state, state->process_array);
array_push_back(state->process_array, object);
}
}
}
The above code will ensure that the processed class isn't faulty, or points somewhere else where It shouldn't.
Let's create our domain handlers.
Make sure to create this under the mono project.
My header file was named as mono_rustbuster.h, and contained:
static MonoDomain* rustBusterDomain;
GHashTable* pluginHashTable;
void mono_method_info_object();
MonoReflectionAssembly* ves_icall_mono_rb_load_plugin(void* objectPtr, char* data, guint32 dataLen) MONO_INTERNAL;
Then we created mono_rustbuster.c, and wrote the following:
#include "metadata\metadata-internals.h"
#include "metadata\image.h"
#include "metadata\assembly.h"
#include "metadata\debug-helpers.h"
#include "metadata\class-internals.h"
#include "metadata\object-internals.h"
static MonoDomain* rustBusterDomain;
GHashTable* pluginHashTable;
void mono_method_info_object()
{
}
int mono_rb_create_domain()
{
pluginHashTable = g_hash_table_new(g_str_hash, g_str_equal);
rustBusterDomain = mono_domain_create_appdomain("PluginDomain", NULL);
return 0x01;
}
int mono_rb_unload_domain()
{
mono_domain_unload(rustBusterDomain);
return 0x01;
}
MonoReflectionAssembly* ves_icall_mono_rb_load_plugin(void* objectPtr, char* data, guint32 dataLen)
{
MonoAssembly* ass;
MonoImage* img;
MonoImageOpenStatus status;
MonoDomain* current;
char *assNameBuf;
current = mono_domain_get();
mono_domain_set(rustBusterDomain, FALSE);
img = mono_image_open_from_data_full(data, dataLen, TRUE, NULL, FALSE);
ass = mono_assembly_load_from_full(img, "", &status, FALSE);
assNameBuf = (char*)malloc(256);
sprintf(assNameBuf, "%s", ass->aname.name);
g_hash_table_insert(pluginHashTable, (gpointer)assNameBuf, (gpointer)ass);
mono_domain_set(current, FALSE);
return mono_assembly_get_object(rustBusterDomain, ass);
}
After this setup your loaded DLLs might whine about missing references. This mostly happens when you load a new DLL in all by yourself using these functions. We added some layers into mono/metadata/assembly.c for this fix.
Find mono_assembly_load_reference This method works with the assembly's references, find where It is calling the reference variable and add:
if(reference == NULL && strstr(image->name, "data-"))
{
reference = (MonoAssembly*)g_hash_table_lookup(pluginHashTable, aname.name);
}
Hint: Mono add's data- to all of the dll's, so that way we can use that memory pointer to find the references. Basically fixes the unresolved referencess.
Head over to mono/metadata/class.c and find: mono_class_is_assignable_from
Before function would return data using the last function check if the class names are equal.
The last return looks something like this:
return mono_class_has_parent (oklass, klass);
Add:
if(!mono_class_has_parent (oklass, klass))
{
if(strstr(klass->image->name, "data-"))
{
if(!strcmp((oklass)->supertypes [(klass)->idepth - 1]->name, klass->name))
{
//OutputDebugStringA("mono_class_is_assignable_from(): Class names are equal so true is returned");
return TRUE;
}
}
}
The above code will add fixes to ScriptableObject cast exceptions.
You are sort of done. You may encounter additional issues. Here is how it works in C#:
[DllImport("mono.dll")]
internal static extern int mono_rb_create_domain();
[DllImport("mono.dll")]
internal static extern int mono_rb_unload_domain();
Handle loading of a new dll:
var icalls = new Icalls();
int domaincreation = RustBuster.mono_rb_create_domain();
byte[] bytes = getyourdllsbytearraysomehow;
IntPtr pluginMem = Marshal.AllocHGlobal(bytes.Length);
for (int i = 0; i < bytes.Length; i++)
{
Marshal.WriteByte(pluginMem, i, bytes[i]);
}
assembly = icalls.mono_rb_load_plugin(pluginMem, (uint) bytes.Length);
Unload:
int domaincheck2 = RustBuster.mono_rb_unload_domain();

Unmanaged DLL in C# not working properly

I've been working on DLL which uses OpenCV to do some tracking. Got everything working on a C console project using VS 2008 (for testing purposes). Then I made a new DLL project and got it compiled. I setted up everything so I just had put a single function on a Thread Class to call a single function.
Then I created a C# project for GUI and other stuff. The DLL loads fine (using System.Runtime.InteropServices, the method starts (I can see the capture window created by OpenCV) but the tracking is not being done. To verify the DLL was actually working, I loaded on Python and called the method and it ran fine (tracking was being made).
I'm new to working with unmanaged DLL's on managed code. Any ideas on what am I doing wrong or how can I debug this? If you need anything else to help me solve this problem I'll provide it.
Thanks in advance.
Edit:
I'm not using a class on the DLL, I'm using a single function, the Thread class comes from the System.Threading on C#
The way I'm using the DLL is like this.
namespace GUI
{
static class NativeTracking
{
[DllImport(#"__Tracking.dll")]
public static extern void _Tracking();
}
}
The I put it on a thread like his
public GUI()
{
InitializeComponent();
_tracking = new Thread(_Tracking);
_tracking.Start();
}
public _Tracking()
{
while(True)
{
NativeTracking.Tracking();
}
}
Edit: Native Coded
Native Code, sorry for the messy format.
Header File
#include <cv.h>
#include <stdio.h>
#include <ctype.h>
#include <windows.h>
#include <highgui.h>
#include "..\original\project\myheader.h"
#include "..\original\project\myheader1.h"
#include "..\original\project\myheader2.h"
#include "..\original\project\myheader3.h"
#include "..\original\project\myheader4.h"
#ifdef __cplusplus
extern "C"{
#endif
_declspec(dllexport) void Tracking();
#ifdef __cplusplus
}
#endif
Implementation
#include "exposed.h"
void Tracking( )
{
int flag = 1, i=0;
iplImgs imgs;
trackingTool tools;
helperTools helperTools;
CvCapture* capture = 0;
capture = cvCaptureFromCAM( 0 );
cvSetCaptureProperty(capture, CV_CAP_PROP_FRAME_WIDTH, 320);
cvSetCaptureProperty(capture, CV_CAP_PROP_FRAME_HEIGHT, 240);
cvSetCaptureProperty(capture, CV_CAP_PROP_FPS, 20.0f);
imgs.image = 0;
cvNamedWindow( "Window", 0 );
initHelperTools(&helperTools);
initTools(&imgs, &tools);
for(;;){
int c;
IplImage* frame = 0;
frame = cvQueryFrame( capture );
if( !frame )
break;
if( !imgs.image ){
/* allocate all the buffers */
prepareImages(&imgs, &tools, frame);
}
cvCopy( frame, imgs.image, 0 );
cvCvtColor( imgs.image, imgs.grey, CV_BGR2GRAY );
if( flag == 1 || conditionB ){
someOperations(&imgs, &tools);
if (conditionC)
flag = 0;
}
else if( conditionD ){
otherOps(&helperTools, imgs.grey);
someTrack(&imgs, &tools, &helperTools, drawPoints);
someCorrections(&tools);
if ( condition ){
if (!wasReset){
wasReset = 0;
continue;
}
if ( validation )
someMoreOperations(&tools, corretions);
}
}
bufferHandlingOps(&imgs);
c = cvWaitKey(10);
if( (char)c == 27 )
break;
switch ((char)c){
case 'p':
drawPoints ^= 1;
break;
default:
;
}
}
cvReleaseCapture( &capture );
cvDestroyWindow("Window");
}

One problem I see is that you're using the default C calling convention in your native code, which is "__cdecl", and in your P/Invoke "DLLImport" attribute you're letting it use the default calling for C# which is "__stdcall". This is probably throwing a run time exception whenever you invoke your native method.
Also, I realize that you're not passing any arguments or expecting any results, but the calling convention does denote the way the function is decorated, which can lead to name mangling problems.
You can:
Change your native export to "__declspec(dllexport) void __stdcall Tracking();"
Or change the "CallingConvention" property on your DLLImport attribute: [DllImport(#"__Tracking.dll") CallingConvention = CallingConvention=CallingConvention.Cdecl]

One of the problem of DllImport (P/Invoke) is that is not type safe. You knows it's working only runtime because you don't have a way to check it at compile time if:
the signature of the method is the right one;
the mangling of the method is correct.
It's very popular for WIN32 methods because you'll find plenty of examples that work, but for the lib you are using, it's a matter of trying and trying until it works or you find the specific problem that's blocking you (remember to verify the dll is in the same directory, or in system directory, of the executable when it runs).
My advice is to create a proper wrapper in C++/CLI. It doesn't have the problems above and it's esier to debug in case of problems. Here is a more complex example I wrote in the case of a callback in C to expose in C#.