How to go beyond the 10000 GDI objects limit with NT7 or NT8?
My current workspaces have too much GDI objects and make Ninjatrader crash when changing workspaces. I've read on google about changing the maximum in the registry to over 10000 handles with the GDIProcessHandleQuota(HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\GDIProcessHandleQuota)
but it seems like a maximum I can't unlock. Does someone else achieved a way to go over this number?
I've tried to add desktop heap too but doesnt work neither (reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contr ol\Session Manager\SubSystems" /v windows).
I'm using windows 10 64 bit. I've seen post about other people having done this in previous windows but not yet on this new windows.
The thing is that I don't actually have 10000 objects showed at the same time more like 3000 but when I change workspaces (something that I do often) NT always crash with my 10 workspaces. Since NT just go over for a second maximum thats why I wanted to go over 10000 to keep NT stable. I like all of my workspaces open at first and idealy I would like to find a solution in this way.
I know its not common to go over 10k and google has told me so too since theres really not much on the subject. I just wonder why I can't unlock it with windows 10. On my actual setup I've got a way to make it work with 9 workspaces without problem but I plan going to 4k monitor soon so I'll open more charts and I'm affraid I'll come accross this problem once again.
Well, as @rleplae was suggesting it seems unreasonable to need to do that, your brain certainly won't be able to make use of all of them..
However, more likely it is simply code that is creating resources but not releasing them, that's where I would start to look.
I run vast workspaces and chart and indicator combinations and NT (7) usually has no problem with resource allocation or cpu usage unless the code is wrong. There is however, as you point out, a fixed per process GDI limit on Windows, and since GDI's get taken from the system wide pool that seems reasonable to me. Looking for resource management issues first, and then whether you really need to do something the way it is being done would definitely be my input.
The following user says Thank You to ratfink for this post:
It's maybe something else that create the crash but NT technician told me there was a problem in the log saying that NT wasnt able to create an handle and that it make the program crash. If I close any of my 10 workspaces the crash doesn't occur no more and it begun when I've created 8 new charts on 2 workspaces.
Can you explain what do you mean by code creating ressources but not releasing them or how to see this?
Does its only user created indicators or original NT7 indicators can do this too?
This post has been selected as an answer to the original posters question
Yes, I would expect to see that, and as it is a per-process limit it should be code inside NT or a user indicator code that is the cause.
For example creating custom pens or styles or other drawing objects in a custom Plot method but never calling 'Dispose' when they're done with. Unfortunately there is no way to tie back system pool GDI's to particular user process objects that I know of, on the other hand I am not an expert on this so there might be. This is my best guess as to where the problem is. Unless you're not using custom Plot methods in which case it isn't.
I doubt original NT indicators will do this. However, it would be worth eliminating indicators from your workspaces one or two at a time (or binary chop if you have lots) to see if you can pin down a specific culprit.
I would also think seriously about the number of bars involved in charts that you are using and whether a higher level timeframe would be more appropriate. Try simple things like just halving the number of days or bars loaded, or using minutes instead of ticks, or whatever. If you are using time-axis based drawing does it need to be so often, etc, etc.
If you remain convinced of a particular low level data requirement then you could always embed a re-use object scheme in any drawing (e.g. use something like (CurrentBar % 500) in place of CurrentBar in any unique ID drawing tags) where you really don't need to see ancient stuff but still want the latest stuff to be in high detail. We usually convince ourselves in OCD fashion that we have to have t all when in fact we rarely look at it usefully. That should only be neccessary where ancient values are still essential to some form of calculation but the visible results are not. I doubt this will be causing the issue in any case and is more just for performance.
There are many other aggregation schemes (e.g. lots of small rectangles into large ones) that could be employed to get around this, but first I would really want you to understand where it's coming from and if you really need that code or whether it can just be replaced by something better or bugfree. I have massively cut down chart load times by doing a lot of these sort of things (in fact startup times would be a good clue as to where to start looking, if a chart is slow to load it's probably a duffer.)
Again, most of the above are more for performace (cpu and memory) improvement and not resource allocation issues. It is possible to draw millions of things without hitting a GDI limit.
Last edited by ratfink; March 5th, 2016 at 02:45 AM.
The following 2 users say Thank You to ratfink for this post:
I didn't achieve to go past the 10000 GDI but you made me check even closer every properties and data loaded from my chart. I was thinking I had checked throughout all of my workspaces before, to eliminate the superfluous, but it seems I've missed 2 workspaces charts historic that I've cut by 6. It made the difference to make NT stable.
Thank you for your time.
The following user says Thank You to Baoumbox for this post: