OpenInsight Crashes and SRPControls.ocx

Comments

• DonBakke

  July 2014

  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

  July 2014

  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

  July 2014

  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

  July 2014

  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

  July 2014

  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

  July 2014

  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

  January 2017

  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.