Acces Violation Error at adress 00499DB0 in module 'm...

tim167 · Post by **tim167** » Thu Aug 18, 2005 10:00 am

I keep getting this error message while trying to write a very simple script for automatically accepting desktop sharing via msn messenger.

Acces Violation Error at adress 00499DB0 in module 'msched.exe'. Read of adress 00000004.

This error message keeps turning up every time i click the msched icon in the system tray or try to open any menu in msched...
I am forced to stop the msched process from the trask manager (ctrl-alt-dell)

any ideas ?

here is the script:

// detect user when start conversation
wwo>[email protected]*
//start action application sharing
setfocus>Windows Messenger
press alt
release alt
send>a
press up*2
press enter
wwo>Start Application Sharing

//select user from list by keystrokes
send>accepteduser
press enter

//wwo>Deelsessie*
wwo>Sharing -Nothing*
setfocus>Sharing - Nothing*

//select and activate 'Desktop Sharing'+'allow control'

mmr>52,103
lclick
press tab
send>
wait>2
press tab*2
send>
press tab
send>+
press tab*2
press enter

support · Post by **support** » Thu Aug 18, 2005 10:04 am

Does this happen only when this script is running, or all the time? Which exact version of Macro Scheduler are you using - check under Help/About?

If the error occurs when this script is running, at what point does it happen? Please provide log files.

tim167 · Post by **tim167** » Thu Aug 18, 2005 10:14 am

It seems to happen with other scripts too, never had this before.
maybe its got something to do with running it from another computer via messenger/shared desktop?

Version 7.3.5 - 06/12/2004

where are these log files ?

thanks!

support · Post by **support** » Thu Aug 18, 2005 11:28 am

You can enable logging for specific macros under File/Macro Properties. A log file taken at the point of the AV error will narrow down which command/line in the script causes it.

pgriffin · Post by **pgriffin** » Fri Aug 19, 2005 1:01 am

I am having this same issue and it is not only when macros are running. I am running XP Pro and version 7.3

Once this problem occurs, I cannot use QuickLaunch or pull down any menus from the main MacroSched interface. I have to Quit the app and start it again.

Hardware_Tester · Post by **Hardware_Tester** » Fri Aug 19, 2005 2:59 pm

This is a familiar error for me, it happens often, when I use the debug mode.

support · Post by **support** » Fri Aug 19, 2005 3:16 pm

I am deeply concerned about this. I've never seen this error so I would need to replicate it to understand what is causing it. If anyone can provide steps that will replicate it please let us know.

pgriffin · Post by **pgriffin** » Mon Aug 22, 2005 4:47 pm

I get the Access Violation error after I have run this script once. I can still use MacroSched, but can't use QuickLaunch or any of the menus. I can only edit and run scripts.

Let>WW_TIMEOUT=30
CapsOff
exe>C:\Documents and Settings\All Users\Desktop\essick.lnk
Label>WaitforConnection
WaitWindowOpen>Connect Essick*
Wait>.1
pushbutton>Connect Essick*,&Connect
WaitWindowOpen>Connecting Essick*
WaitWindowClosed>Connecting*
wait>1
IfWindowOpen>Error Connecting to Essick*
wait>15
Press ENTER
goto>WaitforConnection
endif>
run>c:\program files\netmeeting\conf.exe
wwo>NetMeeting*
waitready>0
wait>.1
setfocus>NetMeeting*
sct>NetMeeting*,Edit,1,10.10.10.250
wait>.1
PushButton>NetMeeting*,Place Call
wwo>Essick Air's desktop*
waitready>0
wait>1
if>WW_TIMEOUT=FALSE,End
setfocus>Meeting Properties*
PushButton>Meeting Properties*,OK
GetWindowPos>Essick Air's desktop*,npX,npY
Add>npX,300
Add>npY,300
MouseMove>npX,npY
wait>1
LDblclick
Label>End

support · Post by **support** » Mon Aug 22, 2005 4:48 pm

Common thread here appears to be Messenger/NetMeeting/Shared Desktop which are all related apps. Anyone else any problems trying to automate one of these apps?

Hardware_Tester · Post by **Hardware_Tester** » Mon Aug 22, 2005 5:14 pm

Mine has to do with several windows of Msched:
Msched main in the taskbar left of the clock
A Script in an edit-window
and then step-by-step debugging

Bob Hansen · Post by **Bob Hansen** » Mon Aug 22, 2005 5:14 pm

I use Net Meeting, have not really looked at this script yet, but will try to test out tonight.

Bob Hansen · Post by **Bob Hansen** » Mon Aug 22, 2005 5:33 pm

May need to know more about Net Meeting connection and/or link to duplicate the same Net Meeting environment, but....

You may need to insert a SetFocus before the MouseMove. After clicking OK button, that window closes and you may have lost prior focus, and the subsequent DoubleClick may be causing a problem.

Code: Select all

setfocus>Meeting Properties*
PushButton>Meeting Properties*,OK
GetWindowPos>Essick Air's desktop*,npX,npY
Add>npX,300
Add>npY,300

//Insert line here ---------------------
SetFocus>Essick Air's desktop*

MouseMove>npX,npY
wait>1
LDblclick

pgriffin · Post by **pgriffin** » Mon Aug 22, 2005 6:12 pm

I appreciate any input, but the program works perfectly every time. when I get the position of the desktop in NetMeeting, the script never loses focus.

thanks for the input.

Bob Hansen · Post by **Bob Hansen** » Wed Aug 24, 2005 12:59 am

the script never loses focus.

How do you know it never loses focus? Focus is always somewhere, how do you know where focus is when running real time in the macro script? Have you inserted a Message Box to display Active Window before MouseMove? Dynamic and manual running and Single Stepping may not always work identically. I think we are trying to work on the dynamic script.

Just curious if you have added the SerFocus> to test this suggestion(not a big deal to add the one line), or if your response just assumes that this will not help. Adding SetFocus> will be easier than a MsgBox with ActiveWindow name.

I am not claiming that this will fix the problem, but would feel better knowing that for a fact it will not help.

As stated in earlier message, may need to get copy of lnk, may need to know settings and configurations of local and remote systems, OS on both, etc. Testing with my local machines does not duplicate your error. Just trying to find ways to do the testing. In my case, when I clicked OK, manually, I lost focus, that is why I suggested inserting this line.

pgriffin · Post by **pgriffin** » Wed Aug 24, 2005 4:09 am

This thread is about an Access Violation occuring in MacroScheduler. The access Violation does not occur during this script. If you'll read my earlier note, it happens AFTER I have run this script. There is no problem whatsoever with the script I posted. As for adding a setfocus>, I am sure that the window on which I want to click has focus before I move away from it, and therefore will always regain focus upon closing the window that pops up in front of it. If it will make you feel better, I'll add a setfocus, but that won't have any effect on the real point....Access Violation.