Leaderboard

To ensure NIER collects the most useful information, you need to set a few INI keys on the process that is executing the LabVIEW code (Development System: LabVIEW.ini in the LabVIEW directory; Run-Time Engine: in a [LVRT] section within the .ini file next to the executable). INI keys: NIERDumpType=full LVdebugKeys=True DWarnDialog=True DPrintfLogging=True promoteDWarnInternals=True Of these keys, you should always set the NIERDumpType=full key when debugging an issue, because this key will cause a larger crash dump with more debugging information to be created. The other INI keys can be used to gather more information, but they have the caveat that they will slow execution of the code down, which can be a problem for certain types of issues. It is also important to note that when NIER creates a full crash dump, it should not be submitted to NI through the NIER crash dialog. The NI system is not prepared to handle crash dumps as large as those generated by NIER with the INI key enabled. (I got this information from an NI support person long time ago, I'm not really sure if all of this still applies. But perhaps it helps?)

I attended my first TestStand course in 2004 and have been working with TestStand on a regular basis since 2008. To me it seems that every one who has replied to this thread until now is making the most common miss assumption about TestStand: "TestStand is a test sequencer". Of cause you are right about that, but it is so much more. With TestStand you get a toolbox for creating your own test management frame work. This means that you as a test developer need to spend some time getting to know you toolbox, just like you had to learn how to program in LabVIEW at some point. An yes, TestStand is a complex toolbox to get your head around. That is the trade off for the flexibility you get. In the posts here I have not seen one challenge that I could not implement and make work in TestStand, just as easy or easier that in a custom LabVIEW sequencer. And when you are on the track with TestStand, you will realize all benefits like batch executions, reporting and property loading. Of cause you can implement and maintain all of this your self, but they are handed to you with TestStand and NI will maintain the fundamental function for you. However I do agree with Chris_Collier that it would be nice if NI provided a course on how to make high level architectures with TestStand. So I guess my point is this: Do not just buy a TestStand license and start using it out of the box as a simple test sequencer. You need to be clear about your goals for the test system, learn how to use TestStand and then learn how to implement you test system with TestStand.

I usually don't recommend using the first token unless you are trying to capture a specific crash. Full crash dumps can be very large and not only will crashes generate full dumps but all DWarns will create full memory dumps so the LVInternalReports folder will get pretty enormous in most cases. I'm not 100% certain but doesn't the DWarnDialog token just show a modal dialog window on any DWarn? I remember doing something like that at one point and just found it very annoying personally.

There's not much specific information in your particular lvlog although in general there's only so much information you can get from it. The header information is obviously helpful to any third-party looking at your crash but it's just telling us about your system, LabVIEW version, uptime, etc. so most things that you already knew. All lvlogs will have at least at least one <DEBUG_OUTPUT>. You have a single debug output which only tells us that the system crashed but does not have a specific DAbort which is a (sometimes) more human readable print of what the problem is. If you do see a DAbort you can try to search that online but it's still pretty difficult. Sometimes you may also see a bunch of DWarns which are more of warnings but if you get a stream of the same warning it's probably helpful to try looking that up. Below the debug output header you see the call stack but you don't have the symbols so you can't see any LabVIEW functions. For this particular crash you could probably load 86cc2439-b4d5-448a-928e-3b3ce5e7e03a.dmp and see most of the call stack because it's mostly acting in Microsoft things. NIER interface is just the method of reporting the crash so even though you won't see those particular calls it's not really important to you. To answer one of your first questions, KERNELBASE looks to be the last call before the crash was reported so that may be the faulting module but that doesn't mean that the real problem wasn't upstream so the best thing to do at this point would be to get some sort of reproducing issue and set up a service request. If you can attach 86cc2439-b4d5-448a-928e-3b3ce5e7e03a.dmp form the crash .zip that was created I can take a look but I can't promise all that much. As a side note, LabVIEW NXG prints the full call stack when it crashes so that's pretty nice. Also if you are using Windows 10 and haven't done any debugging with .dmp files before I would recommend using WinDbg Preview.