I'm running into an error message which is proving particularly difficult to debug. After my built application has been running for some time, a windows system error will pop up telling me my application has done something bad and needs to be shut down (and sorry for the inconvenience). Clicking through to the "see what the error report contains" page reveals the issue as being in the lvrt.dll module at offset 0080a6a.
This unfortunately doesn't mean much to me.
On some occasions when I click "Don't Send", another error message pops up informing me there is "Not enough memory available to complete this operation".
The program will typically run between 8 and 24 hours before the error occurs, though I've had it run error-free for upwards of 48.
My program is unfortunately fairly large, and depends on communication with proprietary hardware so can't be uploaded in a functional state. In general terms, the body of the program (which is executing when the error occurs) involves RS-485 serial communication and simultaneous display of data to 7 continuously updating strip charts (producer-consumer design), along with envalope detection and RMS calculations in real time, all of which is multiplied by two parallel channels (around 1Mb/s data rate for each). The data is also buffered and stored in binary files for later review. Binary files are closed and a new one is opened for every 10 minutes of data collection (approx 50MB of data).
There are also about 40 user controls associated with each channel, and are polled periodically (a couple times a second). The crashes occur during over night tests, however, when there is no user input. Globals are used for inter-panel communication, but no global is written to in more than one location (most are read in multiple locations).
I know this is a bit of a shot in the dark here, but does the lvrt.dll error at offset 00080a6a mean anything to anyone? Are there any "typical" causes for a failure in lvrt.dll having to do with prolonged high data rate serial communications? For reference, this has occured on multiple machines, but all the machines it has occured on are identical out-of-the-box laptop models running XP 32. I'm going to try to run an overnight test tonight on the development machine and see if I get any different results (Vista 64 vs Windows XP 32).
I can't say my hopes are high with this one, and I'm gonna continue to comb over the code for any possible conflicts, but any insight would be appreciated.
