Leaderboard

Hi! I'm a lucker then... I'm writing and reading from Madrid (Spain). I work with PXI-RT, cFP and recently with cRIO. I started using LV6... a long time ago! Now I use LV7.1 and LV2010. I recently found an interesting quote: "A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible." I think that's why we all come here: generally you can find someone who already solved your problems

Reading someone else's memory is limited by the memory protection system. Here is a link to a MSDN site that briefly describes the topic: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366785%28v=vs.85%29.aspx Whenever you try to copy memory that hasn't been allocated, there is a chance to get an access violation exception. Whether an exception occurs or not depends on the data that is accessed. For example: Assume you've allocated an array of 512bytes and one of 256bytes within your DLL. Memory is allocated in contiguous blocks, therefore the block would have a size of 768bytes. Now you accidentally read 712 instead of 512bytes of the first array, but no error occurs, because the memory is within the same block. The result would just be an array of the 512bytes of the first and 200bytes of the second array. Next you try to read 1024bytes and get an access violation, because the number of bytes overlaps the number of allocated bytes. This is just a stupid example, since there is much more to it, but this should cover the basics ( and I can't explain it much better ). Long story short: Do never access memory, that is not allocated properly! As you're calling a DLL, the allocated memory is in the same space as the LabVIEW IDE / Runtime, therefore you are trying to access data of some LabVIEW internal memory blocks, which are most likely protected. I also assume that LabVIEW does force some memory protection over all DLLs that are called in its scope. The result is what drjdpowell just posted: Yes, Microsoft is a bitch when it comes to protecting precious data. The memory management standards are now insane compared to XP. In most cases if you set the error checking options to maximum, the LabVIEW IDE will show violation errors if memory is incorrectly accessed. That might help you to pinpoint the issue. Of course there is also always a chance to crash LabVIEW because you incorrectly accessed memory... Wow, I've just wrote an article to questions that could be answered with two 'yes'

(So far) I have only seen the error on a Windows XP machine with a built exe. I haven't programmed in C for a while now but I seem to recall having received errors when accessing memory that was not allocated to my application. I cannot recall if both read/writes did it or only writes. However, I can believe that these days windows would watch to make sure an application is only using the memory allocated to it (reading or writing). Did your customer find a reproducible way to cause the error?