0
I have an application (x64) which makes use of a third party runtime, and the application is having issues with loading this runtime via its DLLs (also x64).
The Windows Installer struggles to register these DLLs (presumably for a similar reason) and as such I have tested out registering the DLLs using regsvr32, and found some interesting behaviour. I can get the DLLs to successfully register and unregister with regsvr32 (I can find them in the registry under CLSIDs afterwards), but only if I execute regsvr32 from within the folder the DLLs are store in. Even if I use relative paths (eg ....\outer\dlls\binary.dll) from within the folder they are stored in they still register successfully. I tried with both a full path and partial paths, from around 4 down to 1 levels above in the path, and all failed.
The error that it always comes back with is "Invalid access to a memory location." Which is just vague enough to be very difficult to find the source of.
Does anybody have any experience of this issue? Does anybody know what could be the cause? Strange that it works from within the folder but not from anywhere else. I can only assume there is some environmental issue or corruption as I have other machines where there is no problem at all. I did run the .NET repair tool but it didn't seem to make any difference.
Luke
Posted 2017-07-11T11:39:38.453
Reputation: 281
1I am confused. You mention you ran the .NET Repair Tool, but you shouldn't be using
regsvr32to register a .NET library,regsvr32is limited to a Windows COM library typically. Please clarify the reason you run the .NET Repair Tool. – Ramhound – 2017-07-11T13:37:08.100The runtime is for .NET applications to use, but I believe these are C++ binaries – Luke – 2017-07-11T14:26:39.923
@Ramhound Sorry I didn't make that clear. I realise now how strange it sounds. I've just been trying everything and thought maybe it was a .NET issue. – Luke – 2017-07-11T14:37:16.617
You don't just "register" arbitrary DLLs; as @Ramhound said, regsvr32 is only meaningful for native COM, which can execute arbitrary code that can be throwing that exception. Basic modules (think C export) and .NET assemblies are completely different, and typically do not involve regsvr32.
– Bob – 2017-07-12T07:32:01.333You should (a) name the libraries involved, if possible, (b) name the consuming application, if possible, and (c) quote any errors you might have received from the installer, verbatim. More information about the environment will also be useful. Otherwise everyone will be operating on probably-incorrect assumptons. – Bob – 2017-07-12T07:34:21.817
@Bob The runtime is SAP Crystal Reports runtime for .NET 4.0. I understand that these are COM DLLs. The installer fails to register them during setup with "Error 1904. Module <path to dll> failed to register" and HRESULT -2147023898. – Luke – 2017-07-12T07:47:34.703