I have a compiled plugin where I load an (unmanaged) .dll. Recently I started having a problem with the loading, so I tried to simplify my code and tracked it down to this code snippet (which I now put for debugging purposes in a c# script):
public IntPtr hModule;
public string GetDllHandle(string dllName)
IntPtr dllHandle = LoadLibrary(dllName);
if (dllHandle == IntPtr.Zero)
[DllImport("Kernel32.dll", SetLastError = true)]
public static extern IntPtr LoadLibrary(string lpFileName);
[DllImport("Kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
public static extern bool SetDllDirectory(string lpPathName);
What happens is, currently it does not work in Rhino 5 in my personal account (even though it used to), it does work in the admin account, and it does work with Rhino 6. The Error Code I receive is 127, which doesn’t make sense as I am not even trying to find a procedure which I am calling. I have the feeling this is some kind of dependency issue, but still can’t figure out why this is only a problem in one Rhino version. Are there some temporary files / cached files or so which might cause this?
Yeah I figured that was the case, but that’s the only useful input I could come up with. Not an expert at unmanaged dll loading myself. @stevebaer knows all there is to know about this. PInvoke.net is a useful resource worth looking into as well.
Can you put a breakpoint in your unmanaged dll in Visual Studio and hit it when the dll loads? That might help figure out what is happening as visual studio’s output window might give some information on what is going wrong
So in addition, I have so far uninstalled/reinstalled Rhino 5 and Rhino 6 as well as the external software containing this .dll (which has the purpose of allowing interop and accessing their databases), but no change. 32bit causes an Error Code 193.
I have also tested with 32bit versions, it always works fine, just my regular Rhino 5 installation seems to have this problem. Also tested in on other computers with same setup, and no problems, so I don’t think it has something to do with rights.
Any idea in which direction to look? Any temporary or cached files i could maybe delete which haven’t been touched by the Rhino reinstall?
And one more thing, in addition if I just use DLLImport for the .dll in question, same problem, but with this additional info (again, works fine in Rhino 6)
“error: Unable to load DLL ‘C:\Program Files\SOFiSTiK\2018\SOFiSTiK 2018\interfaces\64bit\cdb_w50_x64.dll’: Die angegebene Prozedur wurde nicht gefunden. (Exception from HRESULT: 0x8007007F) (line: 0)”
The application runs fine, even though I think the .dll is not really part of the software but just specifically written to access their databases externally. On the local admin account everything works fine too, I cannot really create another account on this computer.
I think I managed to track down the problem a bit, even though I still don’t fully understand what is happening. It seems to be somehow related to the Rhino Plugin from the same software, which for Rhino 5 and Rhino 6 has different versions. Once the plugin is disabled, the code executes and I can load the .dll. I don’t fully understand why this is not a problem with the other account, and why this is suddenly a problem (as far as I remember I didn’t change anything about this and it worked before).