DLL could not be found or loaded

[pguild]

From time to time, I get this error message: DLL could not be found or downloaded. The probable cause is that you cannot write to the above directory (f:\Zantar) -- But the program does write to that directory and frequently! It is an external drive where the .exe lives. I dismiss the error message and the program continues to run just fine. The error message is intermittent. 
See attachment.

Any advice on what to do?

[td]

The intermittent nature of the problem suggests a hardware, device driver, or OS issue. If you are using Windows 10 or Windows 11, MSFT has acknowledged a file copy and save bug that can cause intermittent failures.

[edit] Another cause of the error is that your drive does not have enough disk space.

[pguild]

Is there a way I can trap this error and cause it not to show?  There is plenty of space on the drive. The program continues to run with no issues after I close the error message.

[td]

Trapping the error is likely not possible but it depends on where it is happening, and having plenty of space only eliminates one of the previously mentioned possible causes. The reason that the compiled script continues to run is not clear. It could be that the to-be-extracted file is already available to the script or is not used by the script. Again it all depends on the why and where.

[JTaylor]

Is the program already running?   If you get the DLL message open task manager and see if there is already a copy running.   Sometimes a script will look like it closed but you will find it in the process list.  Usually down in the second section.

Jim

[kdmoyers]

In situations like this in the past, I have been tempted to devise an operation that is NOT a fatal error, but that detects the error condition. Something that runs async and can be tested for success.  if it fails, I delay a few seconds and try again. But this is terribly fiddly and often does not work anyway.

These days, I always put my effort into resolving the basic failure issue.

One trick I use when running an exe off an unreliable network drives is to copy the exe to local C drive, and run it from there.

Code (winbatch) Select Expand

    ; This section tries to run the program from the C drive
    ; instead of the network drive.
    if rtstatus()==1
      t = intcontrol(1004,0,0,0,0)
      if strsub(filepath(t),1,1) != "C" ; not running from C drive?
        if !direxist("C:\TEMP") then dirmake("C:\TEMP")
        s = strcat("C:\TEMP\",filebasename(t))
        switch fileexist(s)
          case 0 ; not exist
            terminate(!FileCopy(t,s,0),mytitle,"cant copy program to c:\temp")
            break
          case 2 ; exists but locked from read
            terminate(1,mytitle,"can not copy program to c:\temp")
            break
          case 1 ; exists
            if FileTimeGet(s) != FileTimeGet(t) ; not match timestamp?
              errormode(@off) ; tolerate failure
              FileCopy(t,s,0) ; try to copy over it
              errormode(@on)
            endif
        endswitch
        ;display(1,"transferring...","")
        run(s, intcontrol(1006,0,0,0,0)) ; run the C drive copy
        exit ; and exit from this copy
      endif
    endif

[td]

There is a possible relatively easy workaround. First,  choose the compiler's "skip auto-extraction of extenders and other files" option to get the compiler to skip extraction of extenders and other files from large a EXE.  Then use the ExtractAttachedFile WinBatch function wrap with WIL error handling when manually extracting the files. If you trap an error, simply try the extraction a second time. This technique is a good workaround for the aforementioned Windows file copy bug because when you hit that bug a second attempt usually works.

https://docs.winbatch.com/mergedProjects/WinBatch/WINBATCH_E__003.htm

Note that this will not work if the WIL interpreter is causing the error because that DLL is not skipped when the compiler option is set.

[td]

Is the program already running?   If you get the DLL message open task manager and see if there is already a copy running.   Sometimes a script will look like it closed but you will find it in the process list.  Usually down in the second section.

Jim

That could also explain the DLL extraction error depending on the DLL being extracted when the error occurs.

[td]

Thinking about this problem a little more I think Jim's suggested explanation is the best fit with the evidence as presented by the OP. I made the mistake of focusing too much on the intermittent nature of the problem. Jim's solution neatly covers that part along with the other stuff.