Jump to content

Hard Crashes, maybe start async call node related?

Recommended Posts

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.



Link to comment

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.

Link to comment
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.

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

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.