LabVIEW suddenly crashes without error in Windows 7 64 bit

[usoler]

Hello Experts! We are using LabVIEW (can't remember by heart whether it is 2010 or 2011, but check this tomorrow) here for our measurement application. It uses RS-232, USB and GPIB for communication with the hardware. The driver VI for RS-232 is self-written the other are third-party. From time to time - about once a day or week - the application suddenly crashes without any error message or other hint on what's going on and causing the problem. As mentioned this is on Windows 7 64 bit. So what would be the best thing to do to get a clue on what's the problem? Is there any way to get information about those crashes anyway? Thanks a lot for any help in advance! Greetings Ursin Solèr ETH Zurich - Switzerland

[smercurio_fc]

Well, it can't be 2011 since it's not released yet. Unless you're using the beta version? Do you not get a dialog when you restart LabVIEW asking you to investigate an internal error? Was the option turned off? (Check the "Environment" section in Tools->Options.) Do you see any errors in the Windows event logs? Do you see any files in your "My Documents\LabVIEW Data\lvfailurelog" folder?

Without more details I'd guess that for the kind of crash you're seeing it's probably a hardware driver or a DLL call somewhere in the code.

[usoler]

Well.. to justify this it is LV 2009 (9.0f3 64-bit) and not 2010 (and clearly not 2011) - sorry for that confusion. OS is 'Windows 7 Home Premium' (6.1 build 7600).

To be honest the last crash occurred to another person, so I was not able to check if the ' investigate an internal error' dialog appeared (but I would assume it since the option is still ON in the configuration). So I was looking into the windows event logs but most of the issues reported there are related to missing files/url when accessing the LV web server - which should be quite normal and not kill the app as far as I understand... (?) Last I looked into 'My Documents\LabVIEW Data\lvfailurelog' as you mentioned but this directory was empty...

So what would be best to do next? Wait until the error appears again? Or is there a possibility to RE-investigate an old error again...?

Thanks a lot for your fast reply and greetings!

[smercurio_fc]

I don't know of a way to investigate an old crash, especially if there is no log. If this is a real hard crash it's possible the crash reporting system won't be able to catch it. You could wait to see when it happens again. Do you have built-in logging into your software so you can track what it was doing at the time of the crash?

[usoler]

Hello!

Thanks for your reply and sorry for my answer to be that late (I working on this project Thursday only).

> If this is a real hard crash it's possible the crash reporting system won't be able to catch it.

That's what I'm afraid of...

> You could wait to see when it happens again.

Is what I am doing now - but this is no good solution since in the worst case I have to wait for months... ;))

> Do you have built-in logging into your software so you can track what it was doing at the time of the crash?

What do you exactly mean by 'built-in logging'? My data are logged on-the fly (every loop iteration) but I am

NOT logging status messages or similar to identify the crashing sub-system...

How would you do that?

Meanwhile I had another idea; may it be possible that a memory leak in my VI crashes it that hard?

Thanks and greetings!

Ursin

[smercurio_fc]

By the built-in logging I'm referring to using something like a memory log (implemented via a queue, for example) that you add entries to in your VIs. These entries are just text entries to indicate the action currently being performed. If you log to disk then when it crashes you could see where it was.

If you suspect a memory leak then the Task Manager (or equivalent on other operating systems) would be one place to start to look for this.

[usoler · Accepted solution]

> By the built-in logging I'm referring to using something like a memory log (implemented via a queue, for example) that you add entries to in your VIs. These entries are just text entries to
> indicate the action currently being performed. If you log to disk then when it crashes you could see where it was.

I see... somehow iterative process I think - since you have to have an idea where the system crashes to be able to define which events you have to log...

> If you suspect a memory leak then the Task Manager (or equivalent on other operating systems) would be one place to start to look for this.

This is exactly what I did - the VI took about 0.1 - 0.2 kByte/min - so I introduced a cut-off length for my data buffers... Do you have an answer to the question: "Is a memory leak able to crash LabVIEW without raising any error messages?"

Thank you!

[usoler]

(it's not really solved but it seams to us that the memory leak may be in combination with some hardware issues caused the praublem - after solving the memory leak and all warnings - the VI runs without issues at the moment)