Hard Crashes, maybe start async call node related?

[GregFreeman]

I have been getting some hard crashes in my built application and I have some strange feeling (although it's just a guess) that it is related to a combination of using the database toolkit in a pool of workers that are launched by the start async call node. Their job is to sit there and monitor a directory then parse data files and throw their contents at the database through a stored procedure call. All my hardware comms (2 instruments) are using scpi commands through VISA GPIB and TCP so I think the risk that those are causing crashes is relatively low.

Active X inside a bunch of parallel threads seems far more risky, even though as far as I can tell adodb should be thread safe, and each thread manages its own, unshared connection. These crashes are happening ~once a day on multiple test stations. I have sent the crash dumps to NI but am waiting to hear back. Right now I am grasping at straws because when I look at the dump file it's pointing me to function calls in the lvrt dll which does nothing for me. 

I am mostly just looking for any debugging suggestions or direction to getting this resolved more efficiently than just disabling code one loop at a time. I'm also curious if anyone has seen something similar. For the time being, I have reduced my number of workers to 1 in case it is a thread safety issue. I have also considered getting rid of that DB toolkit and leveraging .NET, even though I think that is just a wrapper around the same calls. Looking inside the database toolkit VIs alone scares me.

FWIW I am using LabVIEW 2013 in this application.

Thanks!

 

[bbean]

what kind of hardware is the application running on ?  eg desktops, rackmount computers, pxi racks?

[GregFreeman]

Desktop, windows 7. Connected to Oracle 12c database.

 

Edited September 22, 2017 by GregFreeman

[bbean]

Ok if you said PXI I was going to say check the RAM type.  I had a evil crash that appeared randomly on machines and after a long process with NI's help found that it was the RAM.  NI sells "certified" RAM for the their PXI's and I will always buy that in the future even though its a complete ripoff.

Back to your issue.  Have you tried the Desktop Execution Trace Toolkit to check for reference/memory leaks yet?

I wouldn't be scared about going under the hood of the db toolkit, but I wouldn't go there quite yet.

[drjdpowell]

It’s not likely to be related to the Async Calls, per se, as those don’t have anything to do with threads (async-called VIs run on the same threads as all other subVI calls).

Edited September 22, 2017 by drjdpowell

[GregFreeman]

On 9/22/2017 at 6:03 AM, bbean said:

Back to your issue.  Have you tried the Desktop Execution Trace Toolkit to check for reference/memory leaks yet?

Nope, but that is a good idea. Working on getting that set up now. Don't know if it makes a difference but here is the output from the bottom of the lvlog.txt file.

<DEBUG_OUTPUT>
9/23/2017 4:20:51.818 AM
Crash 0x00000000: Crash caught by NIER
File Unknown(0) : Crash 0x00000000: Crash caught by NIER
minidump id: 41eb3397-b106-4d85-a433-2ce31d619f06
ExceptionCode: 0xC0000005

</DEBUG_OUTPUT>
0x30762E76 - lvrt <unknown> + 0
0x30763518 - lvrt <unknown> + 0
0x30079A96 - lvrt <unknown> + 0
0x307F05C1 - lvrt <unknown> + 0
0x308035CD - lvrt <unknown> + 0
0x768F62FA - USER32 <unknown> + 0
0x768F6D3A - USER32 <unknown> + 0
0x768F77C4 - USER32 <unknown> + 0
0x768F788A - USER32 <unknown> + 0
0x3088BDBD - lvrt <unknown> + 0
0x3088C237 - lvrt <unknown> + 0
0x01471B06 - QtManager452_2013 <unknown> + 0
0x670E7251 - NIQtCore_2013 <unknown> + 0
0x00000000 - <unknown> <unknown> + 0
0x00000000 - <unknown> <unknown> + 0