Cwdss.exe error: can't read memory location

Question

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?

Answer 1

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