GDI+ Error

Support for iMacros. The iMacros software is the unique solution for automating every activity inside a web browser, for data extraction and web testing.
Forum rules
Before asking a question or reporting an issue:
1. Please review the list of FAQ's.
2. Use the search box (at the top of each forum page) to see if a similar problem or question has already been addressed.
3. Try searching the iMacros Wiki - it contains the complete iMacros reference as well as plenty of samples and tutorials.
4. We can respond much faster to your posts if you include the following information: CLICK HERE FOR IMPORTANT INFORMATION TO INCLUDE IN YOUR POST
Post Reply
YoDoNo
Posts: 1
Joined: Wed Mar 06, 2019 1:43 pm

GDI+ Error

Post by YoDoNo » Wed Mar 06, 2019 1:53 pm

Hi, i wrote a smal script which refreshes a page (with the loop), search for a word on this page and clicks on a special position.
VERSION BUILD=12.5.503.8802
TAB T=1
TAB CLOSEALLOTHERS
SET !ERRORIGNORE YES
URL GOTO= a privat url :wink:
TAG POS=1 TYPE=TD ATTR=TXT:"a word :wink: "
DS CMD=CLICK X=921 Y=565
WAIT SECONDS=0.1
After 3300 loops, the Programm freezes and i get this error message in the error log file
2019-03-04 00:41:47Z
iMacros version 12.5.503.8802, IE version 11.590.17134.0, OS version Microsoft Windows NT 6.3.9600.0

Exception at Void CheckErrorStatus(Int32)
Allgemeiner Fehler in GDI+.
bei System.Drawing.Graphics.CheckErrorStatus(Int32 status)
bei System.Drawing.Graphics.FillPolygon(Brush brush, Point[] points, FillMode fillMode)
bei System.Drawing.Graphics.FillPolygon(Brush brush, Point[] points)
bei System.Windows.Forms.ToolStripRenderer.OnRenderArrow(ToolStripArrowRenderEventArgs e)
bei System.Windows.Forms.ToolStripProfessionalRenderer.OnRenderArrow(ToolStripArrowRenderEventArgs e)
bei System.Windows.Forms.ToolStripRenderer.DrawArrow(ToolStripArrowRenderEventArgs e)
bei System.Windows.Forms.ToolStripDropDownButton.OnPaint(PaintEventArgs e)
bei System.Windows.Forms.ToolStripItem.HandlePaint(PaintEventArgs e)
bei System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
bei System.Windows.Forms.ToolStrip.OnPaint(PaintEventArgs e)
bei System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
bei System.Windows.Forms.Control.WmPaint(Message& m)
bei System.Windows.Forms.Control.WndProc(Message& m)
bei System.Windows.Forms.ScrollableControl.WndProc(Message& m)
bei System.Windows.Forms.ToolStrip.WndProc(Message& m)
bei System.Windows.Forms.StatusStrip.WndProc(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Can someone help me?
Tom, Tech Support
Posts: 3513
Joined: Mon May 31, 2010 4:59 pm

Re: GDI+ Error

Post by Tom, Tech Support » Fri Mar 08, 2019 12:27 pm

Hi YoDoNo,

One thing you need to keep in mind when using a product like iMacros is that web browsers in general are not designed for automation. This even applies to the iMacros browser to the extent that it is using the core IE engine. Attempting to push browsers beyond the limits of typical, ordinary usage patterns performed by actual humans invariably leads to memory issues - mostly due to leaks in the browsers themselves and not necessarily iMacros - and other weird side effects that can be difficult to troubleshoot as discussed in the following article:

http://wiki.imacros.net/Web_Testing#Q:_ ... iMacros.3F

The best way to offset and avoid these types of issues is by using the iMacros scripting interface to periodically restart the browser during your automated processes.
Regards,

Tom, iMacros Support
chivracq
Posts: 8625
Joined: Sat Apr 13, 2013 1:07 pm
Location: Amsterdam (NL)

Re: GDI+ Error

Post by chivracq » Fri Mar 08, 2019 2:29 pm

Tom, Tech Support wrote:
Fri Mar 08, 2019 12:27 pm
Hi YoDoNo,

One thing you need to keep in mind when using a product like iMacros is that web browsers in general are not designed for automation. This even applies to the iMacros browser to the extent that it is using the core IE engine. Attempting to push browsers beyond the limits of typical, ordinary usage patterns performed by actual humans invariably leads to memory issues - mostly due to leaks in the browsers themselves and not necessarily iMacros - and other weird side effects that can be difficult to troubleshoot as discussed in the following article:

http://wiki.imacros.net/Web_Testing#Q:_ ... iMacros.3F

The best way to offset and avoid these types of issues is by using the iMacros scripting interface to periodically restart the browser during your automated processes.
Oh, "good", exactly what I thought also... And I was even thinking, "hum 3300, you can be happy actually", I run some ('.iim') Script non-stop all day every day for 21h in FF (using v8.9.7), and I feel "lucky" already if I can reach 1000 Loops before FF will crash or become very slow that I have to kill it and restart it...

And my Scenario is pretty similar, always reloading the same Page, and extracting several Elements, used to monitor Users, from 2 Scripts running in parallel in the same FF Profile, both on the same Page/URL, one extracting 9 Fields (3 (suspicious) Users) and Refresh every 30 Sec (approx, the 'WAIT' is a bit dynamic, depending on if any of those 3 Users is/are "active"), the other one extracting 60 Fields (20 Users) and Refresh every 60 Sec, + 'SAVEAS' for both (with their own separate Log File).

And without using the 'Scripting Interface', if the 3300 Loops take, say about 3 hours for example, an other Approach is to launch the Script from a '.BAT' File from the OS Task Scheduler every 2 hours for example with a 'taskkill' on the Browser... I've explained the "Technique" already several times in different Threads...
The only slight "Drawback" I've noticed, is that the Browser and the Script launched from the Task Scheduler strangely enough will hold shorter than the "expected" 3 hours if they were launched "manually", or will quicker become slower... => So the "2 hours" Timelaps from the Scheduler really needs to be shorter than the "3 hours" if run manually...
I only tested with FF and Pale Moon, both the same Result and with different Versions of iMacros for FF, I don't know if iMB (or IE) behaves the same when launched from the Task Scheduler... (And I never saw anybody reporting that Behaviour (for any Browser and any Version of iMacros) on the Forum...) It could be related to my "specific" FF and PM Profiles (both more or less the same, with about the same 50+ Add-ons, from before WebExtensions), and/or the Site I run that Script onto..., which uses some Flash..., which also regularly crashes... I don't know...
- (F)CI(M) = (Full) Config Info (Missing): iMacros + Browser + OS (+ all 3 Versions + 'Free'/'PE').
- I don't even read the Qt if that (required) Info is not mentioned...!
- Script & URL help a lot for more "educated" Help...
Post Reply