cwdss.exe error: can't read memory location

[Alan Fisher]

I have 3 PCs running XP, Service Pack 1, each with a frame-grabber card, either NI 1409 and 1409. They run identical code. Each one reads the active video channels in sequence, and saves the new image locally on a DataSocket server. These are in remote locations, with seldom a visitor. The users are near a 4th machine, which gets images from the other 3 by reading their DataSocket servers. It is slower, since it does calculations on each image. This runs 24 hours a day, but about once a day one of the 3 image-capture machines--always the same one--halts, displaying an error message and waiting for someone to notice the message and push "OK". After that, it just keeps on going as if the error was no big problem. But of course it is a problem, since the halt is not noticed for a while.
The error window is titled "Socket Notification Sink: csdss.exe Application Error". It then explains that "The instruction at location 0x0040aaf7 referenced memory at 0x482f6f72. This memory could not be 'read'." It always shows the same instruction and the same read address.
What is this telling me? How can I tell what is going on at the address cited? How can it work for hours and then try an out-of-bounds read? Why does this happen with only one of the three machines? Could this be some infrequent timing conflict between reading and writing to the DataSocket?

[DJ_L.]

Hey Alan,
Can you please provide more information on the software that you are using. For instance, are you using LabVIEW, and if you are, what version of LabVIEW are you using (6.0, 6.1, 7.0, 7.1, etc.)? Or are you using some other software, like CVI, VB, or C++? Also, do you have this issue if you do any other kind of Image Acquisition without the Datasocket Communication?

This information will help us determine what might be causing this specific error. Thanks.

Regards,
DJ
Applications Engineer
National Instruments

[Alan Fisher]

I am running Labview 6.1 on a Windows XP machine (Service Pack 1). I never run the code without the DataSocket, since the whole point is offer new images when needed to the PC in the room with the users, which does all the serious calculations. The image is stored in the DataSocket server as a 640 by 480 integer array of either U8 or I16 format, depending on the type of frame-grabber. The machine with the errors has a 1409 and so gets 10-bit data, saved in I16 format. The odd aspects, again, are that the program runs without a hitch for a day or so, then does this illegal read, and that the same code runs on two other machines without this problem ever showing up.

Thanks,
Alan Fisher

[Brett_B.]

Hey Alan,

Are you running this program as a VI or as an EXE. Since it is working on the other 2 machines I believe it to be a corruption in the program or machine. A quick check/remedy for this would be to reinstall the EXE if it is in fact an installable executable. Are these designated systems or are other tasks performed on these machines?

regards,
Brett Burger

[Alan Fisher]

The program runs as a Labview VI, and the machines are essentially dedicated to this job. The machines are available for other tasks, but the need is infrequent, since users are seldom present.

[Brett_B.]

Are you running VIs with the development system installed on each one or do you have a distributed executable?

-Brett