Access violation in module msched.exe

[evangelmike]

Greetings! While running a macro written in Macro Scheduler Ver. 14.07, I got the following message:
"Application Error
Exception EAccess Violation in module msched.exe at 00000D789
Access violation at address 0040D78B9 in msched.exe.
Read of address 000000000."

What might cause this? Is there any workarount? Thanks!

Sincerely,

Michael D Fitzpatrick

[Marcus Tettmar]

What does the macro do? Which line in the code causes the error?

[evangelmike]

Would you believe I had the following code in one of my macros?

Code: Select all

// Check if 4 left most chars are http://www.:
MidStr>IssuerWebAddress,1,4,LeftFourDigits
If>{(%LeftFourDigits%<>"www.") AND (%LeftFourDigits%<>"WWW.")}
    // MDL>Invalid Web Address; Please search the web for the website address and press /. Issuer name is on clipboard.
    Label>GetWebSiteFromGoogle
    WaitClipBoard
    PutClipBoard>IssNme
    Wait>0.4
    Press Home
    Wait>0.2
    GoSub>GetWebSiteFromGoogle
EndIf

A careful scrutiny of the code reveals a Label and a Subroutine with the same name. As it turns out, this code is very rarely executed. I ran it again before correcting the same name error, and it ran without the Access Violation error. Perhaps it will only occasionally fail. No doubt version 16 or 17 of Macro Scheduler will catch a number of similar coding errors. I have since given the Label and the Subroutine different names, and I will notify this forum if the Access Violation error occurs again.

[Marcus Tettmar]

Interesting, thanks for reporting your findings. I've made a note in our bug tracker to look into this scenario and prevent the access violation.

[evangelmike]

I have written a series of HUGE macros, and in reviewing the code, I found a number of places where I had given the same name to two different Labels. (It took me several hours to find all of these.) Many of these errors had been in my code for a number of years. It is to be hoped that jumps to these same-named labels had somehow read my mind and branched to the proper locations. I would pay BIG BUCKS for a Macro assembler which caught most of my coding errors. Some coding errors are extremely difficult to track down, and it is highly likely that some coding errors will never be caught, possibly causing financial loss of many thousands of times the cost of a single copy of Macro Scheduler.

[Grovkillen]

Don't know if this is what you're looking for but this is a script I made some time ago just to evaluate a error I had. I hope you will find it somewhat useful.

Code: Select all

//The output VARIABLE_LIST will add these (and other variables) true value instead of the text... you will understand if you run the script.
Let>MSG_STAYONTOP=1
Let>MSG_WIDTH=300
Let>MSG_HEIGHT=400

//What to look for...
Let>LABEL_TO_LOOK_FOR=Label>
Let>SUBROUTINE_TO_LOOK_FOR=SRT>
Let>VARIABLE_TO_LOOK_FOR=Let>
Let>VARIABLE_TO_LOOK_FOR_END==

//Length of stuff...
Length>LABEL_TO_LOOK_FOR,LABEL_TO_LOOK_FOR_LENGTH
Length>SUBROUTINE_TO_LOOK_FOR,SUBROUTINE_TO_LOOK_FOR_LENGTH
Length>VARIABLE_TO_LOOK_FOR,VARIABLE_TO_LOOK_FOR_LENGTH

//Where to look...
Let>CODE_FILE=%SCRIPT_DIR%\Code.txt
IfNotFileExists>%CODE_FILE%
    Exit>0
Endif>

//Where to add findings
//Findings.txt will add every variable, label and subroutine found together with found row number (to evaluate in Excel for example)
Let>FINDINGS_FILE=%SCRIPT_DIR%\Findings.txt
//Label list file will add every UNIQUE label found
Let>LABEL_LIST=%SCRIPT_DIR%\LABEL_LIST.txt
//same here... UNIQUE found
Let>SUBROUTINE_LIST=%SCRIPT_DIR%\SUBROUTINE_LIST.txt
//same here... UNIQUE found
Let>VARIABLE_LIST=%SCRIPT_DIR%\VARIABLE_LIST.txt
//if the script find any collision this is where it will be saved
Let>COLLISION_FILE=%SCRIPT_DIR%\Collisions.txt

//Start looking...
Let>krow=0
Let>COLLISIONS_FOUND=0
Let>COLLISION_NAMES=
Label>START
    Message>Reading row number: %krow%%CRLF%Found collisions: %COLLISIONS_FOUND%%CRLF%%CRLF%%COLLISION_NAMES%
  Let>krow=%krow%+1
  ReadLn>%CODE_FILE%,%krow%,LINE_TEXT
  If>LINE_TEXT=##EOF##
    If>COLLISIONS_FOUND>0
        WriteLn>%COLLISION_FILE%,COLLISION_FILE_result,%COLLISION_NAMES%
    Endif>
    MessageModal>%CODE_FILE% analyze finisched!%CRLF%%CRLF%Please have a look in %FINDINGS_FILE%%CRLF%%CRLF%%COLLISION_NAMES%
    Exit>0
  Else>
    If>LINE_TEXT=
        Goto>START
    Endif>
    LTrim>LINE_TEXT,LINE_TEXT
    RTrim>LINE_TEXT,LINE_TEXT
        //Check if row is a label
      MidStr>LINE_TEXT,0,%LABEL_TO_LOOK_FOR_LENGTH%,ANALYZED_TEXT
      If>ANALYZED_TEXT=%LABEL_TO_LOOK_FOR%
        Length>LINE_TEXT,LINE_TEXT_LENGTH
        Let>LINE_TEXT_LENGTH=%LINE_TEXT_LENGTH%-%LABEL_TO_LOOK_FOR_LENGTH%
        Let>LINE_TEXT_START=%LABEL_TO_LOOK_FOR_LENGTH%+1
        MidStr>LINE_TEXT,%LINE_TEXT_START%,%LINE_TEXT_LENGTH%,NAME_TO_CHECK
        Let>WRITE_TO_FILE=%LABEL_LIST%
        GoSub>LOOP
        Let>LOOK_IN_FILE=%SUBROUTINE_LIST%
        GoSub>LOOP_LOOK
        Let>LOOK_IN_FILE=%VARIABLE_LIST%
        GoSub>LOOP_LOOK
      Endif>
        //Check if row is a subroutine
      MidStr>LINE_TEXT,0,%SUBROUTINE_TO_LOOK_FOR_LENGTH%,ANALYZED_TEXT
      If>ANALYZED_TEXT=%SUBROUTINE_TO_LOOK_FOR%
        Length>LINE_TEXT,LINE_TEXT_LENGTH
        Let>LINE_TEXT_LENGTH=%LINE_TEXT_LENGTH%-%SUBROUTINE_TO_LOOK_FOR_LENGTH%
        Let>LINE_TEXT_START=%SUBROUTINE_TO_LOOK_FOR_LENGTH%+1
        MidStr>LINE_TEXT,%LINE_TEXT_START%,%LINE_TEXT_LENGTH%,NAME_TO_CHECK
        Let>WRITE_TO_FILE=%SUBROUTINE_LIST%
        GoSub>LOOP
        Let>LOOK_IN_FILE=%LABEL_LIST%
        GoSub>LOOP_LOOK
        Let>LOOK_IN_FILE=%VARIABLE_LIST%
        GoSub>LOOP_LOOK
      Endif>
        //Check if row is a variable
      MidStr>LINE_TEXT,0,%VARIABLE_TO_LOOK_FOR_LENGTH%,ANALYZED_TEXT
      If>ANALYZED_TEXT=%VARIABLE_TO_LOOK_FOR%
        Position>%VARIABLE_TO_LOOK_FOR_END%,LINE_TEXT,0,LINE_TEXT_END
        Let>LINE_TEXT_END=%LINE_TEXT_END%-1
        Let>LINE_TEXT_END=%LINE_TEXT_END%-%VARIABLE_TO_LOOK_FOR_LENGTH%
        Let>LINE_TEXT_START=%VARIABLE_TO_LOOK_FOR_LENGTH%+1
        MidStr>LINE_TEXT,%LINE_TEXT_START%,%LINE_TEXT_END%,NAME_TO_CHECK
        Let>IS_A_VARIABLE=1
        Let>WRITE_TO_FILE=%VARIABLE_LIST%
        GoSub>LOOP
        Let>LOOK_IN_FILE=%LABEL_LIST%
        GoSub>LOOP_LOOK
        Let>LOOK_IN_FILE=%SUBROUTINE_LIST%
        GoSub>LOOP_LOOK
        Let>IS_A_VARIABLE=0
      Endif>
  Endif>
Goto>START

SRT>LOOP
    IfFileExists>%WRITE_TO_FILE%
        Let>qrow=0
           Label>START_OVER
           Let>qrow=%qrow%+1
           ReadLn>%WRITE_TO_FILE%,%qrow%,FILE_ROW_TEXT
           If>FILE_ROW_TEXT=##EOF##
            WriteLn>%WRITE_TO_FILE%,WRITE_TO_FILE_result,%NAME_TO_CHECK%
            Goto>EXIT_LOOP
           Else>
                If>FILE_ROW_TEXT=%NAME_TO_CHECK%
                    If>IS_A_VARIABLE=0
                        Let>COLLISIONS_FOUND=%COLLISIONS_FOUND%+1
                        Let>COLLISION_NAMES=%COLLISION_NAMES%%CRLF%%NAME_TO_CHECK%
                        Let>WRITE_FILE=%SCRIPT_DIR%\%NAME_TO_CHECK%.txt
                        WriteLn=%WRITE_FILE%,FILE_NAME_TO_CHECK_result,%krow%
                    Endif>
                Else>
                    Goto>START_OVER
                Endif>
           Endif>
    Else>
        WriteLn>%WRITE_TO_FILE%,WRITE_TO_FILE_result,%NAME_TO_CHECK%
    Endif>
    Label>EXIT_LOOP
    WriteLn>%FINDINGS_FILE%,FINDINGS_FILE_results,%NAME_TO_CHECK%;%krow%
    Let>NAME_TO_CHECK=
