Extender Error

[snowsnowsnow]

I have a long running script that every so often crashes, displaying the error message shown in the attachment.  Actually, what happens is that this error box comes up repeatedly (about 4 time), then the extender function call that caused it returns an error code, which causes my script to exit (since the script is programmed to exit if the function fails).

The question is: What causes this?  And how to protect against it?  My theory is that the problem is that my Extender DLL (the WinSock Extender) is stored on a network drive and that what is happening is that at the exact moment when the function is called, the network drive is in the "Disconnected" state, so the DLL file is unavailable.  The obvious solution, of course, is to make a copy of the DLL available on a local drive, but that is (obviously) undesirable in my environment (since if it weren't, I'd just do it).

So, any suggestions on how to deal with this?

[stanl]

Possibly Coding IntControl(73,p1,p2,p3,0) with p3 set to a udf to handle the error.

[td]

Unfortunately, snow++'s first error -"Could not access Extender Entry 0x03" - is one of the very few that cannot be trapped using WIL error handling.  It is considered a catastrophic error.  More or less a WIL equivalent to a kernel-mode fatal error generated by the OS.

Snow++ deserves praise for taking the time to diagnose the problem and reporting useful and only useful information with context.  Unfortunately,  I know of no solution other than the one already proposed and dismissed by Snow++.  The error occurs when the interpreter attempts to obtain and use the memory address of the extender's main entry point.  The OS will not honor this request if the extender's in process memory image is not backed by an accessible file system image. That is just the way the OS works and it does make some sense that it should work that way.   

[snowsnowsnow]

Yeah, that pretty much sums it up.

As it happens, I did just go ahead and copy the extender to C:\bin on the local drive, so that it picks it up from there.  But, clearly, I was hoping for a more systematic solution.

ISTM that the way WB accesses extender DLLs now is through some version of memory mapping (I'm not sure what the Windows terminology for it is, but in Unix/Linux, it is the mmap() system call) - which makes the contents of the file appear to be in the memory space of the program, but in actuality, it still needs to be available on disk in order to be used.  Which is all well and good, of course - except when, as here, it isn't.

It also seems to me that it would be nice if there was some way in WB to actually load the DLL into memory, such that the backing store wasn't needed.  But that may not be possible.

[td]

I suppose you could write your own versions of the Windows APIs that load and permit access to dynamic link libraries into a process.   Or you could write a linker that would statically build the extender into a compiled WinBatch script's resource, text and codes spaces.  But both options would likely cost much more than any benefit accrued.