OpenInsight Crashing and Not Responding Issues.


We have recently received a number of support requests from clients reporting that OpenInsight has stopped responding or OpenInsight has stopped working and crashed.  This is sometimes the message that OpenInsight has stopped working because it is addressing illegal memory, or that OpenInsight has stopped responding and you can opt to close it, ask Windows to correct it or carry on waiting for a close.  On further questioning, we sometimes find that there is an associated FS1030 or and FS231 error message.

In 99% of cases, the issue is the result of something environmental or that the UD has been incorrectly installed or some has changed something on the network, such as replacing the server and not reinstalling the UD correctly.

If you should be faced with an issue such as those above, we recommend that you thoroughly check the Universal Driver installation and even uninstall and reinstall the Universal Driver, whilst ‘closely’ following the installation manual.  We also suggest that you check for DEP running on the system because this also causes issues on older OpenInsight based systems.

However, below are a few specific things to consider:

  • FS1030 – This is usually a result of the SYSTEM USER either not being configured correctly with full permissions during the installation, or someone has decided to delete the user.  The latter is common where a server administrator (or outside IT contractor) is running a user audit and removing old users.  They don’t recognise the SYSTEM user or don’t understand the significance and simply delete it as no longer needed, or reset the SYSTEM user with restricted permissions.

 

  • FS231 – This error message is often attributable to an issue within the REVPARAM file, or where the REVPARAM file has been deleted or created with an extension, such as .txt.  One of the most common configuration issues is the SERVERNAME= parameter in the REVPARAM file not matching the name in the registry that was input during the installation wizard.  Sometimes, if you try to run the UD Manager that will fail with an FS231 error message, this is often a result of the servername being incorrect in the UD Manager’s REVPARAM file.

 

  • FS1019 – New server and workstation deployments often contain default firewall rules that block OpenInsight from communicating with the Linear Hash service on the server.  When this occurs a FS1019 or similar message will appear during OpenInsight start-up.  Revelation have published a white paper (knowledgebase article) on this issue and an accompanying Port Checker.  Both are available on request or from http://www.revelation.com/o4wtrs/KB_Articles/KB0269.htm.

 

  • OpenInsight Is Not Responding – This message often shows in the top of the OpenInsight window or in a message.  Three options are offered and one is to allow the program to run until completed. OpenInsight is actually working but the Operating System, often Windows 7 or later, thinks that it has stopped responding because OpenInsight is busy and not ‘currently’ communicating with the Operating System for a time.  Often waiting for the OpenInsight process to complete will result in the message closing itself (or going away) and everything returns to normal.  Some likely causes could be a resize or creation of a large file or a large indexing run. If this becomes an issue for users, it is often necessary to identify which process is taking the time and then to add some code to let the Operating System know that OpenInsight is working.

 

  • OpenInsight has stopped working and Will Close – This is a more serious issue because the operating system will forcibly close down OpenInsight.  We have recently experienced that running OpenInsight with a profile log eradicates this issue and that OpenInsight again crashes when the log is removed.  This has been an issue invoked by the driver in NETDRV being incorrect.  One recent installation of the Universal Driver 4.7.2 was being run with the UD 4.6 driver set in OpenInsight.  This was because the 4.7.2 driver was not amongst the options in NETDRV.  We completed the Universal Driver installation correctly by running the UD Client Install and the system immediately began to run correctly.  If you experience ‘any’ OpenInsight crashing or not responding messages, we would advise that the client driver is checked and make sure that the UD and the client are running as a pair – i.e. 4.7.2 server and 4.7.2 client.

Sprezzatura have a useful blog article which discusses the OpenInsight Not Responding issue in much more detail.  Click Here for the SENL article.

Of course, if none of the above help to eradicate your networking or OpenInsight crashing issue, please contact your local Revelation support person and they will be happy to investigate the issue further.

Finally, if you are running an older version of the Universal Driver, please consider an upgrade to version 4.7.2 which has some important enhancements, including a memory leak fix.  The upgrade from 4.0 is free and your local Revelation representative will be happy to process the supply of the upgrade for you.

Advertisements

Application ‘Not Responding’ on Windows 7


Since moving to Windows 7 ultimate I have had occasional instances where some of my applications get flagged up as “Not Responding”.  I have also been asked about this several times over the last few weeks and a formal support request this morning prompted a discussion internally.  As a reminder to myself and for future reference, I thought that I’d write this blog posting.

If the offending application then tries running a long process (one that will run for more than 5 seconds, I believe), Windows 7 gets excited and reports the application as ‘not responding’.  This notification is normally through a discreet note at the top of the window and sometimes a more noticeable message asking whether to close the application or wait.

