AnsweredAssumed Answered

VRF - Segmentation error again.

Question asked by VRFuser on Nov 26, 1997
Stan:
Thanks for your email. It has helped me to solve the problem. It was not a dll problem as such but it turned out to be a situation where the .GID files  - I assume they are some type of ini type file - were not being correctly changed. If I delete these files after deciding to made a change to the I/O setup and then run ioconfig again it all seems to come right. The reason it worked a few weeks ago was that I decided to install everything into default directories rather than under Program Files. It turns out that I ended up with a new copy of the I/O files under C:SICL95intfcfg which meant new GID files.

Greg: Who do I tell about this, or can you pass this on to the appropriate people?


----------
From: Stan Bischof
To: craigs@trutest.co.nz
Cc: hpvxd_xc@hpislsup.lvld.hp.com
Subject: RE[2]: VRF - Segmentation error again.
Date: Thursday, 27 November 1997 03:10

Craig Smith <craigs@trutest.co.nz> wrote:
> VRF
>
> The problem as described below (a few weeks ago) went away after re-installing
> VEE but has reappeared since I have shifted my PC to another network segment.
> Is this a clue? I have tried to reinstall VEE 4 times but still get this
> error.
> I can use the HPIB interface with direct i/o or PnP drivers, but if I try to
> use the serial port it says "Serial Interface, at 9, is not configured for
> this system". Can anyone help me or tell me who to contact to get this problem
> resolved?
>

Very similar to something that I found and hacked around. As with your case
the I/O Config was failing at startup so I was unable to successfully
configure my cards. In my case the failure was nasty enough to lock up
my system.

Note that this is almost certainly not a _VEE_ issue per se, but rather
is coming from the I/O libraries (SICL/VISA). That's why reinstalling
VEE has no effect.

Looked like a classic unix-style I/O hang, and I approached it in that manner.

As it turns out the designers of the I/O product did a very nice thing:
they left each piece of the I/O in its own DLL. In this way it is
extensible and - in this case- debuggable by the end user.

Here's what worked for me and I expect may work for you.

Look in the <I/O library install directory>/intfcfg directory.

In there you will find a bunch of dll's, like cfg07432.dll, cfg23232.dll,
etc. Each of these pertain to one type of I/O (GPIO card, rs232, etc.).
When I/O config runs it exercises all the DLL's in this directory.
Try moving one of these aside (I would suggest renaming to .dll.original
or something like that ) at a time until you find the one that
is causing the problem. In your case since you are suspecting network
issues, I'd start with the LAN related dll's: cfgsvr32.dll, cfglan32.dll
and cfggln32.dll. Note that each has a "help" file describing what
it is used for.

This is an ugly hack but if you are lucky -as I was -you will find that
the offending dll is one that you don't need.

I _would_ suggest that if this works, you report back to the I/O
folks which dll was causing you trouble. Perhaps that will help them fix it.

good luck

Stan Bischof
stanb@sr.hp.com



Craig Smith
Research and Development Engineer
Tru-Test Ltd.
Ph    +64 9 2745799
Fax   +64 9 2746367
Email craigs@trutest.co.nz



Outcomes