Jump to content

Where to start when LabVIEW Crash Reporter is displayed


Recommended Posts

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

 

 

 

Capture_debug.JPG

Capture_debug2.JPG

Link to comment

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
 

 

Link to comment

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.

  • Like 1
Link to comment

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.

 

stack.png

Link to comment

@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.

Capture_callstack.JPG

Link to comment
  • 2 years later...
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

 

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.

Guest
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.