Windows 10 can not load my dll

I just started beta testing my product and am getting this problem from a user running Windows 10 and am wondering if anyone might have run into this before. This is loading a C++ dll I wrote (DInputPluginNative.dll). The build works fine on Windows 7, but on Windows 10 it fails to load the library.

This is a single line out of a long series of similar errors in the output_log. Do those paths look odd to anyone else?

Code (csharp):

1. Fallback handler could not load library C:/Spel/Design It Drive It Speedboats/DIDIBoats_Data/Mono/.\C:/Spel/Design It Drive It Speedboats/DIDIBoats_Data/Plugins/DInputPluginNative.dll
2.  

I'm running 5.1.2p3. The build is 64 bit, the DInputPluginNative.dll is 64 bit, and the user's Windows 10 operating system is 64 bit. Same as mine (all 64 bit) except I'm running Windows 7 and he's running Windows 10. I don't even know where to begin attempting to fix this. Is this a Unity problem or could it be something I'm doing wrong?

Any ideas would be appreciated. I'm also having a different set of problems with Windows 8 too by the looks of it, but will save that for another thread.

 

Thanks, guys.

Ricardo: That path looked wrong to me too, but why is it that way at all? I don't specify that anywhere myself. Isn't Unity doing that? As far as I've seen so far it only appears doing that on Windows 10.

I'm looking into VoloDyaD's solution now and that feels like it's the right road to follow. My plugin was a debug version. I tried using the different compiler option in Volo's post, but it's spitting a couple of LNK2001 unresolved external errors having to do with DirectInput at me. They're different depending on whether it's configured for debug or release. With release it's a bit shorter:

Code (csharp):

1.  
2. Error    1    error LNK2001: unresolved external symbol c_dfDIJoystick    H:\VS2012 Projects\C++\DInputPluginNative\DInputPluginNative\DInputPluginNative\DInputPluginNative.obj    DInputPluginNative
3.  
4. Error    2    error LNK2001: unresolved external symbol DirectInput8Create    H:\VS2012 Projects\C++\DInputPluginNative\DInputPluginNative\DInputPluginNative\DInputPluginNative.obj    DInputPluginNative
5.  
6.  

So I must not be including the right library or obj or something. Debug version doesn't do this. Welcome to C++ hell...

Anyway, thanks for the help. I'll pull some more hair out over this and try to figure out what I'm missing here. Hopefully this is the big problem behind everything going completely bonkers in beta and it has nothing to do with Unity at all.

 

Adding this fixed the C++ dll unresolved externals. Might get somewhere now.

Code (csharp):

1. #pragma comment (lib,"dinput8.lib")

 

Update: I implemented VoloDyaD's solution and now on one Win 7 Pro 64 tester's machine the output_log file doesn't even show up anymore. So I don't even see a way to debug it now outside of my own machine where the program works like it should, and I can't tell if the problem described in this thread was fixed or not on a Win 10 machine without it logging anymore.

What in the world could I have possibly have done to break the logging? I didn't change the "use player log" option in the player settings or anything like that.

I use an updater asset that kicks in when the game starts. This runs flawlessly on my own builds 100% of the time with fresh installs from the innosetup file I created for it. On a Win 7 Pro 64 user's last test (same OS as mine), the program ran, but stopped at the first file a bunch of times (no download at all), then it stopped after the first download. In neither case was there even output_log anywhere to be written to when he stopped the program.

I'm completely lost at this point and don't know what I can do but start removing bits of the program one by one until it begins working to try to get some clue what might be going on. My program seems to do something different on almost every tester's machine, and not one beta tester has successfully been able to get it working correctly regardless of the version of Windows.

I would think if it's not running on someone else's machine it might suggest a dependency is missing. The only thing I can think might be missing are the Visual Studio 2012 runtimes (I use VS2012), but he's installed those and it makes no difference.

I'll try ricardo_arango's solution, but if that doesn't work I might need to spend a buttload of extra money to get one of those support contracts and hope somebody smarter at Unity can help me figure it out. If this costs thousands of dollars I'm going to be pissed, but I don't know what else I can do at this point without any way to view a tester's debug file anymore.

I don't even know if it's because of my plugin or not. I added a simple debug messaging system to my plugin which of course works perfectly on my machine, but without it showing up on anyone else's, it's useless.

 

Neither solution changes anything. I'm currently doing both and I still get the screwy path showing up with the fallback handler error. Any other ideas?

Why is the path wrong in the first place? I don't set that myself. Wouldn't that make it a Unity bug?

 

Thanks, Ricardo. I appreciate the help.

I've got things running now. Did you get my PM? In my Vista case it was because that machine needed a VC++ runtime update. One of the dependencies in my DInput plugin was missing on that system. I'll look into including that runtime update as part of the installation package.

I'm not sure if the LoadLibrary() call is necessary or not yet. That path in the log file didn't look right to me either, but I don't really know for sure.