Home/ Questions/Q 7937461
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-03T22:31:53+00:00

I work on a project that requires .Net interoperability with unmanaged code. I started

  • 0

I work on a project that requires .Net interoperability with unmanaged code. I started to work with .Net a couple of weeks ago, though I have a lot of experience with C/C++, and I am surprised how CLR deals with P/Invoke. Here are the details. My colleague wrote this function

__declspec(dllexport) int __stdcall ReadIPWSensor(unsigned int deviceClassId, void *buffer) {...}

and I had to call it from C# module. I imported the function as

[DllImport("ipw", CallingConvention = CallingConvention.StdCall)]
extern static int ReadIPWSensor(uint deviceClassId, IntPtr buffer);

just to find out an exception (System.EntryPointNotFoundException, Unable to find an entry point named ‘ReadIPWSensor’ in DLL ‘ipw’). I used DependencyWalker tool and found that the function was exported as ?ReadIPWSensor@@YGHIPAX@Z (my colleague forgot to export it in the DEF file). Just for the quick test (the unmanaged DLL compiles very slowly) I changed my import definition to:

[DllImport("ipw", EntryPoint = "#22", CallingConvention = CallingConvention.StdCall)]
extern static int ReadIPWSensor(uint deviceClassId, IntPtr buffer);

as the ordinal was 22. The test passed successfully with the new import definition.

My first question is: What are the good practices when dealing the mangled function exports? Is it a good practice to use the export ordinals?

In my case I had access to the C++ source code and the DEF file so I added the export and changed back the import definition to 

[DllImport("ipw", CallingConvention = CallingConvention.StdCall)]
extern static int ReadIPWSensor(uint deviceClassId, IntPtr buffer);

I knew there is another function we already use in our project and wanted to compare my code with the existing one. The function is defined as

extern “C” __declspec(dllexport) int __stdcall LoadIPWData(void
*buffer)

and is imported as

[DllImport("ipw", CallingConvention = CallingConvention.StdCall)]
extern static int LoadIPWData(IntPtr buffer);

To my surprise DependencyWalker tool shows that the function is exported as _LoadIPWData@4 (my coworker forgot to export it in the DEF file again). However with this function there is no System.EntryPointNotFoundException error. Obviously, the CLR somehow managed to resolve the right name. It seems there is some sort of fallback mechanism that allows CLR to find the right function. I can easily imagine the it sums the sizes of the parameters and is looking for “function_name@the_sum_of_all_parameter_sizes” though it seems quite simplistic.

My second question is: How does CLR match the exported function names during P/Invoke?

In this scenario I think CLR is so clever that it actually hides a bug – LoadIPWData function should be accessible by its name from other unmanaged modules. Maybe I am a bit of paranoid but I prefer to know how actually CLR works. Unfortunately all my google searches on that topic were fruitless.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The pinvoke marshaller has built-in knowledge of a few common DLL export naming schemes. It knows that __cdecl functions often have a leading underscore and that __stdcall in 32-bit mode is commonly decorated with a leading underscore and a trailing @x where x is the size in bytes of the arguments passed on the stack. It also knows that winapi functions are exported with a trailing extra A or W, a naming scheme to distinguish functions that accept strings and for which there’s both an ansi and a Unicode version. The corresponding [DllImport] property is CharSet. It just tries them all until it finds a match.

    It doesn’t know anything about C++ compiler name decoration rules (aka mangling) so that’s why you have to use extern "C" to suppress that by hand.

    • 0