DLL not loading in Prepar3D v4.2

#1
I have an odd situation. I am trying to distribute an addon that requires a dll, which was created in Visual Studio 2015 C++, to be loaded into the sim. I used the add-on.xml method. Out of 10 people, 7 are running the addon just fine. But 3 of them are experiencing a problem of the dll not loaded. I confirmed this with an internal diagnostic. I checked the path to the dll in the user's add-on XML file. It is correct. P3D auto-detect worked fine and the users accepted it when first starting the sim. The entry for the dll show in the simulator Add Ons menu as enabled. The driver is simply not loading.

What would cause this to happen on only some users but not others? Any ideas?
 
#2
Make sure that your testers use prepar3d v.4.2. It can be checked in prepar3d Menu > Help > About.
If you compiled your dll with simconnect sdk v.4.2, it will not work with p3d 4.1 and early versions. Hope this helps.

Sent from my ONEPLUS A5000 using Tapatalk
 
#5
I had them do that. It showed a few errors like "Error: Invalid unit specified for "A:ADF STANDBY FREQUENCY": "kHz ". But nothing that would indicate a propblem with the dll driver.

"
 
#6
I have compiled it using the Multi-threaded (/MT) runtime library option in Visual Studio 2015. That should eliminate any dependency issues that would make it run on my computer, but not others. Correct?

One commonality is that the 3 computers having the issue are running Windows 10. The DLL file is installed in the C:\Program Files directory structure. Could this be some kind of access permissions/Windows 10 issue?
 
#7
It showed a few errors like "Error: Invalid unit specified for "A:ADF STANDBY FREQUENCY": "kHz ". But nothing that would indicate a propblem with the dll driver.
May be the reason is Character Set in the project properties. Does your users have different locals/languages in Windows?
The PDK states for "Use Multi-Byte Character Set", by the way example projects are configured as "Use Unicode Character Set".
 
#8
The users are all using English. The project is configured as "Use Unicode Character Set". If it were a language issue, would that prevent the DLL from loading?
 

ddawson

Resource contributor
#9
Speaking of Unicode, it is entirely possible that the users having trouble have managed to mess up their dll.xml files by attempting to edit them.
dll.xml and exe.xml, among others, are now stored in Unicode format - a fact not understood by some number of simmers.
You should probably get the users having difficulty to check for dependencies on their system:
http://www.dependencywalker.com/
 
Top