Where to start when LabVIEW Crash Reporter is displayed

[takanoha]

Hi

I have written an app to control my company's camera via a .NET wrapper. During live stream (LabVIEW isn't executing any command) LabVIEW crashes after an hour more. It is reproducible but the duration it takes to reproduce is inconsistent. I have attached Visual Studio's debugger and the memory usage was stable and at the time of exception nothing was caught on VS. 

The only information I have is the LabVIEW Crash Reporter's message. Every time when the crash happens the EIP is the same address. Given the EIP is there anything I can do to diagnose where the culprit is ? 

 

Thanks

 

 

 

[takanoha]

From the debug report found in 

C:\Users\xxxx\Documents\LabVIEW Data\LVInternalReports\LabVIEW\17.0f2 (64-bit)\84ca9510-1bbf-48c1-b8ef-b46ed427d966\84ca9510-1bbf-48c1-b8ef-b46ed427d966

If I open the .dmp file with Visual Studio I get an exception unhandled message saying

Unhandled exception at 0x00007FF873C54008 (KERNELBASE.dll) in 86cc2439-b4d5-448a-928e-3b3ce5e7e03a.dmp: 0xE0434352 (parameters: 0xFFFFFFFF80004005, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x00007FF84C320000). occurred

This exception was thrown at the same address as the EIP #. Does that mean this exception was thrown at KERNELBASE.dll ?

 

For lvlog.txt I have
 

Quote

####
#Date: Wed, May 30, 2018 10:09:26 AM
#OSName: Windows 10 Pro 
#OSVers: 10.0
#OSBuild: 16299
#AppName: LabVIEW
#Version: 17.0f2 64-bit
#AppKind: FDS
#AppModDate: 8/16/2017 19:45 GMT
#LabVIEW Base Address: 0x00007FF6C3F90000

InitExecSystem() call to GetCurrProcessNumProcessors() reports: 8 processors
InitExecSystem() call to GetNumProcessors()            reports: 8 processors
InitExecSystem()                                      will use: 8 processors
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3610544972.71161509, (10:09:32.711615086 2018:05:30)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3610544972.71161509, (10:09:32.711615086 2018:05:30)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3610544972.71161509, (10:09:32.711615086 2018:05:30)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3610544972.71161509, (10:09:32.711615086 2018:05:30)]
starting LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3610544972.71161509, (10:09:32.711615086 2018:05:30)]
starting LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3610544972.71161509, (10:09:32.711615086 2018:05:30)]
starting LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3610544972.71161509, (10:09:32.711615086 2018:05:30)]
starting LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3610544972.71161509, (10:09:32.711615086 2018:05:30)]

<DEBUG_OUTPUT>
5/30/2018 10:15:50.402 AM
Crash 0x00000000: Crash caught by NIER
File Unknown(0) : Crash 0x00000000: Crash caught by NIER
minidump id: 86cc2439-b4d5-448a-928e-3b3ce5e7e03a
ExceptionCode: 0xE0434352

</DEBUG_OUTPUT>
0x00007FF86527147C - nierInterface <unknown> + 0
0x00007FF865276441 - nierInterface <unknown> + 0
0x00007FF8652753F9 - nierInterface <unknown> + 0
0x00007FF873D291A0 - KERNELBASE <unknown> + 0
0x00007FF877838988 - ntdll <unknown> + 0
0x00007FF8778213D6 - ntdll <unknown> + 0
0x00007FF8778350BD - ntdll <unknown> + 0
0x00007FF8777AD278 - ntdll <unknown> + 0
0x00007FF8777AB6E3 - ntdll <unknown> + 0
0x00007FF873C54008 - KERNELBASE <unknown> + 0
0x00007FF84C37CEAA - clr <unknown> + 0
0x00007FF84C4F0EFB - clr <unknown> + 0
0x00007FF84C4F0F54 - clr <unknown> + 0
0x00007FF84C73254E - clr <unknown> + 0
0x00007FF84C72FD79 - clr <unknown> + 0
0x00007FF84C382935 - clr <unknown> + 0
0x00007FF84C32242D - clr <unknown> + 0
0x0000022E3CCD80C3 - <unknown> <unknown> + 0
0x000000F5B477FD88 - <unknown> <unknown> + 0
 

 

[jacobson]

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.

[joerghampel]

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?)

[jacobson]

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.

[takanoha]

Hi Thank you!!! @jacobson Please see attached.

 

 

86cc2439-b4d5-448a-928e-3b3ce5e7e03a.dmp

[jacobson]

Hard to say too much but even without any NI symbols, I get the following call stack which, to my untrained eye, seems to indicate that the camera driver you are using is calling causes some clr exception. I don't have any symbols for the pvcam64 driver so I don't know what call is being made.

 

[takanoha]

@jacobson That's very helpful! I will attach a debugger to find out. Thank you very much !

[takanoha]

@jacobson I know this is beyond LabVIEW, but I have the pdb file now and how do I attach to VS to find out which function it is calling ?

I have narrowed down to this point.

1. KERNELBASE.dll through .NET (0xE0434352)

Unhandled exception at 0x00007FFF5FDC4008 (KERNELBASE.dll) in 33cb1333-6294-4505-a1fb-453e268d3b0b.dmp: 0xE0434352 (parameters: 0xFFFFFFFF80004005, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x00007FFF37DA0000).

I want to find out this 0000022e3cccd80c3().  See attached screenshot.

After opening the dump file with VS I selected the folder where the pdb file is from Tools->Option->Debugging->Symbols but it isn't displaying the function name. 

 

Thank you.

[jacobson]

Not sure to be honest. All of the NI symbols are not handled by me so I just point to some symbol server.

[takanoha]

I used WinDbg Preview and it worked ! 

[EvgenKo423]

On 5/31/2018 at 8:04 PM, jacobson said:

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.

Just wanna add to the topic that you can disable dump creation for DWarns by placing the following key into the INI file:

NIERMaxDWarnDumps=0