[sims] Database errors and slow performance

[Tefters]

@minimoo - Many thanks for the updates/response.

 

I understand the handle processes on a basic scale and read an article last week when looking into this regarding general DB applications having and their front ends having these issues.

 

I won't pretend to fully understand your post as debugging applications is not my forte but it definitely pointed to a memory leak for a better term.

 

So the SIMS support team (2nd line), bless them, have advised me that it's a workstation ram issue which has never been a problem until September, surely 3.25gb ram (x86 image) is more than plenty for general sims admin work with the likes of Outlook, IE and Word open.

 

To appease the support team I have quickly whipped up an x64 image to push the ram on a users machine to the full 4gb and have a few 8gb sticks at the ready but considering I already have 1 ad hoc user that has an 8gb, i5 laptop who leaves sims open 24/7 and ends up getting booted out overnight with this system.handle error I'm not hopeful.

 

@PhilNeal & Minimoo - So are we in agreement that there is some sort of memory leak / handle issue within Sims at this current point in time or do I need to carry on looking into bolstering machines past 3.25gb.

[minimoo]

Personally, I find support team do a good job - I normally feel sorry for them when raising cases as I've normally found something obscure that tends to end up with them sitting in the middle.

 

In terms of "Windows Handle Win32Exception" specially - I'd wait and see what comes back - you can probably prove if i'm correct in this particular instance by opening task manager, showing the USER/GDI object columns, and clicking refresh on my messages until it gets to 10,000 and seeing if it crashes. At the same time, that's not to say this is the only place this occurs - I might leave my profiler running next week as I use sims, and compare some memory snapshots.

[matt40k]

In terms of dbs in general, 9gb is nothing. I still stand by my opinion of the homepage messaging was a stupid idea.

 

If your leaving workstations on 24/7 it'll have problems. Shut down SIMS when your going to leave it for over an hour, not only does it make technical sense, it makes security sense. You also have to remember that parts of sims are still "legacy" code and arent good restoring drop connections, parts of attendance and assessment are the ones that spring to mind. There is no logical reason to leave sims logged in on a workstation 24/7, i hate when folks go oh but it saves 6 secs in the morning. Dont waste support time trying to achieve something that it isnt designed to do and isnt a problem, there are far more important things that need fixing.

 

Changing the school dates? Thats a one time per year thing, that it involves writing at least 2x entries per pupil per day and if you've got lesson monitor, a lot more. Its gonna have a performance impact, its going to lock tables. Pretty sure it has a nice disclaimer too on the instructions. If your doing it more ad-hoc, then all i can think is the saying about poor planning.

@minimoo re dpa, yer... They are not the only supplier who is avoid the whole archiving and decommissioning. I suspect everyone is waiting for the first legal case

[Tefters]

My one off 24/7 sims user knows he will get crashes and performance issues when leaving the application open, he's just a really lazy sod when it comes to that sort of thing so I never really pay any attention to him unless he experiences issues which others report too.

 

As for DB size mine is 14gb and still growing but this is due to linked documents and having a ShareScan solution with SIMS plugin which can scan direct to linked documents for a paperless approach.

I do keep the DB as clean as possible running the maintenance patches every year, shrinking the log (even though I have it set to basic) and archiving attendance marks.

 

I've just been remoted into my office machine and the User GDI count does certainly increase every time you refresh the homepage, each refresh caused a 30 to 50 increase, I then left it 30 mins and it had increased by a further 200 on its own.

 

I will leave task manager running in the background on some users today and remote in to get figures throughout the day to see if what the increase is like.

 

As an extra thought, wouldn't the user have to be sitting on the homepage for this to really take affect or does the homepage widgets stay active behind the scenes?

The users that experience this issue (as not all do) spend a lot of time in students records as they are assistant head of years. They may spend a good amount of time on the homepage but I don't think they would personally.

 

EDIT - Scrap that last thought as just re-read your views on handles not being dropped in the first place rather than being active handles.

Edited November 16, 2015 by Tefters

[Steve21]

SIMS is a resource hog full stop . Whenever we've had slow issues they've always told me to run the indexing patches. Our database is getting on for 9GB.

Only solution we've really had is testing with SSDs improve things dramatically so generally it's down to workstation performance rather than Server.

 

Out of curiosity what is everyone's SIMS DB and Log size? Currently running 5GB~ on the DB but 40GB~ on logs, as an old company that was here before me never set it to truncate so it grew massive, changed it about here so it's not growing anymore, but didn't want to kick it and shrink in case it upset it, and the server will be replaced next year for updates anyway.

 

