Text File Locking with MS 15? (Resolved!!)

[DAYIII]

I have several Macros which have worked well for years, creating network folders and subfolders and writing into them thousands of daily text files. Their code was compiled to an .exe file in Macro Scheduler 14.
I recently upgraded MS to the latest version 15 and modified part of one of these, but not the create directories or WriteLn subroutines. Now my text files are locked for editing or deletion, even long after the .exe macro has closed. The error says "File is open in another program", even when I'm the only user in the network and the macro/process is validated as closed. Only when I restart the local machine are the text files unlocked.

Here's the interesting note; On this same computer there is a parallel .exe Macro that runs for a minute which also was originally compiled in MS 14, and has not yet been modified in MS 15. Those text files write to the same network folder and are not locked. Both macros have a similar WriteLn function.

When I run the un-compiled macro from the Editor, it creates a normal unlocked text file on the same network folder.

The WriteLn function that suddenly creates locked files is as follows:

Code: Select all

Label>RepeatGrab
      Wait>1
      Press CTRL
      Send>a
      Release CTRL
      Wait>.3
      Press CTRL
      Send>c
      Wait>.3
      Release CTRL
      
      GetClipBoard>MyScreen,0
      Length>%MyScreen%,nLength
If>%nLength%=0,RepeatGrab
      
    Let>MyPath=%RootPath%\PrtInqry-%PFile%.txt
    WriteLn>MyPath,WLN_Res,MyScreen"

I have added a WLN_Res which messages me a code: 32 although the content of the txt file seem to be written successfully.
The Database that tries to read, manipulate or delete these txt files returns an error 70 or 3051

Why is there a sudden difference with the macro compiled in MS 15?
What am I missing?

[Marcus Tettmar]

This can't possibly have anything to do with v14 vs v15. There were no changes to WriteLn between v14 and v15. This has to be a coincidence and something else is causing it.

[DAYIII]

Thanks Marcus for confirming that there were no version changes, but do we have some tools here to help me observe and resolve this problem?

The machine is running Windows 10 Pro on a 64-bit processor. Other than these two browsers and these few macros, no other Office or user programs are running.

Two compiled macros running on the same machine and writing text files to the same network folder within the same minute. All text files are simple, one-write files. The v14 compiled macro is controlling an Internet Explorer Browser and the v15 macro is controlling a Chrome Browser (without Chrome Driver). The v14 IE macro continues to write normal text files while the newly compiled Chrome files are locked after both macro/processes are confirmed closed.

After hours, I have been the only user in this relatively small network with same results.
Internal Co. and external IT specialists have confirmed no server updates or issues and insist that Macro Scheduler has a new problem. Since MS v7, I have learned to trust Marcus, but still need to resolve this somehow.
Can someone offer a suggestion as to what else I can test or look at?

[JRL]

Can someone offer a suggestion as to what else I can test or look at?

Windows Defender???

I have not kept official data but I have executables in version 15 that Defender has not only stopped/prevented from running but deleted the compiled file. I don't recall that ever happening with any previous version compiled files and I have 20+ years of compiled files. I could imagine Defender locking a text file generated by a compiled macro while the text file was being examined for its potential malicious intent.

Also this seems to run in streaks. I have a clock program that was compiled in version 13. I made a change and recompiled in version 15. Some months later the clock was not displayed (I use the program as a wall clock in my garage) and when I checked, the file was gone. Recompiled and a few days later the file was gone again. Did this for a week and eventually The clock program is allowed to run. No idea if its because of a Windows update or if the Defender AI decides I must really want my computer infected and gives up.

I have done tests. Writeln locks a file for the spilt second it takes to write the file then the file is released.

[DAYIII]

JRL wrote:
Windows Defender???

Thank you for looking at this JRL, I have long appreciated your amazing contributions to these tools and this forum.
Windows Defender or some other file protection is about the only thing that I have left to focus on.

Our first success teaser was when our IT manager rolled back the latest server updates. Then after 24 hours, the locking issue returned even though additional updates have been turned off. Then the locking stopped for 2 days but then it’s been back on for 2nd day now.

I noticed that the macro in my editor performed perfectly (saving the text file to same network folders) and that the problem only existed after the macro was compiled and was run from any machine on the network. Meanwhile, the legacy macro compiled years ago in MS v14 faithfully writes text files to that same network folder that don’t get locked.

I will keep you posted as we try to understand this frustrating sudden issue.

[DAYIII]

JRL Wrote: Windows Defender??

Thank you JRL for bird-dogging Windows Defender as a likely culprit.
As soon as we disabled WD, the problem disappeared. Now we will identify the macro names as safe files and the target text file folders as safe locations. I’m not the network administrator, so I’m not sure exactly what steps are involved to accomplish this in a server version of WD.

It’s strange how WD discriminated against the text files created in Macro Scheduler v15, and ignored those created in v14.

Hopefully this thread will be helpful to others.
Thanks again JRL and Marcus!