Viewing Line number from Compiled Script

[ParoXsitiC]

I am using the error and debug UDF to catch errors from people using my autoit script. I made it so it emails me whatever error that occurs on their system.

When the script is finally compiled, everything works but the lines that are being emailed to me are mostly on line 8000 or so. My au3 file is only 500 lines, but I do have a bunch of include files that I use.

Based on my search that I've done on the forums, the compiled script also counts your includes as part of the program exe so it will output huge line numbers that might not exist in your au3 because of the extra include files.

One method that I read to actually have a method to actually reference those huge line numbers is to actually run the obfuscator in /striponly mode and it will output a very long au3 file with your includes processed into it. However, I think this method only works if your compiled exe file was actually obfuscated to begin with.

I have not used the obfuscator for my compiled exe because of random errors that come up from the include files. I also dont use the default UPX packing offered by SciTe because I dynamically UPX other files into it later on.

Is it true that running the obfuscator in /striponly mode will only produce a file that is helpful if your compiled script is obfuscated? It seems so, as my obfuscated /striponly .au3 has 3000 lines, but my non-obfuscated compiled exe has atleast 8000 lines.

Please tell me if there is any sane method to actually debugging a compiled exe using AutoIT or should I just look into a solution with c# and scrap the idea of using AutoIT.

Edited August 27, 2010 by ParoXsitiC

[AdmiralAlkex]

Understanding? What the... Why don't you spend 5 seconds to try /striponly out and see for yourself?

[ParoXsitiC]

Understanding? What the... Why don't you spend 5 seconds to try /striponly out and see for yourself?

I have, it spews out a file thats 3000 lines, far off from the line 8000 the compiled script stated it had an error on.

Perhaps it should be known that it was an array subscript error, not sure if that makes a difference.

I have edited my original post to be hopefully more understandable.

Edited August 27, 2010 by ParoXsitiC

[MvGulik]

Reading documentation helps.

/CV or /Convert_Vars=0 ; No Variable encryption (Default = 1)

/CF or /Convert_Funcs=0 ; No FuncName encryption (Default = 1)

/CS or /Convert_Strings=0 ; No String encryption (Default = 1)

/CN or /Convert_Numerics=0 ; No Numeric encryption (Default = 1 )

/SO or /StripOnly ; Set the options to: /SF /SV /CV=0 /CF=0 /CS=0 /CN=0

/SOI or /StripOnlyIncludes ; Same as /SO but will leave masterscript untouched.

/OM or /ObfuscateMinumum ; Generates a much smaller obfuscated file.

/SF or /StripUnusedFunc ; Remove Func's that are not used by the MainScript. (Default = 0)

/SV or /StripUnusedVars ; Remove unused Gobal Variable declarations lines. (Default = 0)

/SCI or /showconsoleinfo 0 ; Default Minimal output to the console; warning and errors.

/SCI or /showconsoleinfo 1 ; Show more progress information.

/SCI or /showconsoleinfo 9 ; Show all debug lines as found in the Obfuscator.log

/Beta ; Use the AutoIt\Beta\Include files

[JohnOne]

If you have created an executable script for others to use, you probably should add your own error checking in it, perhaps generating a string indicating where the error lies.

[ParoXsitiC]

If you have created an executable script for others to use, you probably should add your own error checking in it, perhaps generating a string indicating where the error lies.

The errors occur in AutoIT, normally in the include files. As far as I know there is no way for me to actually catch and generate a line number from errors that I do not foresee (array subscript errors, etc). If there is, please link me or discuss methods.

[ParoXsitiC]

Reading documentation helps.

/CV or /Convert_Vars=0 ; No Variable encryption (Default = 1)

/CF or /Convert_Funcs=0 ; No FuncName encryption (Default = 1)

/CS or /Convert_Strings=0 ; No String encryption (Default = 1)

/CN or /Convert_Numerics=0 ; No Numeric encryption (Default = 1 )

/SO or /StripOnly ; Set the options to: /SF /SV /CV=0 /CF=0 /CS=0 /CN=0

/SOI or /StripOnlyIncludes ; Same as /SO but will leave masterscript untouched.

/OM or /ObfuscateMinumum ; Generates a much smaller obfuscated file.

/SF or /StripUnusedFunc ; Remove Func's that are not used by the MainScript. (Default = 0)

/SV or /StripUnusedVars ; Remove unused Gobal Variable declarations lines. (Default = 0)

/SCI or /showconsoleinfo 0 ; Default Minimal output to the console; warning and errors.

/SCI or /showconsoleinfo 1 ; Show more progress information.

/SCI or /showconsoleinfo 9 ; Show all debug lines as found in the Obfuscator.log

/Beta ; Use the AutoIt\Beta\Include files

When I try to run the options without /SF and /SV it complains:

!File contains records longer than 2047 .. stopping process.

!Ending Obfuscator program.

[ParoXsitiC]

When I try to run the options without /SF and /SV it complains:

!File contains records longer than 2047 .. stopping process.

!Ending Obfuscator program.

I have realized this is due to SQLite.dll.au3 which has lines up to 4095

[Melba23]

ParoXsitiC,

The errors occur in AutoIT, normally in the include files

As you started this thread to find out how to identify the error line, I do not see how you can state that with any degree of certainty. Indeed I would quite surprised if the include files caused the error unless your script passed them some indigestible parameters - there is a fair bit of errorchecking in the standard set of includes, but that can still be broken if you try hard enough!