END>LOOP

SRT>LOOP_LOOK
      IfFileExists>%LOOK_IN_FILE%
        Let>qrow=0
           Label>START_OVER_LOOK
           Let>qrow=qrow+1
           ReadLn>%LOOK_IN_FILE%,%qrow%,FILE_ROW_TEXT
           If>FILE_ROW_TEXT=##EOF##
            Goto>EXIT_LOOP_LOOK
           Else>
                If>FILE_ROW_TEXT=%NAME_TO_CHECK%
                    If>IS_A_VARIABLE=0
                        Let>COLLISIONS_FOUND=%COLLISIONS_FOUND%+1
                        Let>COLLISION_NAMES=%COLLISION_NAMES%%CRLF%%NAME_TO_CHECK%
                        WriteLn=%WRITE_FILE%,FILE_NAME_TO_CHECK_result,%krow%
                    Endif>
                Else>
                    Goto>START_OVER_LOOK
                Endif>
           Endif>
    Endif>
    Label>EXIT_LOOP_LOOK
    Let>NAME_TO_CHECK=
END>LOOP_LOOK

You have to add your script code to a txt file (Code.txt) in you script folder.

[jpuziano]

I have written a series of HUGE macros, and in reviewing the code, I found a number of places where I had given the same name to two different Labels. (It took me several hours to find all of these.) Many of these errors had been in my code for a number of years. It is to be hoped that jumps to these same-named labels had somehow read my mind and branched to the proper locations. I would pay BIG BUCKS for a Macro assembler which caught most of my coding errors. Some coding errors are extremely difficult to track down, and it is highly likely that some coding errors will never be caught, possibly causing financial loss of many thousands of times the cost of a single copy of Macro Scheduler.

Hi evangelmike,

I agree that a duplicate label or subroutine name can really cause problems. These are known issues - please review the two posts below on the Enhancement Suggestions forum asking for ways to prevent them and if you agree these would be valuable, why not add your voice with additional comments on each of the posts below. Your input may make the difference and get things happening on these:

[Open] Warn and/or Prevent entry of Duplicate Labels
http://www.mjtnet.com/forum/warn-and-or ... t5980.html

[Open] Can GoSub throw error if duplicate Sub names found?
http://www.mjtnet.com/forum/can-gosub-t ... t4585.html

I avoid the problem by being very careful and very descriptive when creating a label or subroutine name... but the danger is always there and there is nothing to warn us.

Of course, we could build our own macro scripts to check for this stuff... read in each line of a script, parse for label names, look for duplicates, warn if a duplicate found, etc. etc. but I haven't as yet because:

1) I'm lazy and haven't been burned BAD enough yet by such a slip
2) I have always thought that such a code-checking function should be built-right-in to Macro Scheduler itself.

On the positive side, I see that Grovkillen has written something that seems to check for duplicates. Thanks for sharing that Grovkillen, I'll have to check it out.

Marcus... I'll add the above two enhancement suggestion links to the topic in Sifter on this since they are related... and thanks for potentially considering adding something to MS itself to warn us if duplicate labels or subroutine names exist in our code... much appreciated.

[Marcus Tettmar]

On further investigation I cannot replicate an issue with subroutines and labels having the same name and in fact you can use subroutines and labels with identical names without error - a Goto looks for a Label with that name, a GoSub looks for a subroutine with that name. So that in itself is not the issue.

[Grovkillen]

Hello,

I'm at work so I'm only able to test this on MS 14.0.11 (I have to wait to update until monday, restrictions from IT in Germany).

Anyways, I have found that this scenario will run but not cause an error:
(script will not trigger "MDL>TEST")

Code: Select all

GoSub>TEST
MDL>TEST

SRT>TEST
    Let>TEST=Hello!
END>TEST

While this will cause an error:
(script will error on "GoSub>TEST")

Code: Select all

Let>TEST=Hello!
GoSub>TEST

SRT>TEST
    MDL>TEST
END>TEST

MS will run this without an error:
(script will not jump back correctly after SRT is done)

Code: Select all