Steve

[ITGURU]

Out of curiosity what is everyone's SIMS DB and Log size? Currently running 5GB~ on the DB but 40GB~ on logs, as an old company that was here before me never set it to truncate so it grew massive, changed it about here so it's not growing anymore, but didn't want to kick it and shrink in case it upset it, and the server will be replaced next year for updates anyway.

 

Steve

 

DB size is 8.5GB , log file 700mb. Never have had a large log file as carry out full sql backups daily and whenever I've truncated the log file manually, it's never had any effect on the system.

[matt40k]

l having a ShareScan solution with SIMS plugin which can scan direct to linked documents for a paperless approach.

 

Doesnt that write to dms (ie the file system rather then as blobs in the database?) Students photos are blobs though. I remember when we looked at one large db (thats the mdf) we found the audit table was huge, it had entries from 2004 when someone changed there password!!

 

My main beef is that really, for even a 15gb you shouldnt need half the spec servers some folks have. I think really the issue is client size and if capita to a web based product or even split the client up - so you dont have a all singing all dancing client but say a teacher version and a office version, ideally you'd want a primary and a secondary version also. I still remember tracking down a problem at a primary school that was caused by some code that was done for the exams

 

Bah, good luck to all trying to resolve performance problems. Final tip, remember most of the business logic is client side, so its worth throwing 8gb at your desktops in the office

[Tefters]

@PhilNeal - What's your recommendation here Phil regarding the system.handle issue? Should I be going back to support and asking them to look up Minimoo's case reference and try to link the 2 issues along with referencing this thread or not?

[minimoo]

I *thought* they did a fair chunk of the logic in sql stored proc's.

 

In any case:

 

"I remember when we looked at one large db (thats the mdf) we found the audit table was huge, it had entries from 2004 when someone changed there password!!" -> I suspect sometimes it's things like that which help to slow some things down. The DB's completely split out, everything has a start/end timestamp etc - for whilst it should be indexed etc, everything is growing over time. I've seen a couple of times where things have got deadlocked waiting for each other (P.S. thought SQLSRV normally tried to avoid deadlocks)

 

And equally, regarding LDF log file sizes - pretty sure i've seen one of the patches that sets the sql recovery mode to basic to get rid of a large LDF (and doesn't set it back)

[jinnantonnixx]

And equally, regarding LDF log file sizes - pretty sure i've seen one of the patches that sets the sql recovery mode to basic to get rid of a large LDF (and doesn't set it back)

 

Oh, the (in)famous re-index patch. It switches your recovery to simple (trashing your log backups), shrinks the log file to 1 Meg (with the immediate result that the server throttles-back with lots of log growths (10% growth of nothing is still nothing) and finally gets to the business of re-indexing. A patch should perform one function, and one function only IMO - it certainly shouldn't wreck your backup routines.

 

Anyway, gripe over.

 

Good work @minimoo on debugging the client. I've always headed straight to the databases, but I've been digging into the clients today as I think we have a few problems too.

 

How did you go about discovering the memory leak in the SIMS client?

My normal WinDbg process is:

 

.loadby sos clr
sxe clr
g
!threads
!pe (at exception) or !clrstack -p

 

I tried looking for handle leaks using two snapshots but nothing seemed to be showing up.

!heap -s

 

I've got out-of-memory exceptions, but I ran out of time today. Maybe tomorrow will be more fruitful.

Edited November 16, 2015 by jinnantonnixx

[matt40k]

I *thought* they did a fair chunk of the logic in sql stored proc's.

 

Depends, logically you'd define your business logic in the most logical place - often this would be, for SIMS, in c# code - that way you can have proper unit tests. OK, there is a tsql unit test framework, but I don't believe this is as mature - I could be wrong, they could heavily use it. I suspect the place where the logic goes depends on the developer and if they are a C# developer or a SQL developer\DBA. Regardless, it does happen on the client and the server, so takeaway advise would be don't just assume you need a beast of server, you also need a beast of workstation.

 

Deadlocks happen, as I understand it, you generally lock the table when its a legacy bit of code or your doing a bulk insert\update\delete (for performance) and then the queue of other sql statement(s) happens which then times out. There is no real fix, hipsters will say NoSQL type dbs like mongodb is the answer, but then you'll get other types of problems

 

As for the setting the recovery model - this is generally frown upon in the SQL world. In corporate land, if your DBA setup your database in Full recovery model, if for a good reason, if your application then decides to abuse its powers and set the recovery model to simple your going to have your DBA looking for blood. Like @jinnantonnixx said it should have 1 job (that it does well) rather then trying to be overly helpful.

 

Ideally Capita should be factoring in time for developers to refactor code, this is where you rewrite code that is already "working" and improve it - so you shouldn't end up with load of Delphi code, some .net 1.0 code, it should all be on .net 4.5 or whatever. If you just look at the number of a individual command-line tools and the various options that they have you'll find loads of inconstancies - archive attendance marks, b2b, command report tool. I know B2B is getting updated, but that's because they're selling LAs (or sold in some cases) the new LA ONE v4 which has a new version of B2B - but the point is, you shouldn't have to create a business case for continuous improvement, especially when you're already on the regular billing model (vs buying a version then rebuying the new version). A lot of stuff like you said could go into SOLUS3, like scheduled reports, maintenance task like reindex jobs, archive attendance marks, health checks (last backup, ldf size...) - you could even build in something for the third parties so you have a single place to manage all those pesky third party apps that KO your system

[minimoo]

@jinnantonnixx - thanks - need to see if i'm right. I'm was planning to leave redgate's stuff running whilst using sims for a day and see what else showed up

 

I think initially i used:

 

!gchandles

!DumpHeap -stat

 

and then did a run of:

 

.foreach (location {!DumpHeap -type System.Windows.Forms.NativeMethods+WndProc -short} ) {!gcroot -all ${location} }

 

to try and see if i could identify what

 

Having said the above, and to be perfectly honest - when i posted on forum in here, I downloaded a 14 day trial of redgate's dotnet memory profiler and shoved it in a vm, did a before/after snapshot, and let it compare. That took about 15 minutes of time, and seemed to identify exactly what was going on. [My original windbg attempt, whilst showing what object, took slightly longer, and didn't get me as far as identifying the cause]

 

I wrote a reverse proxy in dotnet a couple of years back, which was a good exercise at the time in diagnosing issues in long running apps, and exhausting resources (e.g. network sockets)

[Tefters]

So i've updated my SIMS call ref 1510-3399534 and basically pointed 2nd line to this forum thread along with minimoo's SIMS incident number.

 

As PhilNeal has not come back with any advisories as of yet on this I'm guessing we are playing the waiting game and just advising our users to carry on as is and just deal with the errors by ignoring them and re-opening SIMS?

I'm going to try and have 1 or 2 users kill off the Messaging widget on the home screen in the meantime as this appears to be the main culprit.

[PhilNeal]

@minimoo your case is being reopened.

[jinnantonnixx]

@minimoo - I think you're on to something.

 

Long post coming up but I think I've spotted where SIMS is leaking.

 

We suspect that SIMS has a memory leak. One of our busy users suffers from regular crashes. I asked the school tech to send me the process dump files so I could take a look.

Running the DMP files through DebugDiag shows that, in every case, the exception thrown is ‘System.OutOfMemoryException’ and the GC Heap usage was between 1.0GB and 1.5GB.

 

This is suggesting a memory leak, so let’s try and sniff it out.

To check, we run SIMS and attach Process Explorer to the Pulsar process. Try this for yourself to see if I’m correct.

Keep an eye on the #GC Handles count (in the .NET Performance tab) and the Private Bytes (in the Performance Graph tab).

Leave the dust settle and establish a baseline.

Now just open and close the Student Details window repeatedly. Don't browse any students, just open and close the Student Details window. See what happens. The Private Bytes memory increases. As does the count of GC Handles.

 

If you do this enough, SIMS will crash.

 

Before it does, you can attach WinDbg debugger to the Pulsar process to check a few things.

Look at the finaliser queue object list:

!FinalizeQueue

...

67defec0 36717 440604 System.WeakReference

0d0ab68c 3931 455996 SIMS.UserInterfaces.UIMenuItem

1910f8a0 1490 464880 SIMS.UserInterfaces.MaintainedListView

653435c0 4053 470148 System.Windows.Forms.ToolTip

0cbc2ed8 2139 581808 SIMS.UserInterfaces.ComboBox

0d0ac924 6403 614688 NETXP.Controls.Bars.CommandBarButtonItem

0d9096ec 1888 641920 NETXP.Controls.Bars.FloatingForm

1c220bfc 1623 701136 SIMS.UserInterfaces.ListView

0d9020a4 1888 717440 NETXP.Controls.Bars.CommandBar

0d90003c 6425 873800 SIMS.UserInterfaces.Label

65354f40 28309 1585304 System.Windows.Forms.Control+ControlNativeWindow

Total 177295 objects

Even after a short period of opening and closing the pupil browse window, we see huge numbers of Windows form controls. This seems very odd - could be a garbage collection problem???

 

Let’s look at the method table (MT) for these form controls:

!dumpheap -mt 65354f40

...

4d8e6294 65354f40 56

4d8e63c4 65354f40 56

4d8e7568 65354f40 56

4d8e79ac 65354f40 56

4d8e8cb8 65354f40 56

4d8e8ef0 65354f40 56

4d8e91b0 65354f40 56

4d8e93d4 65354f40 56

...

 

There are thousands of objects matching this method table, but we’ll just consider one at random.

 

We can identify what’s keeping this object alive by checking its roots:

0:014> !gcroot 4d8e7568

Thread fb0:

*** WARNING: Unable to verify checksum for C:\Windows\assembly\NativeImages_v4.0.30319_32\System.Windows.Forms\b51470d7e909c4fab01a25fd1e1c42dc\System.Windows.Forms.ni.dll

0014f05c 6531fe48 System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)

ebp+50: 0014f088

-> 05836f54 System.Windows.Forms.Application+ComponentManager

-> 05836f98 System.Collections.Hashtable

-> 05836fcc System.Collections.Hashtable+bucket[]

-> 05836f88 System.Windows.Forms.Application+ComponentManager+ComponentHashtableEntry

-> 04f82900 System.Windows.Forms.Application+ThreadContext

-> 05083f14 System.Windows.Forms.ApplicationContext

-> 05077078 SIMS.UserInterfaces.MainContainer

-> 05078638 System.ComponentModel.EventHandlerList

-> 057b9698 System.ComponentModel.EventHandlerList+ListEntry

-> 05084cd8 System.ComponentModel.EventHandlerList+ListEntry

-> 05084b4c System.ComponentModel.EventHandlerList+ListEntry

-> 05083f48 System.ComponentModel.EventHandlerList+ListEntry

-> 6faeb490 System.EventHandler

-> 6faeb380 System.Object[]

-> 4d901624 System.EventHandler

-> 4d89899c System.Windows.Forms.ToolTip

-> 4d898a10 System.Collections.Hashtable

-> 4d8f0b20 System.Collections.Hashtable+bucket[]

-> 4d895f0c SIMS.UserInterfaces.TextBox

-> 4d896070 System.ComponentModel.EventHandlerList

-> 4d9210dc System.ComponentModel.EventHandlerList+ListEntry

-> 4d9180e8 System.ComponentModel.EventHandlerList+ListEntry

-> 4d9180b4 System.ComponentModel.EventHandlerList+ListEntry

-> 4d918080 System.ComponentModel.EventHandlerList+ListEntry

-> 4d918060 System.EventHandler

-> 4d8752c0 SIMS.UserInterfaces.EditStudent

-> 4d878570 SIMS.UserInterfaces.LinkBar

-> 4d90abe4 SIMS.UserInterfaces.LinkBarLinkLabels

-> 4d90e984 System.Collections.Hashtable+bucket[]

-> 4d90e934 SIMS.UserInterfaces.LinkBarLinkLabel

-> 4d8e7440 SIMS.UserInterfaces.DynamicAttributeGroupBox

-> 4d8e7568 System.Windows.Forms.Control+ControlNativeWindow

 

Found 1 unique roots (run '!GCRoot -all' to see all roots).

 

We can see that this object is a group box, created by the EditStudent routine in SIMS.

 

OK, let’s pick another object at random of the same MT.

!gcroot 4e38aaac

Thread fb0:

0014f05c 6531fe48 System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)

ebp+50: 0014f088

-> 05836f54 System.Windows.Forms.Application+ComponentManager

-> 05836f98 System.Collections.Hashtable

-> 05836fcc System.Collections.Hashtable+bucket[]

-> 05836f88 System.Windows.Forms.Application+ComponentManager+ComponentHashtableEntry

-> 04f82900 System.Windows.Forms.Application+ThreadContext

-> 05083f14 System.Windows.Forms.ApplicationContext

-> 05077078 SIMS.UserInterfaces.MainContainer

-> 05078638 System.ComponentModel.EventHandlerList

-> 057b9698 System.ComponentModel.EventHandlerList+ListEntry

-> 05084cd8 System.ComponentModel.EventHandlerList+ListEntry

-> 05084b4c System.ComponentModel.EventHandlerList+ListEntry

