Latest Beta

[Jos]

Doesn't look to me you are running the Beta version here when its running the AU3Check from C:\Program Files\AutoIt3.

Just use Alt+F5 or ALt+F7 to use Beta in stead of "switching" .....

[Triblade]

Doesn't look to me you are running the Beta version here when its running the AU3Check from C:\Program Files\AutoIt3.

Just use Alt+F5 or ALt+F7 to use Beta in stead of "switching" .....

Ok, cool thanks for the info!

Didn't know you have to run the script differently when switched.

[Jos]

Ok, cool thanks for the info!

Didn't know you have to run the script differently when switched.

I don't know what you mean by Switching, but that is just simply not needed. Use the proper shortcuts and you select which version is used.

See this webpage for an explanation: http://www.autoitscript.com/autoit3/scite/...nstallation.htm

Jos

[pdaughe]

I installed the new beta and recompiled my application. I generally try to keep up with the betas, but I was running 13.3.

13.6 worked fine on Windows XP.

HOWEVER, IT FAILED UNDER VISTA.

My application is composed of multiple compiled AutoIT scripts. The main exe "Run" the other exe's.

The MOMENT the main application attempts to RUN the first exe, Windows Data Execution Prevention (DEP) closes the process and reports that it attempted to use memory normally reserved for Windows improperly.

Here is Vista event log for the problem:

Product
Total Memories Viewer Service

Problem
Stopped working

Date
8/2/2008 8:51 PM

Status
Report Sent

Problem signature
Problem Event Name: BEX
Application Name:   Viewer.exe
Application Version:    2.4.0.0
Application Timestamp:  4890bee6
Fault Module Name:  StackHash_a53e
Fault Module Version:   0.0.0.0
Fault Module Timestamp: 00000000
Exception Offset:   009ca158
Exception Code: c0000005
Exception Data: 00000008
OS Version: 6.0.6001.2.1.0.768.3
Locale ID:  1033
Additional Information 1:   a53e
Additional Information 2:   9458bcae6f2a95d03cd3c8ea9a67196c
Additional Information 3:   5da6
Additional Information 4:   b27b1007aadedbdb542b323f64e08c2b

Extra information about the problem
Bucket ID:  297714101

The problem is repeatable and happens every time.

If there is any additional information I can provide, please let me know.

Sincerely,

Paul

Developer@twmi.rr.com

[Valik]

If there is any additional information I can provide, please let me know.

A simple reproduction script.

[Jon]

We turned on DEP in the latest beta, so windows really enforces certain operations. If a simple script shows the problem then we may have a bug. If the script is playing directly with areas of memory that it shouldn't be, or not making the right calls before it does, then it may be the script.

[Valik]

Jon, didn't you turn DEP back off?

[Jon]

Jon, didn't you turn DEP back off?

No, I left it on but turned off image randomization (the one that seemed to be breaking Aut2Exe). DEP is quite a useful one, and I think the x64 exes are much stricter about memory access anyway (remember the code execution trouble I had with x64 and Callback register) - the fact that x64 builds are working well gives me a bit of confidence that we are not breaking DEP-like rules. As far as I know AutoIt should be DEP safe, but might have done something bad somewhere which would be worth trying to fix if it turns out I'm wrong. Either way we'd need a repro script.

[pdaughe]

No, I left it on but turned off image randomization (the one that seemed to be breaking Aut2Exe). DEP is quite a useful one, and I think the x64 exes are much stricter about memory access anyway (remember the code execution trouble I had with x64 and Callback register) - the fact that x64 builds are working well gives me a bit of confidence that we are not breaking DEP-like rules. As far as I know AutoIt should be DEP safe, but might have done something bad somewhere which would be worth trying to fix if it turns out I'm wrong. Either way we'd need a repro script.

I've tried to reproduce the problem with a simple script (e.g. just RUNing another exe works) -- so far, the "simple" scripts work. It's 1:20 US E.S.T. and I have some (wife) responsiblities today, but will work on this first thing tomorrow morning. I have tripled-checked the scenario though; absolutely no code changes --- if I compile under 13.6 the problem occurs everytime; with 13.3, it's fine. I am running Vista, Service Pack 1, with all available updates applied. This problem does NOT occur for me under Windows XP PRO, Service Pack 3, all updates applied.

[Jon]

Vista and XP have different DEP capabilities I believe. Also your XP machine maybe older and the CPU in that probably does not have DEP hardware support.

[pdaughe]

I see that for both Vista and XP, DEP is turned on for "essential Windows programs and services only", although as Jon suggested, DEP could obviously be different on the two operating systems.

Jon's suspicion was correct: at the bottom of the Data Execution Prevention tab (Performance Options dialog), on my VISTA machine it says: "Your computer's processor supports hardware-based DEP".

As soon as I get time to work on this, I hope to be able to narrow it down to the specific AutoIt function. I have a fairly robust trace facility built-in....

Paul

Edited August 3, 2008 by pdaughe

[Jon]

The DEP option "essential services blah" is for "normal" executables. When someone compiles a program you can mark it as DEP compliant which means it runs with DEP always (if the hardware supports it) regardless of that OS setting - or so I believe. That's what we did with AutoIt recently. It would be great to find out what's triggering the problem.

[pdaughe]

The DEP option "essential services blah" is for "normal" executables. When someone compiles a program you can mark it as DEP compliant which means it runs with DEP always (if the hardware supports it) regardless of that OS setting - or so I believe. That's what we did with AutoIt recently. It would be great to find out what's triggering the problem.

"It would be great to find out what's triggering the problem".

