Problems after upgrading to Windows 10

[Dana]

I realize this is probably too vague, unless somebody's seen a similar issue and has somewhere to point me:

I have a compiled script that's been running flawlessly for some years.  Yesterday, I replaced the Win7 box with a new Win10 one and copied the script and related files to the new box.  The script runs a GUI, waits for a serial input trigger, does some more serial I/O using the CommMg UDF, uses some stuff from Date.au3 and Array.au3, then writes a line to an Excel file using the Excel UDF.  Mostly it works, but I'm getting random autoit errors after successfully running some number of cycles (5-100, i.e. minutes to hours).  Mostly the same line, occasionally a different place.  When it happens and the script is restarted, it again works fine, until it doesn't again.

I ran the windows compatibility checker and it suggested using Windows 8 compatibility, now I'm waiting for the user to try running it again.  Unfortunately they run it mostly on the night shift when I'm not around.

Anybody seen anything like this after a Win10 upgrade?

[Earthshine]

you need to add debugging code to your app to find out where and why it fails. make sure you are error checking everywhere and logging it with your debug statements.

Share your code if you would like others to help

Edited March 26, 2021 by Earthshine

[Nine]

10 minutes ago, Dana said:

I realize this is probably too vague

Yep you are right. 

But there is some idiosyncrasies under Win10, not because of AutoIt, mostly because Win10 has changed some details under the hood.  Fortunately, many of those issues have a workaround.  The beta version has implemented multiple of those workarounds.  You could try this first.  And of course, I cannot agree more with @Earthshine about having some sort of log debugging file to look at the statements results (e.g. @error).

Since we have no code and no idea what are the errors you have encountered, guess this is the best we can do...

[Earthshine]

my favorite logging udf so far is log4a 

log4a - A logging UDF - AutoIt Example Scripts - AutoIt Forums (autoitscript.com)

config it in the main au3 program like this, then just include log4a.au3 in each of your included scripts.

log away, it is very customizable too. great tool.

#include "log4a.au3"

#Region ;**** Logging ****
; Enable logging and don't write to stderr
_log4a_SetEnable()
; Write to stderr, set min level to warn, customize message format
_log4a_SetErrorStream()
_log4a_SetMinLevel($LOG4A_LEVEL_TRACE)
If @compiled Then _log4a_SetMinLevel($LOG4A_LEVEL_WARN) ; Change the min level if the script is compiled
_log4a_SetFormat("${date} | ${host} | ${level} | ${message}")
#EndRegion ;**** Logging ****

 

Edited March 26, 2021 by Earthshine

[Dana]

Hmmm.  Well, I learned a little more.  I ran the code through the Au3Stripper so I could make sense of the line numbers.  It seems likely that it has something to do with the Excel UDF, since the bulk of the errors are on a line which comes from the UDF.  I have a datalogging subroutine (function), which builds a string to write and then:

If Not $ExcelRunning Then
        Global $oExcel = _Excel_Open(0, 0, 0, 0) 
        If Not @error Then
            $ExcelRunning = 1
        Else
            MsgBox(0 + 16 + 4096 + 65536, "Error", "Error " & @error & @CRLF & "Extended error " & @extended & @CRLF & @CRLF & "Contact Engineering")
        EndIf
    EndIf

    $oWorkbook = _Excel_BookOpen($oExcel, @ScriptDir & $logfile)
    If @error Then
        MsgBox(48 + 4096, "Error", "Unable to open " & @ScriptDir & $logfile & @CRLF & @CRLF & "Contact Engineering")
        _Excel_Close($oExcel)
        Exit
    EndIf

In Excel.au3, which gets merged in at compile time, there is:

Func _Excel_BookOpen($oExcel, $sFilePath, $bReadOnly = Default, $bVisible = Default, $sPassword = Default, $sWritePassword = Default, $bUpdateLinks = Default)
    ; Error handler, automatic cleanup at end of function
    Local $oError = ObjEvent("AutoIt.Error", "__Excel_COMErrFunc")
    #forceref $oError
    If Not IsObj($oExcel) Or ObjName($oExcel, 1) <> "_Application" Then Return SetError(1, @error, 0)
    If Not FileExists($sFilePath) Then Return SetError(2, 0, 0)
    If $bReadOnly = Default Then $bReadOnly = False
    If $bVisible = Default Then $bVisible = True

That last line ("If $bvisible...") is where the error occurs.  When the error doesn't occur, the _Excel_BookOpen function completes, it writes a range of data to the file, then does an _Excel_BookClose to save the data, does some housekeeping, and back to where it's waiting for input for the next cycle.  Note that I'm not getting an error messagebox on the "unable to open...contact engineering" line, which is logical since the _Excel_BookOpen function didn't complete.

The strange part is the randomness; the error mostly occurs about 20 minutes and maybe 30 cycles of the working part of the program... though it has happened two minutes and two cycles apart.  The data being processed every cycle is similar, with only minor differences in the string and floating point data.  It's hard to think of any way where a change in the windows version or settings would cause such randomness, it should either work or not.  There is no interacting with other programs (other than Excel), it's not interacting with anything on the screen.

Since then, I've changed it to Win7 compatibility mode and made the user an admin as he was on the old computer.  Since it's Friday afternoon, I probably won't hear until next week whether that fixed anything.

[argumentum]

7 hours ago, Dana said:

writes a line to an Excel file using the Excel UDF

no clue of what or why as you haven't shared but, I'd use a CSV file. It can be opened in Excel for those curious and simplifies everything   

[Nine]

Make a replicable runable snippet.  And as I have seen tons before, you will find yourself the problem.  But if you cannot, please post your snippet here so we can test it ourself.

[Dana]

It looks like running the program as admin and turning off UAC fixed it.  Still not clear why that would cause a random failure like this, unless something (Excel integration?) was just on the hairy edge of timing out.  A little over 1000 cycles with no error last night and this morning.

I'm using Excel so others can find and view the data without having to worry about the import options.

[argumentum]

2 hours ago, Dana said:

I'm using Excel so others can find and view the data without having to worry about the import options.

CSV will also open. If Excel lock the file then you may have a problem. A dump ( CSV ) is simpler. ( my 2 cents, I'm sure you have perfectly good reasons for the way you do it )