-> 05083f48 System.ComponentModel.EventHandlerList+ListEntry

-> 6fcf393c System.EventHandler

-> 6fcf372c System.Object[]

-> 4e3da748 System.EventHandler

-> 4e36a3c8 System.Windows.Forms.ToolTip

-> 4e36a43c System.Collections.Hashtable

-> 4e3c5460 System.Collections.Hashtable+bucket[]

-> 4e367aac SIMS.UserInterfaces.Button

-> 4e367ccc System.ComponentModel.EventHandlerList

-> 4e401cbc System.ComponentModel.EventHandlerList+ListEntry

-> 4e3f8d10 System.ComponentModel.EventHandlerList+ListEntry

-> 4e3f8cdc System.ComponentModel.EventHandlerList+ListEntry

-> 4e3f8ca8 System.ComponentModel.EventHandlerList+ListEntry

-> 4e3c53e4 System.ComponentModel.EventHandlerList+ListEntry

-> 4e3c53b0 System.ComponentModel.EventHandlerList+ListEntry

-> 4e36d064 System.ComponentModel.EventHandlerList+ListEntry

-> 4e36d044 System.EventHandler

-> 4e3570b0 SIMS.UserInterfaces.AdditionalDetailsControl

-> 4e357374 System.ComponentModel.EventHandlerList

-> 4e40122c System.ComponentModel.EventHandlerList+ListEntry

-> 4e3f6ca8 System.ComponentModel.EventHandlerList+ListEntry

-> 4e3f6c74 System.ComponentModel.EventHandlerList+ListEntry

-> 4e3f6c40 System.ComponentModel.EventHandlerList+ListEntry

-> 4e3f6c20 System.EventHandler

-> 4e347064 SIMS.UserInterfaces.EditStudent

-> 4e3ef3b4 SIMS.UserInterfaces.UserInterfaceManager

-> 4e3ef3cc SIMS.UserInterfaces.ISIMSControls

-> 4e3f011c System.Object[]

-> 4e380fcc SIMS.UserInterfaces.MaintainedListView

-> 4e3e1cac SIMS.UserInterfaces.MaintainedListViewDisplayItemDelegate

-> 4e37fbd4 SIMS.UserInterfaces.MedicalDetailsControl

-> 4e38a944 SIMS.UserInterfaces.DocumentListControl

-> 4e38aaac System.Windows.Forms.Control+ControlNativeWindow

 

Found 1 unique roots (run '!GCRoot -all' to see all roots).

 

Simailarly, this is another Windows control (a document list control) created by SIMS.

 

But are these objects going to be released? Just to be sure, we go back to debugger and run SIMS for a while, just opening and closing the pupil browse window. After a while, we break into SIMS with the debugger, and check if these two objects are still here - yes they are, so they haven’t been collected by the DotNet garbage collector.

 

What do we actually know? We can be sure that SIMS is not releasing memory when the Student Details window is closed. We lose about 10MB of memory every time this happens. The memory used by the form objects is not being released. We can also see the inexorable rise in the handle count.

 

For our busy users, we see that their machines crash. From analysing process dump files, we can see that the machines have run out of memory. There are no substantial contiguous segments of free memory left - a classic case of memory fragmentation. Normally this is resolved by the Finalizer (sic) thread. This runs in response to a garbage collection (GC) event.

 

If you leave the machine untouched for hours, the GC doesn't run. The memory is never released. It's possible that the Dispose method is not freeing up all the objects created for the form. But as there are a humongous number of objects waiting to be finalised, it could be that the Finalizer thread is not being called.

Edited December 23, 2015 by jinnantonnixx

[minimoo]

@jinnantonnixx - OK - that looks like a different issue to 1508-3368857 [which was my intouch/messages on homepage slow leak over time issue]. Can you ensure you log this one with capita and preferably post case number here. Given your description - I know sims crashes out on our admissions lady and causes her grief in June each year, but i've never bothered to diagnose long enough to log a decent report. I'll then test on Monday 4th January (or in the first week), and log a case with sims if I can reproduce the same issue. This would make our admissions lady happy if we could get it fixed, and allow capita to confirm whether the issue affects more than one customer.

 

@Tefters, @jinnantonnixx: In terms of the initial case we raised in this thread, I've so far had the following updates from capita since mid-november:

 

14/11 - with escalation team, and work being undertaken to resolve

18/11 - with escalation team, and work being undertaken to resolve

23/11 - with escalation team, and work being undertaken to resolve

