We have a macro that works fine on an XP virtual machine on VMWare Workstation. However, if I switch the virtual machine image from a single CPU to dual CPU the macro crashes ("msched.exe has encountered an error and needs to close").
Very strange problem and not sure if this is a VMWare issue or a Macro Scheduler issue. It could even be code, but I suspect not as it works perfectly when only one CPU is assigned to the VM.
Any ideas? I've not looked into this in any detail yet and for the mean time have switched back to a single CPU.
Thanks,
Ken
Macro Scheduler / VMWare Workstation Multi CPU issue
Moderators: Dorian (MJT support), JRL
I am a long time VMware user. I don't have any experience with your problem in nay of my machines. But if I were guessing I would suspect that your macro is running into a timing problem between steps.
Running multi-CPU virtual machines is not necessarily faster than single CPU and VERY often slower. This is an often discussed issue on the VMware forum.
I'll be curious as to what you find.
Running multi-CPU virtual machines is not necessarily faster than single CPU and VERY often slower. This is an often discussed issue on the VMware forum.
I'll be curious as to what you find.
- Marcus Tettmar
- Site Admin
- Posts: 7395
- Joined: Thu Sep 19, 2002 3:00 pm
- Location: Dorset, UK
- Contact:
Have you debugged it and/or enabled logging to determine where in the script the problem occurs? What is the script doing when the crash occurs?
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar
Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?
Thanks for your comments.
I haven't done anything yet to diagnose it. I'll run it through the debugger and see what happens when I get a chance.
I am running several things in parallel and the box has a quad core CPU: so I thought allocating two cores to the VM may help. I was actually going to run some timings to check this as I'm aware that often a single CPU VM performs better overall.
The comment on timing makes sense: there's a lot going on and several points where the script is waiting for an event.
I'll let you know what I discover.
Thanks,
Ken
I haven't done anything yet to diagnose it. I'll run it through the debugger and see what happens when I get a chance.
I am running several things in parallel and the box has a quad core CPU: so I thought allocating two cores to the VM may help. I was actually going to run some timings to check this as I'm aware that often a single CPU VM performs better overall.
The comment on timing makes sense: there's a lot going on and several points where the script is waiting for an event.
I'll let you know what I discover.
Thanks,
Ken
If it is a timing issue, and of course depending on the nature of the scripts involved, your problem may be solved by using "Let>RP_WAIT=1" (switches waiting for program termination on and off in RunProgram) rather than a fixed Wait>n; a more rigorous code implementation. Thanks to JRL for pointing this out to me.
Certainly though if it is a timing issue it would suggest that using >1 CPU's is not to your advantage.
Regards
k
Certainly though if it is a timing issue it would suggest that using >1 CPU's is not to your advantage.
Regards
k
-
- Newbie
- Posts: 3
- Joined: Sun Jan 13, 2013 1:20 am
Re: Macro Scheduler / VMWare Workstation Multi CPU issue
MS blue screens my system when running 2 instances of vmware (1cpu each), takes anywhere from 1 to 12 hours w/ imaging script running. however can run for weeks with just 1 instance of vmware. Makes me think that vmware just has problems handling and interfacing more than 1 core no matter what.klcmay wrote:We have a macro that works fine on an XP virtual machine on VMWare Workstation. However, if I switch the virtual machine image from a single CPU to dual CPU the macro crashes ("msched.exe has encountered an error and needs to close").