I know! We just can't get it out of our blood can we -- we've GOT to trace down that problem. Well, HERE IT IS:

My program A launches program B using RUN. That works fine (Valik). Program B executes a couple of hundred statements and then attempts

this statement:

GUICtrlCreateObj

Am I correct in suspecting it is the control itself that is causing the problem?

If so, AutoIt has does me a real favor, since this is a purchased control. At least I assume that is what this DEP is all about: a program tried to address memory belonging to a page which was not allocated to the process's address space. That may not be the correct terminology, but my background is mainframe, and the mainframe provides storage protection for each 4K physical page of memory.

Anyway, it is important for me to note that program B had already successfully embedded another activeX control.

I instantiate all the controls, and in some cases multiple instances therefof, in one function called during program B's initialization. This function completed normally.

I successfully embedded one control, but the GUICrlCreateObj for the second control never returned (I had a trace statement right before it, and right after it).

Curious as I am, I turned on DEP under XP for all programs, but my application still ran fine. We would suspect the software-based DEP not to be as comprehensive as the hardware-based DEP. Actually, I'm surprised Vista doesn't turn in on for all programs when the processor supports it. If my understanding of this is even close, I believe you are right on in activating DEP for compiled AutoIt programs.

That's all I know to do at this point. If you want me to do anything else, I be pleased to assist in whatever why I can. By the way, the control is from ELPhotox.com. I have already e-mailed their support to inquire about the problem.

Thank you again -- all of you -- for such a fine product. AutoIt rocks!

Sincerely,

Paul

[Valik]

Three questions. First, does that ActiveX component have a trial? If yes. Can you create a simple script that reproduces the issue? If the control is doing something, then it shouldn't take more than just a handful of lines to reproduce it.

Lastly, anyone know if VMware is able to simulate hardware-based DEP on a Vista virtual machine? I do not have a DEP capable processor.

Edit: The answer is no, VMware can't simulate hardware-based DEP. Can you get this (not) working with Vista's software-based DEP? What about the control, does it spawn an EXE by any chance?

Edited August 3, 2008 by Valik

[pdaughe]

Three questions. First, does that ActiveX component have a trial? If yes. Can you create a simple script that reproduces the issue? If the control is doing something, then it shouldn't take more than just a handful of lines to reproduce it.

Lastly, anyone know if VMware is able to simulate hardware-based DEP on a Vista virtual machine? I do not have a DEP capable processor.

Edit: The answer is no, VMware can't simulate hardware-based DEP. Can you get this (not) working with Vista's software-based DEP? What about the control, does it spawn an EXE by any chance?

I visited ELPhoto's web site -- it's not clear whether they have a trial is it? This I know FOR SURE: I wouldn't have purchased it if it did not have a trial (however, I purchased it nearly two years ago). Nevertheless, I have had several communications with the developer in times past. In fact, the link to the AutoIt web site on the ELPhoto web site is due to my encouragement and working with the developer (we users do try to express our appreciation!). SO, even if a trial is not available, I may be able to arrange to send a working copy in a simple script. This may take a couple of days though...

The control does NOT not spawn any additional processes.

My Vista machine ($322 from NewEgg, including shipping) is a relatively low-end machine running a Intel dual-core E2160 1.8GHZ which DOES support hardware-based DEP. Jon evidently is aware that even these relatively low-end processors support hardware-based DEP. To my knowledge, there is no way for me to force Vista to use software-based DEP.

My development machine is an AMD 3800+ running XP PRO. Apparently, the 3800+ does not support hardware-based DEP. As I mentioned before, I enabled the software-based DEP on this machine for all programs, and the application ran fine. So sorry, I have no way to my knowledge of testing it under Vista with software-based DEP only.

[Valik]

According to Wikipedia, software DEP isn't even the same thing, so that's rather unhelpful. I do have a 64-bit processor that could have hardware DEP but it's a bit of a pain to get that machine running unless somebody wants to donate a power supply to me. I honestly don't know if it has it or not and I don't even know what the processor is other than AMD so I pretty much have to boot it to check.

There is a download on the site which seems to imply it might have a trial but I could find no mention. I didn't bother to download it at the moment as I won't be able to even check if the other machine has DEP until tomorrow.

[GEOSoft]

According to Wikipedia, software DEP isn't even the same thing, so that's rather unhelpful. I do have a 64-bit processor that could have hardware DEP but it's a bit of a pain to get that machine running unless somebody wants to donate a power supply to me. I honestly don't know if it has it or not and I don't even know what the processor is other than AMD so I pretty much have to boot it to check.

There is a download on the site which seems to imply it might have a trial but I could find no mention. I didn't bother to download it at the moment as I won't be able to even check if the other machine has DEP until tomorrow.

What numbers do you have on that processor Valik? I probably have the info to determine what it is.

[Valik]

Uhh, it's AMD and 64-bit. Outside of that I just plain don't remember.

[GEOSoft]

Uhh, it's AMD and 64-bit. Outside of that I just plain don't remember.

Hmmm. That isn't quite enough info. If you take it off the board and get the numbers I can probably help out. Unfortunatly I also don't have any spare power supplies kicking around and AMD's can be fussy about power. As a matter of fact I need a PS for a 3200+ that I have sitting here.

[Jon]

Valik: All x64 chips have DEP I believe.

P: DEP is not turned by default for all processes because it breaks far too many programs that aren't coded for it.

As it's coming from an external control and we want to ensure that we can happily run most controls, we might have to do what windows does and leave it off for compatibility sake. I'd forgotten that we sometimes execute other controls that may not work. I'm happy that "our" code is DEP compliant though