Error -50103 and Windows 7 64 bit

[dc128]

I am attempting to switch a system running on Windows XP to a Windows 64 bit computer.

I am using DAQmx 9.8, MAX 5.5, cDAQ 9178 with 9215 modules through USB, Dell Optiplex 7010 64 bit, Windows 7 SP1.

I've run into an issue where the resources for a global channel are not released after using them.

This occurs in two different .NET programs and also in MAX.

The first time you begin to read the data (in the programs) or run the channel (in MAX), it will display data as normal.  However, after stopping the read (in the program) or stopping the channel and exiting MAX (in MAX), and then starting to read or run again, the programs or MAX will either a) lock or b) display error -50103.

Cycling power to the cDAQ will reset it and you can see the behavior described above again.

I've worked my way through the knowledge base eliminating potential causes to no avail.

For example, here are a set of specific circumstances that lead up to appearance of the issue.

1.  The computer is shut down/powered down.

2.  The cDAQ chassis is powered down.

3.  The computer is booted up.

4.  The cDAQ chassis is powered up.

5.  MAX is opened and a global virtual channel is selected and run.  It displays readings properly.

6.  The channel is stopped and MAX is closed.

7.  MAX is reopened and the same channel is selected and run.

8.  Either an error -50103 appears or the "stop" button flashes, changes to "abort", and becomes non-functional.  No readings are displayed.

Neither of the .NET programs have executed at this point.  This computer is a clean image so there should be no program able to access the resource other than MAX and the two .NET programs.

Has anyone else encountered this issue?

Thanks for any insight you can give me.

[Catherine-B]

Hi dc128,

Were your .NET programs running without issue on your Windows XP computer? What happens when you run those same programs on the Windows 7 computer?

You said you have worked your way through a KnowledgeBase article and eliminated possible causes. Is this the article you were looking at?

http://digital.ni.com/public.nsf/allkb/485201B647950BF886257537006CEB89?OpenDocument

What steps have you tried/causes have you eliminated?

Best Regards,

[dc128]

Thanks for your response. Here is the additional information you requested.

The programs have worked for years on computers running Windows XP. The programs will either 1) deadlock or 2) catch an exception that displays an error -50103 message on these Windows 7 computers.

Also, I've noticed that the phenomenon occurs in MAX, immediately after start up, without any execution of the .NET programs.

Case 1: Running a DAQmx application after a Traditional DAQ application without first resetting the Traditional DAQ driver.

No traditional DAQ software is installed on this computer. No Traditional DAQ channels have been created. The applications are entirely DAQmx and only DAQmx global virtual channels are defined.

Case 2: Continuously starting and clearing a DAQmx task (in a loop) for an extended period of time.

I have recreated the failure simply by 1) running the channel in MAX, 2) stopping it, 3) exiting MAX, 4) reopening MAX, and 5) running the channel again. The .NET programs will not execute without being manually started, and just before running the channel in MAX the computer and power to the DAQ chassis were shut down in order to reset them.

Case 3: Generating a finite pulse train and another counter task on the same device in LabVIEW with NI-DAQmx.

This case does not apply to software and channels on this computer.

Case 4: Using multiple DAQ Assistant Express VIs to access channels on the same data acquisition board.

The programs do not make use of LabView and no LabView software other than whatever is packaged in the DAQmx runtime is installed on this computer.

Case 5: Using multiple SubVIs that run without any error independently, but generate an error when called from a top-level VI.

The programs do not make use of LabView and no LabView software other than whatever is packaged in the DAQmx runtime is installed on this computer.

Case 6: Concurrently running two or more analog input or analog output tasks

The programs use only one task of each type. Also, the problem appears in MAX before the programs have been run. There are no tasks defined in MAX, but only channels.

Case 7: Failing to properly clear a task and release its resources.

The resources are not being released. However, the cause is unknown. The programs close and dispose of the tasks after use and in the catch blocks, and the problem appears in MAX without running the programs.

[Catherine-B]

Hi dc128, 

You said you were using DAQmx 9.8 and MAX 5.5 on the Windows 7 computer, correct? What versions of DAQmx and MAX did you have on you XP computer?

I am going to try to reproduce this behavior on my end.

Best,  

[dc128]

The XP machines are using a mixture of versions between DAQmx 9.1 and 9.8, with very few running DAQmx 9.8, and are using the associated MAX version with each.

My next step is to revert to DAQmx 9.7.5 or 9.6 on the Windows 7 computers and see how that works; unfortunately, I won't be able to get to that until next week.  I'll post the results here once those tests are completed.

[dc128]

I have some additional information.

I tested the programs and MAX, attempting to recreate the issue, on another system with a different Windows 7 64 bit machine with a different 9178 connected via USB.  This computer had the same operating system image and the same software as the other computers, with the two following exceptions: the DAQmx version was 9.2.1 instead of 9.8 and the MAX version was 4.7.1 instead of 5.5. 

I could not reproduce the issue on that system, and both the programs and MAX worked as expected.

[PeanutButterOven]

Have you tried reverting the problematic system back to the DAQmx version 9.2.1?

[dc128]

I now have a third Windows 7 64 bit computer with MAX 4.7.4 and DAQmx 9.2.3 installed that exhibits the behavior described above.

The hardware and software configuration are similar to the other two mentioned.  To summarize, of three similar systems, two display this behavior and one does not.

System 1: Shows problem

Dell Optiplex 7010

Standard image of Windows 7 64 bit

cDAQ 9178 w/ 9215 modules, one 9265 module, one 9472 module

USB connection to computer

MAX 5.5

DAQmx 9.8 

PAL 2.9.1

USI 2.0 

System 2: No problem

Standard image of Windows 7 64 bit

cDAQ 9178 w/ 9215 modules, one 9265 module, one 9472 module

USB connection to computer

MAX 4.7.4

DAQmx 9.2.1

System 3: Shows problem

Dell Optiplex 7010

Standard image of Windows 7 64 bit

cDAQ 9178 w/ 9215 modules, one 9265 module, one 9472 module

USB connection to computer

MAX 4.7.4

DAQmx 9.2.3

PAL 2.6.2

NI Spy 2.7.2

PXI 2.5.6

Currently reverting System 3 to 9.1 and System 1 to 9.2.1.  Will update when completed.