26/11 - with escalation team, and work being undertaken to resolve

1/12 - with escalation team, and work being undertaken to resolve

4/12 - with Escalation Team and is currently Pending Development.

9/12 - with escalation team, and work being undertaken to resolve

14/12 - with escalation team, and work being undertaken to resolve

17/12 - with escalation team, and work being undertaken to resolve

 

Not sure if the change on 4th December is that something was done, or my normal support guy was off for the day and it was picked up by someone else

@PhilNeal: Sims is obviously a bug and complex application - memory leaks are going to happen - I'm not sure if you've ever been a programmer, but it's quite easy to miss free()-ing something. Are jinnantonnixx/myself helping with sending these to the support desk - or have we kicked off an internal discussion/plan to add more memory leak detection into the testing/build processes, so reporting issues at this stage would be more of a hindrance?

[PhilNeal]

@minimoo I've asked our developers for an update as I alerted them to this thread a while ago. Thanks for reporting issues! Many years ago I did programme - at one point SIMS was all my own work. Sadly I don't code any more!!

[teresawill]

I have same trouble now and thanks to all the points people shared. It really helps a lot.

[PhilNeal]

Here's the update:

• PRB11652\1508-3368857: Messaging widget causing crash due to Out of Handles error after several hours. The intension is to include the fix in the spring release.
  
• Crash due Out of Memory error, pointing to a potential memory leak in the Student Details screen. We've asked the developers to check this out.
  

Thanks

Phil

[minimoo]

We like Phil

[SimonCygnetIT]

@PhilNeal There is also this call running 1511-3423846 - PRB12112. This is about a memory leak surrounding staff records and personnel. No updates at the moment except that it is with the Escalation team.

[Tefters]

@minimoo @PhilNeal - Many thanks for the updates, since pointing my support ticket to this thread way back at the start of this discussion I have been receiving the same weekly "This is awaiting development" issues so nice to see this is going somewhere!

 

Luckily in the meantime simply telling people to remove the messaging widget is the answer and since then SIMS has been happily running with no issues.

[minimoo]

Just had this one when going through student applicants and adding lots of photos. Once supportnet comes back (as it's currently down for me ;/) I will log a case so it can get triaged with the others. I suspect given there's already a case on the "student details", that this might be a variant of that but with the applicants screen instead.

@jinnantonnixx can you see if your case on student details was collapsing to same fault code ?

 

1075-9663-0700

1158

-2147467259

Error creating window handle.

at System.Windows.Forms.NativeWindow.CreateHandle(CreateParams cp)

at System.Windows.Forms.Control.CreateHandle()

at System.Windows.Forms.Control.get_Handle()

at System.Windows.Forms.Control.CreateGraphicsInternal()

at System.Windows.Forms.Control.CreateGraphics()

at NETXP.Controls.Bars.CommandBar.GetSize()

at NETXP.Controls.Bars.CommandBar.UpdateSize()

at NETXP.Controls.Bars.CommandBar.margins_Changed(Object sender, EventArgs e)

at NETXP.Controls.Bars.Margins.set_Bottom(Int32 value)

at SIMS.UserInterfaces.ToolBar.InitializeComponent()

at SIMS.UserInterfaces.ToolBar..ctor()

at SIMS.UserInterfaces.MainException.InitializeComponent()

at SIMS.UserInterfaces.MainException..ctor(Exception exception)

at SIMS.UserInterfaces.DefaultEntryPoint.catchAll(Object sender, ThreadExceptionEventArgs e)

at System.Windows.Forms.Application.ThreadContext.OnThreadException(Exception t)

at System.Windows.Forms.Control.WndProcException(Exception e)

at System.Windows.Forms.Control.ControlNativeWindow.OnThreadException(Exception e)

at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)

at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)

at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)

at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)

at System.Windows.Forms.Application.Run(Form mainForm)

at SIMS.UserInterfaces.DefaultEntryPoint.Main(String[] commandLineArguments)

System.Windows.Forms

-2147467259

[jinnantonnixx]

@minimoo

No, it's not the same fault.

 

However, it might be a different symptom of the same problem - failure to allocate handle due to too many handles being in play, rather than failure to allocate free memory from the heap. Both of these might have their roots in the same underlying cause - failure to release resources (Windows form elements, amongst others).

 

 

I've submitted a fault report concerning the memory leak, by the way.

Edited February 1, 2016 by jinnantonnixx

[minimoo]

I had to email my one in, as supportnet was down, have been given case ref: 1602-3448930