OI crashing

AusMarkB

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.

KevinFournier

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.

AusMarkB

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.

KevinFournier

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.

AusMarkB

Any suggestions on anything I can do to try and catch any exceptions without grinding 80 odd users to a halt?

KevinFournier

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.

AusMarkB

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.

DonBakke

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.

KevinFournier

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.

AusMarkB

@DonBakke, yes asynchronous
@KevinFournier, thanks I'll look into it.

josh

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