LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview 2011 application crashes from time to time

Hi together,

 

from time to time my LV application crashes. This happens in different stages of the program.

I use some ext. DLLs written in C, some simple IO hardware and some serial communications with ext. hardware.

My feeling is that it has s.th. to do with the upgrade from LV 851 to  LV 2011, but I'm not sure.

On target PC and on develpment PC we're using WXP Pro. SP3.

 

Many Thanks.

0 Kudos
Message 1 of 14
(3,059 Views)

Random crashes as you describe them have two common sources:

- Race Conditions

- Access Violations caused by external code.

 

There are some more, for instance memory leaks, but they are less common (for crashes at least).

 

The main question is:

What happens when a crash occurs? Are there any dialogs popping up? Is the application frozen after this or does it disappear completely?

Did you check Windows event logs for possible entries?

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 2 of 14
(3,056 Views)

Hi Norbert,

 

thanks for answer. Sorry I forgot to attach the log file. We've a pop up windows. After OK click the application is closed.

Windows is still running.

Attached the log. What are race conditions?

 

Thanks, Thomas.

 

 

####
#Date: Fr, 7. Sep 2012 11:24:58
#OSName: Microsoft Windows XP Service Pack 3
#OSVers: 5.1
#OSBuild: 2600
#AppName: ASELFEET
#Version: 11.0f2 32-bit
#AppKind: AppLib
#AppModDate: 09/07/2012 05:47 GMT
#LabVIEW Base Address: 0x30000000



07.09.2012 11:30:29.886
Crash 0x0: Crash caught by NIER
File Unknown(0) : Crash: Crash caught by NIER
minidump id: 4348c788-ae48-4b2a-a8c1-056ac57e6e81
ExceptionCode: 0xC0000005ËN
0x3072C804 - lvrt <unknown> + 0
0x3072CBB8 - lvrt <unknown> + 0
0x7C35F0C3 - MSVCR71 <unknown> + 0
0x7C8438FA - kernel32 <unknown> + 0
0x00000000 - ASELFEET <unknown> + 0

 

0 Kudos
Message 3 of 14
(3,053 Views)

Thomas,

 

a race condition is something, well,... the name is very expressive. It occurs if you try to access a shared resource (interfaces or memory {e.g. a variable *cough*}) from different, concurrently running parts of your software.

 

What does the dialog tell you? Does it come from LV or from the OS?

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 4 of 14
(3,050 Views)

ok, thanks for explanation. I'll check if there are some stupid variables which are written from different locations.

The windows event log I'll check too.

 

The dialog comes from LV and tell s.th. like "Sorry for to inconvenience .... We have to close your application"...

 

The LV log file is attached in the post above.

 

Thanks.

0 Kudos
Message 5 of 14
(3,047 Views)

If your program is using references the garbage collection in 2010+ is alot more aggressive, thus a reference can get cleaned and you try to operate on the Null-ref. That should be reproducable in the development environment.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 14
(3,032 Views)

Thanks for the hint with the references. Until now I cannot find anything where I tried to access a closed ref.

 

This sounds for me a little bit like: Go back to LV 851 and then it works.

 

 

I found in the application event viewer from windows "No multicast socket available to use for address 224.0.1.1"

 

Could this has s.th. to do with the problem?

 

 

0 Kudos
Message 7 of 14
(3,028 Views)

I tried to access a closed ref  on the target system --> no crash.

 

 

0 Kudos
Message 8 of 14
(3,020 Views)

The crash dialog from LV indicates (most common reason) an unhandled exception thrown by a component used in your application. Therefore, the OS shuts down the process of this exception, in your case LV.

 

From experience, external code is a prominent source for such exceptions. You should try removing all DLL calls as a first step for pin-pointing the source of the crash. If the crash is not occuring anymore, it is most likely that a call has invalid parameters (e.g. empty array instead of a predefined buffer).

Try to boil down the issue as much as possible. To be honest, this could be a very time consuming issue, but you have little to no choice i assume.

 

Sidenote: Do you have the Desktop Execution Trace Toolkit? If yes, run it and observe memroy allocations, reference leaks and unhandled errors as primary parameters.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 9 of 14
(3,018 Views)

It might be worthwhile to go through all your DLL calls and set error reporting to maximum if it is not already.

 

Good luck!

 

0 Kudos
Message 10 of 14
(3,000 Views)