0

we have a 32-bit .dll working on a remote 32-bit machine without a problem. We have moved our systems to another machine (64bit), also this .dll was moved.

However this .dll is working in the new machine without crash, but not working as intended (returning a custom error message, whose reason is not understandable). Normally it should produce the same result with the other machine. I have used Dependency Walker to check for missing dll's that this dll is depending on. Placed the 32-bit versions of the missing dll's under SysWOW64, but no good.

By the way our dll might not be just depending on another dll, it might be also be depending on any other file type(for example an .ini, etc.). On Windows is there any way that we can keep track of a dll's access of other files, i.e. can we see which files this dll is using?

Does anyone have any opinion about this case?

lamostreta
  • 2,359
  • 7
  • 44
  • 61
  • To debug .Net assembly loading use the Fusion Log Viewer, SysInternals Process Monitor will show file system load events by process. – Alex K. Sep 02 '16 at 14:47
  • 1
    Process Monitor (available from the MS web site) is often useful for this sort of troubleshooting. – Harry Johnston Sep 02 '16 at 23:35
  • "not working as intended" is not an appropriate problem description. – Hans Passant Sep 05 '16 at 07:39
  • 1. Did you recompile all the depended dlls in 64bit? 2. Did you install the right version of vcredist_64? – neohope Sep 05 '16 at 07:55
  • unfortunately we are having this issue in Windows Server 2003 and PM monitor is not working on Windows Server 2003 – lamostreta Sep 05 '16 at 13:56
  • I have changed the explanataion @HansPassant – lamostreta Sep 05 '16 at 13:57
  • can you please provide the more details about dll? have you compiled the dll with X86 debug mode? if yes, change the configuration to "Any CPU" and build it again in Release mode. might help! NOTE: for .NET projects only – Dirty Developer Nov 14 '16 at 06:51

0 Answers0