OpenInsight Crashes and SRPControls.ocx

Matt_Jones

I have recently upgraded a 54 user client to the latest version of our OI app, as well as upgrading them from OI 9.3 -> 9.4, and from individual SRP OLE Controls to the latest version single SRP OLE control, SRPControls.ocx.
The client is reporting a significant increase in incidence of OpenInsight crashing with the Windows message "OpenInsight has stopped working. A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available. Debug (button), Close Program (button)".

The client reports the problem is not reliably reproduceable, sometimes seems to happen when just moving the mouse, and sometimes occurs even when the user is not doing anything, ie not even moving the mouse or typing on the keyboard!

These “non-OI-debug” crashes my client is experiencing are raising Windows events and while there are some related to OENGINE.DLL and CFGMGR32.dll, at least half now appear to be related to SRPControls.ocx, and I am guessing this explains the “increase” in crashes the customer is reporting.

Here is an example of the Windows Event log entry information for SRPControls.ocx:

EVENT # 604497
EVENT LOG Application
EVENT TYPE Error
OPCODE Info
SOURCE Application Error
CATEGORY Application Crashing Events
EVENT ID 1000
DATE / TIME 27/06/2014 13:50:38
COMPUTERNAME TERMSERV1
MESSAGE Faulting application name: OINSIGHT.exe, version: 9.4.0.0, time stamp: 0x51ad1331
Faulting module name: SRPControls.ocx, version: 3.1.1.0, time stamp: 0x53603c38
Exception code: 0xc0000005
Fault offset: 0x003d7b73
Faulting process id: 0x69bc
Faulting application start time: 0x01cf918b22b872f7
Faulting application path: G:\Emril8\OINSIGHT.exe
Faulting module path: G:\Emril8\SRPControls.ocx
Report Id: f68aea4f-fdbe-11e3-a517-18a905485db8

These crashes occur on both terminal server client sessions and standard lan client sessions.
We use a number of SRP controls within SRPControls.ocx in our application, namely: Button, Picture, ReportTable, Splitter, StatusBar, Subclass, Tab and Tree.

I'm not looking for or expecting an immediate solution, although that would be great!
However, any assistance in how we can troubleshoot the issue to track even where it might be happening would be greatly appreciated.
Thanks.

DonBakke

Hi Matthew,

My apologies for the long wait before getting any response. Since you and I had already corresponded via email, I was allowing time for others to jump in. I thought it would be rude if I waited any longer.

I see that in your post you have already answered two of the questions I wrote back to you with: which controls are you using and does this occur on workstations connected to the LAN.

As I had noted before, we have seen crashes with the SRP controls in newer releases of OI (especially OI 9.4.0) ourselves. In fact, your issues look very similar to those that Ray Chan posted on the Revelation WORKS forum last April. In his case, however, he believes that the problem was due to the way he would have OLE button controls close forms. In earlier versions of OpenInsight it was a bit more tolerant with regard to using Send_Event to close a form although the best practice has always been to use Post_Event. I still think you might learn something from the different responses offered in that thread. Aaron Kaplan recommended you check TIMER events to see if they could be causing the spontaneous crashes when the system is idle.

In your case, the timing and cause of the crash almost seems random, as if environmentally related more than anything else. We would be a lot closer to a solution if we could isolate this to a specific control within the SRPControls.ocx itself. I have a theory (mostly based on intuition, not technical knowledge) that this is connected to the SRP Subclass control. So I want to come back to you with a couple of suggestions:

1. Is it possible for you to disable the code that makes use of the SRP Subclass control? I realize this might cripple some core functionality of your application, but I think it is worth a shot.
   
2. Is it possible for you to downgrade the SRPControls.ocx to an earlier version? This will really help us to figure out if there is something we may have introduced that is contributing to the problem.

Matt_Jones

Hi Don,

I looked through the thread you suggested, and subsequently removed the TIMER event, and changed the delay before indexing out to 30. I have been letting that play out and monitoring the crashes for a few days since. I don't have monitoring on individual user workstations, but on the terminal server the average crashes per day has gone from 6 in the week before changing the settings, to 5 in the week after changing the settings - not really a significant change.
I am hesitant to disable the SRP Subclass control - as you say, it may cripple core functionality.
I am happy to try downgrading the SRControls.ocx to the earlier version. This will be an easier sell for the users to test I think. If we need to subsequently disable the Subclass control, then so be it, but perhaps not yet.
Can you recommend the cleanest, robust method of downgrading the SRPControls.ocx to the earlier version please?
Thanks Don.

DonBakke

Hi Matthew,

Are you storing the SRPControls.ocx file in a central location (i.e., on the server) or on individual workstations? This only matters because a centrally stored file can remain locked until every user is logged off of the application properly. Beyond that, downgrading SRPControls.ocx is a simple process:

1. From a command prompt that is in the folder with SRPControls.ocx, unregister the control: RegSvr32.exe /u SRPControls.ocx
   
2. Rename the current SRPControls.ocx to something else (like SRPControls311.ocx).
   
3. If you have an older version of SRPControls.ocx then copy that into this folder.
   
4. Register the control: RegSvr32.exe SRPControls.ocx
   
   Technically, step #1 is optional. If downgrading your control doesn't work then I can send you a copy of our pre-release control. I am not optimistic that it will fix your issue (since we have not been targeting this to be fixed), but it is worth a try if nothing else.

Matt_Jones

Hi Don,

This customer upgrade was from the individual SRP OLE controls to the single SRPControls.ocx - they had not used a version of SRPControls.ocx prior to this.
I do store the ocx file on the server, in the oinsight.exe folder.
One of the problems I have with this is getting around to every workstation to unregister / register the component(s).
Could I just do this test on the terminal server?
That is, unregister SRPControls.ocx on the terminal server and then register the previously used individual ocx files, leaving all other workstations still using SRPControls.ocx??
That would mean all other workstations would continue as is, and I would be downgrading and testing only the terminal server, which is the only one I get good statistics from anyway.
Is that workable - to run the different versions that is?
Thanks Don.

Matt_Jones

Yes, I keep an archive copy of these things just in case!
I will give that a try, and I will let it run for a few days again and see what results we get.
I'll post again once I have some more data.
Thanks.

DonBakke

Hi Matthew,

That is a perfectly good way to test, and isolate, the SRP ActiveX controls. I take it, then, that you still have the individual controls that preceded SRPControls.ocx?

KDIV

I as well have noticed an unusually high number of 'OpenInsight has stopped working' crashes myself. I have not been able to isolate the components. I am using Win10 PRO and Win7 PRO, OI v9.4, UD v4.7.2 and SRP Utilities, v1.18, latest SRP Editor and SRP DatePicker, if on the network its Win2012 R2, otherwise local standalone workstation. I am not using what is described above, I could just be in the Forms Designer, making a lot of misc changes to the form (changing a control's size), then out of the blue I get the 'OpenInsight has stopped working', I have to close OI (although it crashes - still have to close), sometimes I have to reset entities via SYSPROG, sometimes a reboot. When I am in the Forms designer, I have the SRP Editor open (minimized), I will have the application manager open (minimized), I do not use SB's UI, I might have the table browser opened (minimized). I have learned, I do not need to be executing any of my code and this anomaly occurs. I have tried to catch a (snapshot) of what is occurring in memory using a memory manager - as I cannot say from any certainty where this is originating, but am finding it difficult, as I cannot deploy a form/module to production with this type of behavior occurring. Any suggestions or recommendations would be appreciated. Thank you.