RSRC_NFOUND error with multiple processes

[Evan Van DYke]

I'm working on programming a system in which we have a background process(that runs at system startup as a user that is a member of the Administrators group) that handles various tasks as well as a set of DLLs that can be called by user-level processes. However, when said background process is running, no user-level process can get handles to instruments. The calls to the driver init functions return 0x9fff0011(VI_ERROR_RSRC_NFOUND). If I run the same program as the Administrator user, the code works perfectly. It is, obviously, a permissions problem or some other exclusion inside the MeasurementStudio/VISA/Instrument driver DLLs. Since MAX is unable to access the VXI subsystem as a normal user when the background process is
running, I am assuming that it is a MS/VISA problem.

More specificially, MAX says that it is unable to access the NiViPxiK and niVVGLk DLL/Services.

We are creating executables with MSVC, using the latest version of Measurement Studio on MS Windows 2000 boxes.

Any help would be appreicated.

[jws]

Hello Evan,

Can you give a little more detail about exactly what hardware the background process is accessing? I presume that MAX works fine, under any circumstances, when this background process is not running?

Regards,
Jesse

[Evan Van DYke]

Sure. I've been playing with it some more since the post, and I'm afraid that it's looking like it may be an internal driver issue.

At the moment, all the background task is doing is calling a viOpenDefaultRM, running through the list of station instruments to do some viGetAttribute calls on them, and then closing the instruments and the RM. We'll also be having it perform instrument resets and the like. nothing terribly onerous or complex.

Since this post, I've found that while I thought the problem was just with the VXI instruments, it is actually effecting our GPIB instruments as well... they just don't get a big yellow icon in MAX. When the background process has opened the instruments and closed them again, an attempt to get a handle to
them(by calling their respective VXI-PNP driver init functions) as another user(unless said user is Administrator) returns a 0xbfff0011 if it is a VXI instrument and a 0xbfff003e if it is a GPIB instrument. Since the code works fine when the background process is closed, or if both processes are acting as the same user, it really looks like a shared-resource permission problem to me.

Do you happen to know if the VISA/VXI/GPIB drivers make any calls to CreateMutex/CreateSemaphore/CreateEvent/etc.? We had to make sure that all of our calls to these functions specified a security descriptor with a NULL DACL(which is global access), instead of the NULL(Default)Security Descriptor(access to current user or administrator). I have made sure that the user-level account has full access to the National Instruments registry keys, and the directories on disk that store some config files, so it isn't any of those simple problems. Am I missing something?

[Evan Van DYke]

Hrrm, just noticed that before these calls, the call to viOpenDefaultRM is returning 0x3fff0077(Configuration not loaded). The errors in the open calls might be a result of this... could the permission problem be in here? (the config.m?? file is globally-readable)

[Evan Van DYke]

Mr. Curtis,
My reply to your direct E-mail is getting bounced back by the server, so I thought that I'd paste it here while IT at NI looks at the bounceback issue.

> Our version of NI_PAL is: 1.5.6f0
>
> other versions are:
> NI-VISA: 2.6.1
> NI-VXI: 3.2
> NI-488.2: 1.70 (We know that 2.0 is out, but havn't upgraded yet).
>

I can not get the utility, as our corporate mail system blocks out executables. Could you zip it and send it to me that way?

many thanks.

--Evan

[Joji]

Evan, I emailed you a linkg to a newer version of NI-PAL.

If anyone else has this problem please contact National Instruments Technical Support.