All Things WinBatch > WinBatch

DLL could not be found or loaded

<< < (2/2)

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 ---    ; 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")
          case 2 ; exists but locked from read
            terminate(1,mytitle,"can not copy program to c:\temp")
          case 1 ; exists
            if FileTimeGet(s) != FileTimeGet(t) ; not match timestamp?
              errormode(@off) ; tolerate failure
              FileCopy(t,s,0) ; try to copy over it
        run(s, intcontrol(1006,0,0,0,0)) ; run the C drive copy
        exit ; and exit from this copy

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.

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.


--- Quote from: JTaylor on June 01, 2023, 08:18:47 am ---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.


--- End quote ---

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

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.


[0] Message Index

[*] Previous page

Go to full version