APPCRASH on module nivissvc.dll

[endeavor]

hello all,

i'm having problems with my 32-bit machine vision application running under 64-bit win 7—something causes crash after certain time of execution, which could be from 4 hours to several days. app is working in automatic mode, capturing images from FLIR camera and processing it infinitely. it also works with MSSQLExpress DB, writes binary videos, images, text logs to the local hard disk etc. memory private working set is stable... app was developed with LV 2010 SP1, IMAQdx version is 3.9.1.

here is info from windows:

Problem signature:
Problem Event Name: APPCRASH
Application Name: --------.exe
Application Version: 0.1.0.0
Application Timestamp: 4d2fa0d5
Fault Module Name: nivissvc.dll
Fault Module Version: 11.0.1.49152
Fault Module Timestamp: 4e2b0124
Exception Code: c0000005
Exception Offset: 00107e2d
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 1053
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

any suggestions?

thanks in advance!

[ChristopheC]

It would be helpful to see the full call stack. Would that be possible to attach it to Windbg and try it again attached to the debugger?

Do you need instructions on how to do that?

-Christophe

[endeavor]

Dear ChristopheC,

thank you for your reply, I'll try Windbg and come back here with new info.

[endeavor]

Dear Christophe,

sorry for the delay, my debugging was postponed till yesterday. Here is some new info.

1) When the program is in acquire mode WinDbg permanently shows:

...

(1718.1a24): C++ EH exception - code e06d7363 (first chance)
(1718.1650): C++ EH exception - code e06d7363 (first chance)
(1718.1a24): C++ EH exception - code e06d7363 (first chance)
(1718.1a24): C++ EH exception - code e06d7363 (first chance)
(1718.1a24): C++ EH exception - code e06d7363 (first chance)
(1718.b0c): C++ EH exception - code e06d7363 (first chance)
(1718.1a24): C++ EH exception - code e06d7363 (first chance)
(1718.1a24): C++ EH exception - code e06d7363 (first chance)
(1718.1a24): C++ EH exception - code e06d7363 (first chance)
(1718.1a24): C++ EH exception - code e06d7363 (first chance)
...

Pause between messages is about 500 ms. Looks like a timeout action, I'll check...

2) It seems that in appcrash situation we have the following:

(1718.1a24): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** ERROR: Symbol file could not be found. Defaulted to export symbols for nivissvc.dll -
nivissvc!LV_ImageDTFlatten2+0x3d:
6c507e2d 8b00 mov eax,dword ptr [eax] ds:002b:44800000=????????
0:019:x86> g
(1718.1a24): Access violation - code c0000005 (!!! second chance !!!)

Do you have any comments on it? Thanks in advance!

[invancea]

Is it possible for you to provide a VI which reproduces this issue?

Thanks

[endeavor]

Hello ivancea,

thanks for your answer. Would you explain please what do you mean under your question? At the moment it's impossible for me to identify which of hundreds VIs could evoke this problem...

[David-A]

Hello endvr,

Does this crash only occur when you are using the executable or does it also occur when you are running within the LabVIEW envirnoment?  You said there are hundreds of VIs, would you be able to use highlight execution to watch the ones that call into the nivissvc.dll?  Do you have the Desktop Execution Trace Toolkit?  If so, you may be able to run that to determine which VIs are being called at the time of failure.

David A

[BlueCheese]

Hi,

That crash is occuring on an internal function used to flatten an image into a string. Are you perhaps using Vision images in shared variables or using any of the palette VIs to manually flatten an image into a string?

If you are using shared variables with images, could you try changing the shared variable from an image type to a string type and manually flattenning and unflattening on both ends to see if this fixes the problem? If so it could point to an issue with the native support for images inside of shared variables (which is a fairly new feature).

Eric

[endeavor]

Dear David A and Eric,

thanks for your help. Answering your questions...

1. This crash only occurs during application execution. And one more bad thing is that at the moment I don't have all the neccessary hardware in my office so I can debug this program only directly on the customer's PC using a chain of remote desktop connections. So WinDbg seems to be the only way to get any info.

2. For me it was very strange to notice LV_ImageDTFlatten2 name in the log, because I'm not using Flatten Img to String function, neither shared variables (never, never!). Any suggestions on what function could call flatten operation internally?

Thanks in advance.

[BlueCheese]

I can't think of any other reasons off-hand for why that function could get called aside from when running on an RT target with a front panel opened on a hsot PC somewhere else. Are you postive you don't have some cluster somewhere in your code that contains a reference to an image that is going through the native LabVIEW flatten to string?

If you already are using WinDbg to get the exception details, a simple thing you could do is use the ".dump <filename>" command to generate a crash dump file that you could upload. With this crash dump we can see the whole call stack and details about what might be calling it and why. This might lend a bit more insight into what is going on. If you either attached it the forum or uploaded it it to the write-only FTP site here: ftp://ftp.ni.com/incoming/ we could then take a look.

Another helpful thing could be to use the command "bp nivissvc!LV_ImageDTFlatten2" to set a breakpoint on that function before the crash occurs and then step through your LabVIEW code to see when it breaks into the debugger. This might reveal what part of your code is causing the flatten to occur (which might make it easier to reproduce the error).

Eric