›
Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

OI crashing

AusMarkBAusMarkB
in General
Looking for suggestions as to how to resolve a regular crashing issue. The application crashes randomly for different users. Worst case, it got to a point where one user was experiencing crashes every couple of minutes so obviously became unworkable.
There are many errors in the server application event log though not all crashes present an error. Sometimes the application just disappears with nothing to say for itself.

The issue has been in the hands of the clients IT company and they seem (or at least think they have) had success on a user by user basis by re-imaging the workstations. However we have about ten instances permanently running on the server and the crashes are becoming more persistent there.

Many/most of the errors in the event log reference ntdll.dll as the faulting module but the faulting application varies. Sometimes oinsight.exe, sometimes oengine.exe, sometimes srpcontrols.ocx.

Here's some info from the event log.

When I clicked on an srp tabcontrol



For this one, I simply minimised the application


report.txt attaches is a log file that occurred with the tabcontrol crash it case it helps anyone more than it does me.

Comments

  • KevinFournierKevinFournier
    edited December 2020
    For the Tab Control crash, you got Exception code: 0xc0000005, which is a bad pointer. That could be a bug, but it could be related to your second report. That one got Exception code: 0xc0000006, which is a network error.

    With these two bugs at work, I have to ask, are you registering all OCXs (both SRP's and Revelation's) on each local machine or on a centralized location on a network? If you are doing the latter, we strongly recommend the former.
  • AusMarkBAusMarkB
    The SRP controls are copied locally and registered as part of the user login script so it's definitely the former. For the Revelation one's I'm assuming you're referring to the clientsetup in which case it is run upon setting up a new PC though now that you mention it, I'm not sure whether that is pointed to a network or local drive. We don't do it ourselves in this case so I can ask the question of the IT company.
    I'm pretty sure, other than identifying where the OI application is, that they just accept the defaults so that should be local as well.
  • KevinFournierKevinFournier
    With our OCX being local, that at least eliminates one potential point of failure. Unfortunately, I'm not sure what else I can offer without specific steps to recreate the crash. The fact that it crashed by merely clicking on the tab control is concerning. It makes me worry that you have fundamental problems with the Win32 API emulation of your virtual machines.
  • AusMarkBAusMarkB
    Any suggestions on anything I can do to try and catch any exceptions without grinding 80 odd users to a halt?
  • KevinFournierKevinFournier
    Not in OI. There is no way to capture these exceptions and get useful information. All you get with OI are memory dumps, which don't tell us much. All we can really do is find out what users are doing when things crash.

    This is OI.

    This is the way.
  • AusMarkBAusMarkB
    Yeah, that's basically what I told the IT guys who were suggesting I take that approach but I was silently hoping I was just ignorant of the possibilities.

    As for what the users are doing, there's no real consistency.
    While working through it yesterday, it crashed on me three times in about ten-fifteen minutes.
    The first, I clicked on the title bar of a window to move it and the app just disappeared, no messages, no entries in the windows event viewer, nuffin. The second time was the error above where I clicked on the tab and the third was when I minimised the app to look at something else.
  • DonBakkeDonBakke
    Can you confirm that the OLE events are qualified to be asynchronous? I am not optimistic that this is relevant but it is best practice to do this unless your OLE event really needs to be synchronous.
  • KevinFournierKevinFournier
    One option that I have no experience with is enabling user-mode dumps. This is something Carl Pates suggested in the Revelation forums. He says, once you have those, you can use WinDbg or DebugDiag to analyze the dumps.

    I can't really say how useful the information will be, but it's something.
  • AusMarkBAusMarkB
    @DonBakke, yes asynchronous
    @KevinFournier, thanks I'll look into it.
  • joshjosh
    What OS is it? Also, you should try running Process Monitor. It can tell you something about what the app was doing just before the crash.

    https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
Sign In or Register to comment.