Home Image-Pro Automation (Macros, Apps, Reports)

Error message about 'The number of USER objects has reached a maximum of 9800'

Hi guys,

We developed an Apps program for image batch analysis on IP-10 version 10.0.4.

The goal of batch processing is to open more than 600 images for analysis, and each image will be closed immediately after the analysis is completed. The image processing steps will open each image one by one and than to make two or three mask image to do image processing and counting.

Unfortunately, our program will pop up an error message about 'The number of USER objects has reached a maximum of 9800, please close some workspaces and try again.' when it reaches more than 300 images.

We try to write another simple Apps program that only executes the process of open image and close image. The same message will pop up after reaching about 1200 images.

If we close this error message, IP-10 will pop up another macro execution error message about '(&H80131502) Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index'.

I guess this is a macro bug caused by the workspace object being closed because the object does not exist.

I'm not sure if the problem is a limit on the number of workspace objects or the memory on IP-10 has not been effectively reuse.

Please help me to solve this annoying problem, thanks!


  • Hi Jims,

    It looks like some objects are not released in the macro loop. Can you please send us the "Loop on" macro and a couple of test images, so we can check the problem?


  • 2019-12-27-100926

    Yuri --

    Would the setting of

        (shown below)

    be an issue for this user?

    I remember when the default of 10000 was causing one of my apps to have issues.


    -- Matt

  • Matt,

    No, this is not related to "Individual Object display limit", it's rather related to accumulation of "User objects" and not releasing them. Every Windows program may have only 10000 objects, so the code should take care of closing unnecessary windows and releasing unused objects. 

  • 2019-12-30-110741

    Yuri --

    Thank you for that additional information.

    Is there a way to determine the number of WINDOWS OBJECTS that are in use by IP and APPS running within IP?

    Thanks again.

    -- Matt

  • In the Windows 10 Task Manager "Details" tab, you can left-click on the column headers, then "Select columns" and add any of the many available metrics, including "User objects" and "GDI objects".
  • 2019-12-30-113552

    Craig --

    Thank you for the information.

    I have WIN 7 on my main machines and based on your suggestion, I find I can access that via TASK MANAGER + VIEW + SELECT COLUMNS.

    IP 10 has 561 USER OBJECTS and 848 GDI OBJECTS after startup with no images open.

    There is some really interesting information available there.  COMMAND LINE is very revealing!

    Thanks again.

    -- Matt

  • YuriG said:

    No, this is not related to "Individual Object display limit", it's rather related to accumulation of "User objects" and not releasing them. Every Windows program may have only 10000 objects, so the code should take care of closing unnecessary windows and releasing unused objects. 

    Hi Yuri,

    We wrote a testing Apps that only performs simple OPEN image and CLOSE image jobs, also monitor the changes of the USER objects field in the TASK MANAGER.

    When Apps executed nearly 1290 images, the number of USER Objects in the TASK MANAGER was also close to 9,800.  For sure, as long as the number of USER Objects exceeds 9,800, IP-10 will immediately pop up the error message. It's interesting that we have tried different image formats with the same result.

    In addition, we used the BATCH PROCESSING tool to do the same test. The number of USER Objects will be controlled within a normal range will not continue to increase. So we are sure that the BATCH PROCESSING tool will continuously releasing useless USER Objects.

    May I know if there is any way to release USER Objects manually?

    Happy New Year and Thank you in advance!


  • Jims,

    If you confirmed that the number of user objects do not increase during batch processing, then something special is in your app. User objects are created by UI elements, so you may check if your app dialog is not accumulating them. Try switching off any app dialog updates during batch processing and see if it makes any difference.


  • Hi Yuri,

    Please refer to the attached project file.
    We were tested commands 'DocumentCommands.Open' and 'MCimage.open'.
    And just only using a 'for ... next' loop to open image. It will increase user objects number continue until finished the loop.
    After that, i clicked any workspace function in IP-10. The user objects number was immediately reduced.

    [ Ready for open image loop ] 

    [ Looping 20 times ]

    [Finished loop]

    [Just open new image from workspace button]

    Best Regards,
  • Hi Wesan,

    Thank you for providing a test macro. I could also see that the number of user objects increases in the loop, though all objects are released properly when I run GarbageCollect macro after that.

    We will investigate the issue further, and for now I can suggest a solution that would avoid User Objects accumulation and speed up the processing: you can open images as "invisible", which is much faster and doesn't create UI elements with associated events. All commands will handle invisible images the same way as visible, just pass the right img object. 
    Here is how a modified version of OpenMcImageTest macro may look like:
        Public Sub OpenMcImageTest(ByVal filename As String)
            Dim img As McImage = Nothing
            If FirstLoad = True Then
            End If
            img = ThisApplication.Images.Open(filename,mcImageCreateFlags.mcicfNoAddToCollection Or mcImageCreateFlags.mcicfNotVisible)
            'do something with img
            img = Nothing
        End Sub

    And that's how you can modify ApplyImage macro to work with invisible images:

        Public Function Applyimage() As SimpleScript
            Applyimage = New SimpleScript
            Dim docList1 = New List(1)
             If FirstLoad = True Then
                Exit Function
            End If
            With Application.DocumentCommands.Open(Applyimage)
                .Filenames = New String() {Load_ImageName}
            End With
            Dim doc As IMcDocument=docList1(0)
            'do something with doc
            Debug.Print doc.Name
            With Application.WindowCommands.CloseAll(Applyimage)
            End With
            docList1 = Nothing
        End Function

  • Hi Wesan

    ...this problem  is related to the number of GDI objects. You can increase that number that is by default 10000 in the windows registry, then it will appear less often. You can switch the number to max 65,536. Search registry for GDIProcessHandleQuota. 

    In WS7 it gave the right error message, from then on it just crashes (up to killing your explorer and need of full restart). 

    If Yuri's suggestion would work? - I guess so because if not producing image handles, then those handles are also not counted up. However, I did not yet find solutions for all functions to run with .visible = False. 


  • Hi Daniel,

    The problem is related to the the quota on GDI objects and USER Objects per process. Yes, the default is 10000 and you can adjust it in the registry, but Image-Pro checks it itself and the default limit is 9800 (though it could also be adjusted in the settings, but not exceed the registry value).

    We are working on fixing the issue and it should be included into the next patch, but for now, you can use my recommendations as workarounds. Working on invisible images will prevent USER and GDI objects accumulation in loop macros and also significantly speed up processing. If you cannot find a way to run some functions on invisible images, please send me the code (Click here to upload files) and I will check it.



  • HI Yuri, 

    Actually the problem was resolved for v9.3 and Windows 10, but now appearing again with IPP v10 and Windows 10 (and likely also 11). 
    Will you work on this again, please? 
    It is very tedious since in the meanwhile we are not allowed to change registry anymore and every time have to poke the IT administration to do this (on 5 computers). It's unfortunately not stable with updates (WS updates again reset the GDI object limit to the senseless 10.000... 
    Best wishes, 
  • Hi Dan,

    Can you please share your macro and several test images, which could reproduce the problem? I want to check if the macro can be modified to avoid accumulation of User objects (e.g. working with invisible images, or clean ups).

    If you can share it, please upload the IPX file and test images here: Click here to upload files.

  • Hi Yuri, 
    My macro is huge and it will not be easy to give you that (needs quote some environment as well). Also it does not make a difference. 
    The problem is linked to IPP10 with WS10, appeared with WS7 and IPP 9.2, was resolved with WS10 and IPP9.3 and now appeared again with IPP10. All with the same code (and I use garbage collect asf), so code-independent. This just has to do with image handles in WS and obviously you had a solution already in 9.3. It just did not go through to IPP10. We need this high number of handles due to our very high throughput image analyses... 

  • Hi Dan,

    The leak of user and GDI objects was fixed in latest updates, so it doesn't exist in IP 10.0.11 for image and set windows, but the issue is to release all unused objects within the macro loop (calling GarbageCollect within the loop will not work), so you may use shorter loops and call Garbage Collect manually, after executing the loop, or use Timer events. 
    I've attached a test macro that checks user and GDI object leaks opening and closing images, run every macro several times to see if they detect any leaks.

    If no leaks are detected by test macros, try to modify macros adding your code, that could reproduce the leaks, so we can investigate the problem.

  • Great - many thanks Yuri. We'll test. 

Sign In or Register to comment.