Leaderboard

I can't seem to find the post or links to sign up for the LAVA BBQ this year (2018). Is it still on? Thanks for any info...

mxLvProvider definitely refers to some project provider code, and TSVN is almost completely a project provider add-on. The best bet in this case would be to uninstall TSVN and see if you still see crashing. If the problem points to TSVN you might be able to reach out to the developer, but since it's a free toolkit I don't know how much bandwidth they put into development and updates on it.

Some of your crash logs point towards the TSVN Toolkit. Possibly related: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019RInSAM Edit: OpenCV also causes some issues: <DEBUG_OUTPUT> 21/02/2018 17:31:12.240 DWarn 0x50CBD7C1: Got corruption with error 1097 calling library OpenCVWrapperToCpp.dll function ?lv_Canny@@YAXHHNNH_NPAH@Z I suppose you were working with the Call Library function at that moment, so these problems are to be expected. Just make sure to restart LV every now and then to reset the memory or LV will crash eventually.

Opinions of Applications Engineer and not of NI R&D Each crash is going to create a .zip with an lvlog.txt and multiple .dmp files. The lvlog.txt will first print some basic information about your setup; OS Build, AppName (LabVIEW if it's the dev environment), LV Version, etc. The log will then print out some thread information which has never been all that informative to me. Finally you will see a Debug Output section for each DWarn or DAbort. A DWarn is something that LV could recover from and a DAbort is something that LV could not recover from. Usually the DAbort is what we are concerned with but if we get 20+ DWarns printed quickly before a crash I typically suspect they are pretty related to the crash. I looked at a log on my computer and found the following. <DEBUG_OUTPUT> 2/27/2018 8:21:52.351 AM DWarnInternal 0xB0BC654A: No path given for current component in JSON map file. C:\ProgramData\National Instruments\LVComponentLocationInfo\LVToolsProductMap.json e:\builds\penguin\labview\branches\2017\dev\source\panel\showerr.cpp(3732) : DWarnInternal 0xB0BC654A: No path given for current component in JSON map file. C:\ProgramData\National Instruments\LVComponentLocationInfo\LVToolsProductMap.json minidump id: 9c36ea77-c0f5-45bb-8b2f-2c4267d223ca $Id: //labview/branches/2017/dev/source/panel/showerr.cpp#5 $ The first line is the time of the error. The next two lines print the actual error message (if it has one) and the source where that error happened. Finally it prints the minidump id which ties this particular error back to a specific .dmp file in the zip folder. If you open the dump file of a minidump and have the correct symbols loaded you will be able to see the call stack but not much else (unless you have enabled full dumps). How much help you get from looking at this information is going to vary greatly depending on the particular crash but the most I personally hope for is a good indication of where to start looking. For instance, if the entirety of the call stack is DAQmx calls, looking at the DAQmx portion of your application sounds like a good place to start at least. Now the stack may just show that LV is allocating/copying memory and then messing with the Data Space. If that's the case, then we have to look for when LV may be allocating memory which means we haven't really learned anything too useful. Now let's say that we actually get useful information out of this and I can tell you that the reason for the crash is that you are trying to read data from a NULL channel reference (I'm just making that up). Now we've found the root cause in our source but we're not really closer to actually resolving your crash are we? The crash logs may tell us what went wrong at the lowest level in the LabVIEW source but without knowing how we ever got into that situation we aren't really able to make any recommendations for you to act upon. This is why having a reproducing test case is so important. If we know what went wrong and can show how we got there, we can take it to the appropriate people. TLDR: If you do attach some crash logs I am willing to take a quick look and let you know what I see but I can't promise anything.