SALFLIBC.DLL gets set to 0 length

I have had this problem on a couple of machines, where SALFLIBC.DLL gets reset to a zero length file. I cannot determine what goes bonkers or when. I usually notice it on my secondary computer. But just now, on the primary, PLATO would not successfully compile, link, and run. The error was 'Target does not exist'. I looked in the SilverFrost\Program Files folder, and there was the zero length DLL. Copied from the redist location and re-ran the build, and all was well.

Anyone else have this occur? Anyway to stop it from happening?

Antivirus problem?

Never had my AV do this, even to an actual virus.

The closest I've been able to determine, if either the compiler or my application crashes horribly (i.e. no error dialog), then this file gets wiped. Even setting it to 'Read-Only' doesn't help. Also, as a regular user, I can't get access to delete the file unless I go ADMIN and change the ownership and permissions.

Odd.

Since there are several versions of the DLL that have been released since the initial release of the 8.1 compiler package, it would be useful to know the DLL version.

You could look into the Windows and your AV program log files to see if any entry matches the file in question.

The only SALFLIBC.DLL I have is the one from the 8.1 release. I scanned the system for all occurrences of this DLL, and the only one damaged was the one in the Program Files folder.

The AV system has no record of doing anything to this file.

Worth a look. I know 2 AV packages that won't allow Silverfrost products to run, and they are the only bits of common software that 'quarantine' other programs.

It seems to me that the only explanation is that these machines have become infected with malware. I would try scanning with good AV checker. I use Kaspersky but I don't know if it is the best.

It happens after a crash. The crashes are self-induced (development), but I cannot come up with the root cause; the fixes are different each time, as one might expect.

Without crashing, the DLL is always there and ready.

If I can make it 'disappear' at will, or I can come up with something small that works to re-create the issue, I'll post the results here.

You could try chkdsk. There could be a problem with the files properties

Quoted from wahorger It happens after a crash. The crashes are self-induced (development), but I cannot come up with the root cause; the fixes are different each time, as one might expect.

Without crashing, the DLL is always there and ready.

If I can make it 'disappear' at will, or I can come up with something small that works to re-create the issue, I'll post the results here.

Is your program a standard Fortran program, or does it make calls to Windows-specific routines such as LoadLibrary()? If the latter, some more details would be helpful for making a diagnosis.

Bill,

I had a horrible thought that perhaps you have an OPEN statement where FILE='SALFLIBC.DLL' and this is a self-inflicted wound? Surely not. Stranger things have happened, and they can be the result of accidental editing (there are several chord-key presses that will insert).

You can, of course, copy SALFLIBC.DLL to the folder wherein lies your development executable, and that copy will be used by your program. See if that gets zeroed.

Eddie

Eddie,

Nope. At the point where the program crashes, no files are open. I only open (and close) files from 1 routine. And never would select this file in any case. No reason to.

The only thing I can think of is that the debugger may be getting started, but I'm not opening the program from within Plato, nor using the debugger to open it. Have never need to use the debugger (although I do recognize the power in that).

I never see the error dialog when this kind of thing happens.

Bill

Bill

If your DLL is in a protected folder (like Program Files (x86)) and you are not running 'As an administrator' then there should be no way for you to accidentally blank out the DLL (within Plato, the debugger or anywhere). Even if there were something wrong in Plato or the debugger, in theory this behaviour should not happen without an explicit prompt to elevate your status.

This is why I am assuming that there is some malware involved.

Quoted from wahorger ... I'm not opening the program from within Plato, nor using the debugger to open it. Have never need to use the debugger (although I do recognize the power in that)

How about trying to do exactly that, i.e. run

C:>SDBG YourProg.EXE

and see if this will nullify dll?

Paul, thanks for the input. I have run scans of my computer and nothing shows up. It might be the AV software itself, but there is no record in the logs.

Is it possible that the DLL is in the registry with two different paths, and there is some conflict with that? I build and test my installs on this same machine, same user. My install builder lets me register the DLLs if I so choose, and I have that option enabled. None of the other DLLs that I build on my own have been affected by this.

Dan, I ran the debugger, but no untoward results. As I said, it has been found only after a crash, a crash which occurred before the program got really running and no error dialogs was ever displayed.

I run the program a lot, when implementing changes, I might have 20 builds in a typical day, and will run the program at least that many times, checking each incremental change. Only when I have one of these odd crashes (when I'm trying stuff with various windows) does the DLL go wonky.

Based on Paul's last post, could you be looking at a virtual copy of the file ? Explorer will display the virtual file properties. I have virtual copies of files that are changed in directories that I do not have rights to; eg on windows 7 I have:

c:\Users\user\AppData\Local\VirtualStore/processor_mhz.txt c:\Users\Campbell\AppData\Local\VirtualStore\Program Files (x86)\Silverfrost/cmptree.tce

You could check if there are files in \AppData\Local\VirtualStore that point to the dll ?

( I think the virtual tree name changed at Win10 )

John, thanks for the suggestion. I looked (both as my regular User account and as the ADMIN) and can find no other references to the DLL. I also searched the registry for any references, and none there either.

I have 4 copies of the DLL. One in the Program files under FTN95, 1 in the restribution folder, and 1 each in my installations folder (under Program Files) for a total of 4. They all have the same file size and date:

02/20/2017 10:19 AM 2,286,592 salflibc.dll

I'll keep looking for something that looks suspicious.

Bill