AutoIt (AutoItX) on C# Windows 7 App System.DllNotFoundException

Question

I have a C# application that uses AutoItX for automation. This application works fine in my Windows 8.1 x64 environment compiled with Microsoft Visual Studio 2013 release 3.

I pushed a copy of the app code to a bitbucket repository and cloned it to a computer running Windows 7 x64. AutoItX version 3.14.2 was installed and the 32bit calls were selected. The application was compiled using Visual Studio 2013 release 4.

The app compiled fine, but the first use of the AutoIt functions resulted in an error:

An unhandled exception of type 'System.DllNotFoundException' occurred in AutoItX3.Assembly.dll

I tried the following steps. The app was tested after each of these steps

1. Attempted to register the .dll manually using regsrv32

   regsrv32 "C:\Program Files (x86)\AutoIt3\AutoItX\AutoItX3.dll"

2. Uninstalled VisualStudio 2013 R4 and attempted to reinstall VisualStudio 2013 R3 {The installation of R3 failed because it required internet explorer version 10 and version 11 has already been installed on this computer} so R4 was reinstalled

3. Uninstalled AutoIt and reinstalled selecting the 64 bit library preference. Compiled the app with x64 Platform option

4. Uninstalled AutoIt and reinstalled using the 32 bit library preference Compiled the app with the X86 Platform option

5. Manually copied AutoItX3.dll to the C:\windows\System32 directory

6. Manually copied AutoItX3_x64.dll to the c:\Windows\SysWOW64 directory. Compiled the app for x64 platform

7. Wiped computer clean and reinstalled windows 7, AutoIt (32 bit preference), Visual Studio 2013 R4

8. Installed AutoIt v14

9. Installed the beta version of AutoIt v15

10. Performed a Windows update - 213 updates (!) installed

11. Installed Internet Explorer v11

12. Performed a Windows update - 4 updates installed

13. Installed AutoIt version 3.10.2 that worked on the Windows 8 system

I would appreciate suggestions on what to try next. I'm probably missing something very basic, but I just can't find a solution

Answer 1

5. Manually copied AutoItX3.dll to the C:\windows\System32 directory

6. Manually copied AutoItX3_x64.dll to the c:\Windows\SysWOW64 directory. Compiled the app for x64 platform

That's the only thing you did wrong, you reversed the copies. There are no other DLLs you could be missing, the AutoItX3.dll and AutoItX3_x64.dll files themselves have no other dependencies that are not already available on any Windows machine. Just operating system DLLs, they've been around forever. Something you can see with Dumpbin.exe /imports.

And the exception message comes out of .NET, it is caused by a [DllImport] attribute. You can see the content of AutoItX3.Assembly.dll with a decompiler like ILSpy or Reflector. There is very little to it, only two DLLs are ever used. AutoItX3.dll for 32-bit code and AutoIt_x64.dll for 64-bit code.

Fairly tragic btw, otherwise a side-effect of ab/using the operating system directories for non-operating system DLLs. The only real way to make sense of why this is backwards is to know the history of Windows.

Back in the early days of Windows when it was still a 16-bit operating system (versions 1 through 3.11), c:\windows\system was the home directory for the operating system executables. Starting with NT 3.11 and Windows 95, the first 32-bit versions, that directory was renamed to c:\windows\system32. When the 64-bit version became available, Microsoft could not rename it to c:\windows\system64 anymore. Too many programs hard-coded the name of that directory in their source code. Breaking those programs would have been a good idea, just not a good strategy to get customers to move to the next version.

The 64-bit version has an emulator that can run 32-bit programs, it is called WOW64. "Windows on 64-bit Windows". The c:\windows\syswow64 directory is therefore the home directory of the 32-bit executables.

Exactly backwards from what the names would suggest. Just reverse the copies and that runtime error will disappear.

---

Generic advice applies:

• The official way to get the loader to tell you about missing DLLs is to enable loader snaps. It is the most reliable way, albeit a bit clumsy.
• Dependency Walker has not been maintained for a very long time and produces far too many false warnings. It also has a problem with .NET programs like this, it cannot see the dependency on AutoItX3.dll. You should still get something out of it when you use its Profile mode.
• Process Monitor was always the best tool to troubleshoot missing DLLs. You'll see your program searching for the missing DLL, you can tell its name and the directories it looks in from the trace. Start near the bottom working backwards to avoid drowning in the data. I should however note that its been unreliable lately on the machine I use since ~Win81, the trace is just missing stuff I know should have been there. YMMV.