1

I have a .NET DLL SigToolNet.DLL with multiple visible COM classes. It references a .NET DLL FTDIVcpLibNet.DLL wrapper for a native C++ static library FTDIVCPLIB which in turn references 3rd party native DLL ftd2xx.dll. The SigToolNet.DLL is registered with the 32 bit regasm successfully

C:\Release> regasm SigToolNet.dll /codebase
RegAsm : warning RA0000 : Registering an unsigned assembly with /codebase can cause your assembly to interfere with other applications that may be installed on the same computer. The /codebase switch is intended to be used only with signed assemblies. Please give your assembly a strong name and re-register it.
Types registered successfully

Side note, I don't know why it's giving me this warning since SigToolNet.dll is code signed. When running on the development system where VS2019 is installed the application TestHarness.exe which references COM visible class in SigToolNet.DLL runs successfully. However, when SigToolNet.DLL is installed on another computer I get an exception at run time at the point where the 2nd call to one of the COM visible methods (DetectDevice) is called

Command DetectDevice failed
Error code: -2147024770
Desc: Could not load file or assembly 'FTDIVcpLibNet.dll' or one of its dependencies. The specified module could not be found.

All referenced DLLs including FTDIVcpLibNet.dll are located in the same folder where SigToolNet.DLL is located which is also where it was registered.

I've tried running on 3 different computers all with the same failed results on both Windows 7 and Windows 10. The development system where it runs successfully is running Windows 10.

I also tried tracing the assembly load failure with Assembly Binding Log Viewer (fuslogvw.exe)

*** Assembly Binder Log Entry  (6/26/2020 @ 4:00:00 PM) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable  C:\Vendor Testing Harness\Epic 2018 And Beyond\EpicESigTestHarness.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = SigToolNet, Version=2020.0.0.3, Culture=neutral, PublicKeyToken=null
 (Fully-specified)
LOG: Appbase = file:///C:/Vendor Testing Harness/Epic 2018 And Beyond/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = EpicESigTestHarness.exe
Calling assembly : (Unknown).
===
LOG: This bind starts in the default load context.
LOG: Download of the application configuration file was attempted from file:///C:/Vendor Testing Harness/Epic 2018 And Beyond/EpicESigTestHarness.exe.config.
LOG: Configuration file C:\Vendor Testing Harness\Epic 2018 And Beyond\EpicESigTestHarness.exe.config does not exist.
LOG: No application configuration file found.
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Vendor Testing Harness/Epic 2018 And Beyond/SigToolNet.DLL.
LOG: Attempting download of new URL file:///C:/Vendor Testing Harness/Epic 2018 And Beyond/SigToolNet/SigToolNet.DLL.
LOG: Attempting download of new URL file:///C:/Vendor Testing Harness/Epic 2018 And Beyond/SigToolNet.EXE.
LOG: Attempting download of new URL file:///C:/Vendor Testing Harness/Epic 2018 And Beyond/SigToolNet/SigToolNet.EXE.
LOG: All probing URLs attempted and failed.

I find this log confusing. It says it fails to locate SigToolNet.dll but it appears to be looking for it in the same folder as the TestHarness.exe. It should be looking for it in C:\Release which is where SigToolNet.dll was successfully registered. Also, the reported exception is not that it couldn't find SigToolNet.dll but that it couldn't find FTDIVcpLibNet.dll. Shouldn't the first place it looks be the same folder where SigToolNet.dll is registered?

I've used remote debugging in VS2019 and have been able to breakpoint and single step in SigToolNet at the call to the first method Init. But the breakpoint on the 2nd call to DetectDevice never happens due to the exception before the call executes.

All .NET DLLs are using .NET 4.8

I have been unable to determine why it runs successfully on the system where SigToolNet.dll was developed and VS2019 is installed but not on other systems.

JonN
  • 2,498
  • 5
  • 33
  • 49
  • If the signature warning occurs under Windows 7 make sure you have the necessary updates for SHA-256 support in place, see [KB 4472027](https://support.microsoft.com/en-us/help/4472027/2019-sha-2-code-signing-support-requirement-for-windows-and-wsus). – dxiv Jun 27 '20 at 22:34
  • The signature warning occurs when running regasm /codebase on both Windows 10 and Windows 7 – JonN Jun 28 '20 at 05:17
  • Are you also running `regasm /tlb SigToolNet.dll` on the target machine? As a last resort, run [Process Monitor](https://learn.microsoft.com/en-us/sysinternals/downloads/procmon) and try to follow the file/registry accesses before the error. – dxiv Jun 28 '20 at 05:32
  • I was already generating SigToolNet.tlb and copying it to the target computer along with SigToolNet.dll. Registering on target with "regasm SigToolNet.dll /tlb" does not change the result of the cannot find exception. – JonN Jun 28 '20 at 05:56

1 Answers1

1

Possible you have to install approciate version of C++ Redistribatable for your FTDIVCPLIB.dll. On machine with VS2019 your have already had it.

Lana
  • 1,024
  • 1
  • 7
  • 14
  • Yes that does appear to have been part of my problem. On the Windows 10 system installing 2015-2019 C++ Redistributables did resolve the issue. However on the Windows 7 system I'm still getting the can't find file exception on loading FTDIVcpLibNet.dll. So there must be something else missing. It is very frustrating that the exception does not report the exact file it can't find. With native DLLs I've used Depends.exe but that doesn't seem to work with a managed DLL. I read that fuslogvw would give me report for managed DLL but the fuslogvw report doesn't make sense (see orig post). – JonN Jun 27 '20 at 22:30
  • So if I have an x86 native 32 bit application that references a managed DLL with a COM visible class and that references a managed DLL wrapper, how do I determine exactly what DLL file that managed DLL wrapper can't find during execution? – JonN Jun 27 '20 at 23:00
  • What does Depends tool show for FTDIVCPLIB on Win7? Does it load ok? – Lana Jun 28 '20 at 09:08
  • 1
    Depends run on the Win7 system showed that FTDIVcpLib.dll was missing the debug version of the v140 C++ runtime. The Redistributable installer only installs the release version of the C++ runtime DLLs. I rebuilt project using release version of FTDIVcpLibNet.dll and now it runs on Win7 system. I'm marking this as correct answer. I still find frustrating that Microsoft error reporting lacks sufficient detail to realize what was missing with a lot less effort. – JonN Jun 30 '20 at 21:14