GoSub>TEST
Label>TEST
IfNot>TEST=Hello!,TEST
MDL>TEST

SRT>TEST
  Let>TEST=Hello!
END>TEST

But this will work just fine:
(success)

Code: Select all

GoSub>TEST
Label>TEST
IfNot>VARIABLE=Hello!,TEST
MDL>VARIABLE

SRT>TEST
  Let>VARIABLE=Hello!
END>TEST

I would vote YES for jpuziano's suggestions regarding warning about duplicate names of Subroutines, Labels and Variables. Thanks for reading!

[jpuziano]

I would vote YES for jpuziano's suggestions regarding warning about duplicate names of Subroutines, Labels and Variables. Thanks for reading!

Thanks for your support Grovkillen. Now we just have to convince Marcus it would be worth building these checks and warnings into MS itself.

If anyone else out there reading this supports this idea (or has been burned by the lack of these warnings) let's hear from you... and thanks for listening Marcus... its great to see the continuous improvement of Macro Scheduler over the years!

[Grovkillen]

Today my updated script started acting weird and it was because I used Subroutine name and a variable with the same name. Didn't cause any error message and the result was that it took me 2 hours of error testing before I ran my script (posted above) and found the problem. Please make this a key feature!

Thanks for reading

[Marcus Tettmar]

MJT: My responses in bold italics.

Hello,

I'm at work so I'm only able to test this on MS 14.0.11 (I have to wait to update until monday, restrictions from IT in Germany).

Anyways, I have found that this scenario will run but not cause an error:
(script will not trigger "MDL>TEST")

Code: Select all

GoSub>TEST
MDL>TEST

SRT>TEST
    Let>TEST=Hello!
END>TEST

MJT: In this case the scrip just ends. If you have more after the SRT it would keep going through that. The reason is that END>TEST becomes END>HELLO and therefore the subroutine you are in ("TEST") never ends because a matching end is never found. The only way we could make an error is to change default behaviour so that it gives an error at the end of the script if the end of the subroutine it is currently in is not found, rather than just finish which is what happens presently.

While this will cause an error:
(script will error on "GoSub>TEST")

Code: Select all

Let>TEST=Hello!
GoSub>TEST

SRT>TEST
    MDL>TEST
END>TEST

MJT: Of course this causes an error because TEST is now Hello so Gosub>TEST is looking for a subroutine called "Hello" which does not exist.


MS will run this without an error:
(script will not jump back correctly after SRT is done)

Code: Select all

GoSub>TEST
Label>TEST
IfNot>TEST=Hello!,TEST
MDL>TEST

SRT>TEST
  Let>TEST=Hello!
END>TEST

MJT: This is for the same reasons as in your first example. NOTHING to do with the label. What is happening is that End>TEst is now Hello. It woul be the same as doing:

SRT>TEST
..do soemthing
END>HELLO

It would keep going to the end of the script because it hasn't found the end of the subroutine.


But this will work just fine:
(success)

Code: Select all

GoSub>TEST
Label>TEST
IfNot>VARIABLE=Hello!,TEST
MDL>VARIABLE

SRT>TEST
  Let>VARIABLE=Hello!
END>TEST

MJT: Yes, because you're not changing the name of the subroutine.

I would vote YES for jpuziano's suggestions regarding warning about duplicate names of Subroutines, Labels and Variables. Thanks for reading!

MJT: This has nothing to do with labels which is why your original post probably left me dumbfounded.

All we are seeing here is that you are changing the name of a subroutine while youare inside it and so the end> part is never found. Since MacroScript is interpreted it will keep executing all statements until either the end of the subroutine or the end of the script is found. So what you see is the script just exit. If you had other statements after the End> line you would see those executed. Since the script gets to the end and exits, there is no error as such.

The only proposal I can suggest is that if inside a subroutine and the end of the script is found before a matching End> line then we pop up an error to say "End> not found". I can put that on the wish list.

Nothing to do with labels being confused with subroutines after all.

[Grovkillen]

Thanks for the information Marcus. I was not aware of that you could dynamically name Subroutines. I would have understand that MS would interpret a dynamically named Subroutine if it only accepted it when using "%" i.e.:
Let>TEST=Hello!
SRT>%TEST%
END>%TEST%

Your explanation helped me understand this but I could not find this information anywhere... Please make it more obvious in future relaese (help file etc.). Thanks!!

The only proposal I can suggest is that if inside a subroutine and the end of the script is found before a matching End> line then we pop up an error to say "End> not found". I can put that on the wish list.

I'd like that...

[Marcus Tettmar]

Your explanation helped me understand this but I could not find this information anywhere... Please make it more obvious in future relaese (help file etc.). Thanks!!

It's no different to any other variable and is addressed in the help file under variables.

However, I will make a note to add some extra blurb to the subroutines topic.