lvalarms.dll crash

[ShaneRR]

I've got quite a problem here.

We are using a large LabVIEW application (written by me) for years now on different test benches.

The software changes a lot because we have to change our tests a lot. So far we had no problems since the time it was running on LabVIEW 7.1. Then 8.0, 8.2 and now 8.5.

My software was able to to it's job for hours and even days straight while handlings 128 input channels (SCXI), analog and relais outputs and CAN traffic while logging and visualizing all of the former mentioned things.

But now I have a branch of my software which crashes under very strange circumstances.

The program starts with a launcher, named Launch.vi. Here the user can open a configurations dialog or start the rest of the program.

While waiting for user input it reads the windows registry, that's basically all. This launcher level is nearly identical between all the versions, even the stable ones!

What happens is this: I run the VI and everything is fine. I can run the whole program from that point and it is perfectly stable.

BUT, if I stop the launcher and run and it again it crashes. The window borders appear but the contents are missing, just white space.

I tried to put LabVIEW into single-step mode, but it doesn't come even that far. It seems that LabVIEW crashes while it attempts to draw the window.

The crash message from my Vista x64 is:

 Problemsignatur:
  Problemereignisname:    APPCRASH
  Anwendungsname:    LabVIEW.exe
  Anwendungsversion:    8.5.0.4002
  Anwendungszeitstempel:    46a6a1e1
  Fehlermodulname:    lvalarms.dll
  Fehlermodulversion:    8.5.1.1
  Fehlermodulzeitstempel:    469d5675
  Ausnahmecode:    80000003
  Ausnahmeoffset:    000015cb
  Betriebsystemversion:    6.0.6001.2.1.0.256.6
  Gebietsschema-ID:    1031
  Zusatzinformation 1:    1921
  Zusatzinformation 2:    ea0e3d40cb8bc5e7fdb3eb63fdd22b01
  Zusatzinformation 3:    5fdd
  Zusatzinformation 4:    6fbd21e6e8410cabced82d944fc159e1

I run it on a Core 2 Duo. But under XP and different processors (like Athlon 64 and similar) this behaviour is the same.

Under LabVIEW 8.6 its also the same.

The Launch.VI is pretty much similar to versions which runs fine, so I think that the problem must be within the rest of the program.

But at that time those VI's aren't running yet. It's just a "while" with an event structure.

I don't know where to start to look for the source of this problem and my app is quite big.

I would be really thankful for any ideas...

[andre.buurman@carya]

Try to eliminate code parts by disallowing code to start.

Each try disable more code unitl the problem disappears.

Then re-enabled the last disabled code to see that the behaviour returns.

Then try to disable only code in that part etc.

If its a specific thing you will probably find it. NOTE the diagram disable structure can be very usefull.

[muks]

Will this be of any help

[ShaneRR]

@muks:

I've already seen that post and tried this out, but it didn't help.

@André:

Thanks! That did it! 🙂

I had to set one of my sub-VIs to... erm... "ablaufinvariant" (sorry, I've only got the german version here).

I still don't get it why my whole LabVIEW crashed because of that, but at least I got rid of that nasty bug.

[Jochen]

ShaneRR,

"ablaufinvariant" is "reentrant" in the English version of LabVIEW. As you probably know, reentrant vis allocate a new memory space for each instance of the vi in your code. This changes significantly the applications' timing. The crash that you have experienced seems to be the result of a race condition or something similar.

I don't know, if there is a correlation with this KB document, as this document only mentions issues with quadcore systems, but it would great, if you could do a test with your original (crashing) configuration and the attached lvalarms.dll from the KB.If you can do this test please post your results.

I'm glad, that you have managed to eliminate this problem, but as the root cause of the issue is not clear, there is still some uncertainty. If you come across a similar issue again, it would be great, if you could reproduce it with a small example and post it here.

Thanks and kind regards,

Jochen Klier

National Instruments

[ShaneRR]

Jochen,

I've tested the DLL from the KB article with a restored "buggy" application and it still crashes. As far as I can see the behaviour is exactly the same.

But while testing I discovered that the reentrant option was not the solution to my problem.

The sub-VI containing the buggy code consists of  4 concurrent while-loops.

One of them is the main "program" with some initializations and a big event structure.

The remaining 3 are used for a ramp functionality (I give it an end value and the time to reach that value).

2 of them were always synchronized in their start time by a create notifier VI (I wired the output to the while-loop but without using it) but the other 2 were "floating loose" in the VI.

After wiring the output of the notifier VI to one of the other 2 while-loops (and I mean while-loop #3, it doesn't help to synchronize #4) the crash disappears.

I'm still not sure why, as those 2 are very similar to each other.

The concurrent while-loops cannot be the problem as well, because I have applications with 6 oder 7 of those starting at once without any synchronization and they work perfectly fine.

The other strange thing is that all ramps are inactive at first. So the only thing the while-loops has to execute is a case with a 250ms wait in it.