That aside, Jos fixed the 2047 character input line limit in v1.0.15 as you can see here. Are you running the up-to-date version of Obfuscator - 1.0.28.7? If not you you can download it from here.

I use these directives for all of my compiled scripts and I have yet to have a problem with Obfuscator:

#AutoIt3Wrapper_Run_Obfuscator=y
#Obfuscator_Parameters=/sf /sv /om /cs=0 /cn=0

The line numbers returned by the compiled script will match those in the YourScript_Obfuscated.au3 file, unless you have used the "line continuation" underscore which throws it out from that point onwards.

I hope this helps.

M23

[ParoXsitiC]

ParoXsitiC,

As you started this thread to find out how to identify the error line, I do not see how you can state that with any degree of certainty. Indeed I would quite surprised if the include files caused the error unless your script passed them some indigestible parameters - there is a fair bit of errorchecking in the standard set of includes, but that can still be broken if you try hard enough!

That aside, Jos fixed the 2047 character input line limit in v1.0.15 as you can see here. Are you running the up-to-date version of Obfuscator - 1.0.28.7? If not you you can download it from here.

I use these directives for all of my compiled scripts and I have yet to have a problem with Obfuscator:

#AutoIt3Wrapper_Run_Obfuscator=y
#Obfuscator_Parameters=/sf /sv /om /cs=0 /cn=0

The line numbers returned by the compiled script will match those in the YourScript_Obfuscated.au3 file, unless you have used the "line continuation" underscore which throws it out from that point onwards.

I hope this helps.

M23

Yes, The first thing I did was google that error and realized he said he fixed it, I downloaded the newest AutoIT non-beta, the newest SciTe install, it still didn't work. I downloaded the newest Obfuscator and then replaced the one SciTe had (even though they were the same) and it still didnt work. The Obfuscator seems to still be plagued with the error.

I am certain its part of the includes I have because I use the old zip.au3 and I have personally seen the sporadic error in testing. Also, you're right some of it could be my error as well. The point is that I can only catch errors that I can forsee. As far as I know there is no way for me to capture AutoIT script errors which cause the script to shutdown. The only attempt at that is the debug UDF I am already using which runs in the background, waits for autoit to exit and error and then it reads the console. Which displays large line numbers.

I understand that if I can fix the errors obfuscater generates (3 that say potentially break my script, and 1 where SQLite.dll.au3 disallowed it to run) then If I compile a obfuscater script and hand THAT version out, then I can match it with my obfuscated au3. However, right now about 50 people have a non-obfuscated compiled script. Which comes back to my first question, will a non-obfuscated compiled script release numbers of a obfuscated au3?

Also, many of the includes use Opcode (which requires line continuation) and I even run SQLite queries formatted using line continuation throughout. Based on what you are saying, even if I was to fix the issue obfuscator has with my includes, fix the SQLite.dll.au3 records error, recompile the script with obfuscation, force everyone to download the new compiled script with obfuscation. That it still won't work, because of line continuation.

[Melba23]

ParoXsitiC,

I use the old zip.au3 and I have personally seen the sporadic error in testing

Try wraithdu's new Zip UDF - it is much better!

will a non-obfuscated compiled script release numbers of a obfuscated au3

Most unlikely as obfuscating the script will remove various lines (unwanted functions, comments, etc) and then compile the resulting YourScript_Obfuscated.au3 file. So the au3 files and the resultant exes will not be identical and will give different line numbers for the same error.

it still won't work, because of line continuation

Quite likely I would have thought, although I do not use line continuation anywhere near the scale you seem to.

Sorry if I seem to be the bearer of bad news - it seems you are asking for rather more than AutoIt can currently give.

M23

[JohnOne]

I am certain its part of the includes I have because I use the old zip.au3 and I have personally seen the sporadic error in testing. Also, you're right some of it could be my error as well. The point is that I can only catch errors that I can forsee. As far as I know there is no way for me to capture AutoIT script errors which cause the script to shutdown.

I dont get this, you say it only happens when compiled and blame it on standard includes, then you say you see the error when testing (I have to assume this is uncompiled), so which is it?

When you are using the included UDFs, you are using different functions within them, and most, if not all have error checking, so you need to test these in your own script and report the function which its coming from, you dont need a line number.

[ParoXsitiC]

Try wraithdu's new Zip UDF - it is much better!

I planned to, but I was getting an error (Look at the lost posts of the thread, you can see I made a few comments). I had to use the old zip.au3 because I was forced on a deadline. I will use the new zip UDF in my next release.

I dont get this, you say it only happens when compiled and blame it on standard includes, then you say you see the error when testing (I have to assume this is uncompiled), so which is it?

When you are using the included UDFs, you are using different functions within them, and most, if not all have error checking, so you need to test these in your own script and report the function which its coming from, you dont need a line number.

The zip include I was using had errors, but they were very sporadic. I thought I had cleared all of them by adding a few sleeps into the udf. Worked fine for me, but I am getting about 20 complaints that errors are happening, as the only error I could duplicate in my limited testing was with the zip udf. Plus using the obfuscated output, the line 8000 is within 500 lines of the zip UDF.

[MvGulik]

Seems off topic now. But are you now using Obfuscator at build time to create a full-source-code/line reverence file ?

[ParoXsitiC]

Seems off topic now. But are you now using Obfuscator at build time to create a full-source-code/line reverence file ?

I do not compile my script with Obfuscator (As there are many errors).

But when I attempted to create a reference file, yeah.