Fortunately, my OpenInsight 9.2.1 runs very quickly on my Windows 7 laptop and I don’t run into the issue too much.  However, if you (or your clients) are seeing this with your OpenInsight applications please keep the following in mind:

  1. The issue appears to be down to a process that is running (looping) for more than 5 seconds and Microsoft picks this up and flags it as a possible ‘non responding’ program and informs the user accordingly.  Despite the warnings, the process continues and the application usually gets flagged as responding again once the process has finished.  However, if you get the message popup on your screen and you click cancel, Windows 7 will try to terminate the application and this ‘could’ cause data loss or other nastiness.
  2. To manage your user’s expectations, simply make sure they are aware of this Windows 7 behavior and advise them to leave the application to run for a short while.
  3. Make sure that you are using one of the later versions of OpenInsight and the latest Universal Driver.  If configured correctly, this should ensure that your OpenInsight application is running as optimally as possible.  If in doubt, give me a call and book a health check wit hone of the developers.
  4. Most importantly, make sure that you code to address this Windows feature.  In OpenInsight, this can be as simple and easy as using a YIELD( ) within your programs that are likely to take any length of time (more than a few seconds).

Yield ( ) checks for pending events in the Windows event queue and executes them.  It then returns control as soon as the event queue is empty.  All pending events will be executed, including OpenInsight and Windows events.  It is therefore good practice to handle process dependent conditions (such as a CLOSE event0 after a Yield( ) call.

Example syntax for Yield ( ) is:

done = FALSE$
 Loop
 ReadNext ID Else done = TRUE$
 Until done
 * Allow for an event, such as CLICK
 Yield()
 * Process ID record
 Repeat

Legacy Applications
It is usually best to address this issue within your OpenInsight application and thereby maintain control.  However, for legacy systems there is another (which I would consider a last resort) option which makes use of Microsoft’s Application Compatibility Toolkit.  You can get further details about that by clicking here.

Why’s my oinsight.ini file not working????


We recently had a support enquiry because the OInsight.ini file (located under C:\Windows) was not being picked up and the developer was therefore unable to change the Application Manager buttons to display the System Editor ++, rather than the old System Editor.

I’d always understood that the OInsight.ini file that OpenInsight used for these settings and others, was the one in the Windows directory. However, from Windows Vista and Windows 7, things are no longer that simple.

As Carl enlightened me, Vista and Windows 7 implement something called virtual file redirection, which means that the ini file the OpenInsight uses is not the one in C:\Windows – when it asks for the file Windows goes and gets it from the Virtual Store instead. It is Microsoft’s way of trying to stop people using ini files – they don’t like you using the registry these days either!!

Anyway, the *real* ini file that Windows gives to OpenInsight is stored in your user settings folder something like:

C:\Users\[UserName]\AppData\Local\VirtualStore\Windows\oinsight.ini

If you change that ini file, then everything should be fine and OpenInsight will display the right buttons and your other preferences/settings.

For the more technical and those who want to understand all of this in more detail, the following link will be useful:

http://windowsteamblog.com/windows/b/developers/archive/2009/08/04/user-account-control-data-redirection.aspx

Configuring OpenInsight 9.x for 64 bit Machines


In order to run OpenInsight version 9.x on 64-bit versions of Windows, some additional configuration of the default OpenInsight needs to be addressed.  These changes should be made only following a successful installation of OpenInsight.  The guidelines assume that you have a fresh installation of 64-bit Windows (not one of the Home editions) and also a fresh installation of OpenInsight version 9.0 or later. Depending on your chosen User Account Control settings in Windows, these may not all apply to you.

  • 32-Bit Java Runtime
    O4W and CTO both require a Java run time to run.  For compatibility reasons, you should download and install the latest 32-bit which is available from JRE (Java Runtime Environment).
  • Alternative Registry Location
    As well as the operating system’s usual 64-bit registry entries, 64-bit Windows also maintains a separate list of 32-bit registry keys for the purposes of maintaining compatibility with 32-bit applications.  As far as OpenInsight is concerned, these 32-bit registry settings are maintained under the ‘HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\RevSoft’ registry branch and all registry changes for OpenInsight should be completed under this branch.The registry settings for SYSPROG are:
      [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\RevSoft\OECGI2]
    “UserName”=”SYSPROG”
    “UserPassword”=”SYSPROG”
    “ApplicationName”=”SYSPROG”
    “ServerURL”=”localhost”
    “ServerPort”=”8088”
    “ProcedureName”=”RUN_OECGI_REQUEST”
    “EngineName”=””


    The registry is not an area that should be played with lightly and for this reason Revelation have created an updated registry file to assist in the configuration of OECGI2.  The file can be downloaded from the main Revelation web site at http://www.revelation.com/knowledge.nsf/07dbcbabb6b3e379852566f50064cf25/88e6dbc0988dec9385257566007831c5/$FILE/oecgi2%20vista64.reg. This file should be used in place of the OECGI2.reg that ships with OpenInsight 9.0.

Please also be sure to review and follow the OpenInsight 9.0 Workstation Installation Notes that now apply to the installation of OpenInsight on all versions of Windows.

>RCL4.DLL


>

I am still running into developers reporting issues with OpenInsight being left running in the task manager when OpenInsight is closed. This is mostly on Vista machines, but I thought it worthwhile to include another posting here dedicated to this issue. It will not be any surprise to you that this results in some undesirable behaviour. Revelation therefore jumped on this issue very quickly and the latest RCL4.dll file resolves that issue.