msvcr100.dll error after 10 hours of usage of implemented dll

[budist]

Hey,

I imported a .dll (controls and imports data from a USB device) in a VI. I want to run the VI for a week (7 d). Without the dll and other hardware (which I cant use anymore) via VISA the VI never failed.

With the .dll it aborted two times after 15 to 16 hours and now after about 11 hours.

What could solve this problem? Is it the LabVIEW version or the DotNET version?

Does somebody got the error, too?

Thank you very much in advance!

[AndreasGareis]

Hello,

what dll are you using (manufacturer)? The crash can have many reason. Can you give more information about how your VI looks like and where you call the dll?

Best regards

AndGar

[budist]

Hey,

thank you for the reply!

The dll is from AST (http://www.ast.de/index.php/de/mess-und-regeltechnik/controller). It controls a USB-Device (the AE 703). I got one .dll for .Net 2 and one for .Net 4. I used the .Net 4 cause thats the latest version.

AST sent me a test-VI for controlling the .dll. That worked fine, so I adapted the Control-VIs for my VI. Can the problem still be related to the input-data types?

But maybe it has still something to do with buffer size? Cause the VI is running without any problem until some certain point.

Or should I try another LabVIEW version? I am still running tests with resetting the device. Maybe that will do it. 

Otherwise, maybe reset the USB-port (however that works and if that works)?

The VI looks like this:

I got three loops in parallel. The hardware is initialized before the measurement loop with three dll-calls in row. Within the measurement while-loop there is one call of the dll (read data). It's called every 15 ms.

I will post some pictures of the VI soon. I dont know whether I can post the .dll....

[budist]

I couldnt copy the text, so I hat do take screenshots. Does some of the àttached files/information help with the problem?

[budist]

More information: Win7 64 bit

LabVIEW: 32 bit (will check soon if RAM will overflow or/and 64 bit version will solve the problem)

in the attachment you may see the relevant part of the code. (I know Queue message handler would be better but its working this way 😉 )

I first need to get the tool running again without any error before cleaning it up (cause I dont think cleaning it up would solve the problem, except cleaning up some buffers )

Thanks for any help or advice!

[AndreasGareis]

Hello,

could you post the VI instead of a screenshot of it? Also, the Test VI you have received from AST would be handy.

Best regards

AndGar

[budist]

Hey,

I got the VI working (for more than one day up to now) @ Win7 64 bit instead of Win XP 32 bit.

I had a look at the Windows Task Manager and it seems that I need more than 3 Gb of RAM (at a x86 system).

The VI is running with a memory need of 2,7 to 3,2 Gb (all PC-tasks), starting at 2,7 Gb (and filling up to 3,2 at the beginning 15 hours).

So with more RAM available at the x64 system the VI is running without any problems until now. I ran the VI analyzer and found some memory opitimization possibilities, too.

If I find out more, I will let you know. Hope that helps!

Maybe another possibility?:

http://zone.ni.com/reference/de-XX/help/371361H-0113/glang/request_dealloc/

[budist]

Hey,

I got new problems with my VI. It is running for a longer period of time, but again, after a nearly constant time period it shows the error "unknown software exception" (0xc0000417) for the application at position 0x6f07af3e. (see attached file)

The "position" is different every time: before the last error it was at 0x7208af3e.

I updated every component on the Laptop (the PC I used before even rebooted, and LabVIEW not just stopped and showed the error message like on the Laptop now) and LabVIEW itself (all critical updates).

I add the .dll I implemented and some code.

Can someone find a solution or give me a hint?

Thank you a lot!