Access violation (0xC0000005) at EIP=0x00B1BA26

[Aero_Eng]

Hello,

We created a test program with Labwindows/CVI. After build, I connected the PXI to the Percussion 7740 laptop, using a standard thunderbolt cable from BestBuy and the PXIe8301 module. I can open the program, but when I run it to collect data, I get this error:

Could this at all be related to the LabView license expiring? 

Any help will be much appreciated. I've search online and through NI documents with no luck. Reinstalled and updated drivers several times as well.

Report file:

####
#Date: Tue, Nov 16, 2021 7:56:45 AM
#OSName: Windows 10 Enterprise
#OSVers: 6.2
#OSBuild: 9200
#AppName: AETS_Front_End
#Version: 21.0 32-bit
#AppKind: AppLib
#AppModDate:
#LabVIEW Base Address: 0x5C9E0000

InitExecSystem() call to GetCurrProcessNumProcessors() reports: 12 processors
InitExecSystem() call to GetNumProcessors() reports: 12 processors
InitExecSystem() will use: 12 processors
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3719912207.82422400, (07:56:47.824223996 2021:11:16)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3719912207.82422400, (07:56:47.824223996 2021:11:16)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3719912207.82422400, (07:56:47.824223996 2021:11:16)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3719912207.82422400, (07:56:47.824223996 2021:11:16)]
starting LabVIEW Execution System 2 Thread 4 , capacity: 24 at [3719912207.82422400, (07:56:47.824223996 2021:11:16)]
starting LabVIEW Execution System 2 Thread 5 , capacity: 24 at [3719912207.82422400, (07:56:47.824223996 2021:11:16)]
starting LabVIEW Execution System 2 Thread 6 , capacity: 24 at [3719912207.82422400, (07:56:47.824223996 2021:11:16)]
starting LabVIEW Execution System 2 Thread 7 , capacity: 24 at [3719912207.82422400, (07:56:47.824223996 2021:11:16)]
starting LabVIEW Execution System 2 Thread 8 , capacity: 24 at [3719912207.82422400, (07:56:47.824223996 2021:11:16)]
starting LabVIEW Execution System 2 Thread 9 , capacity: 24 at [3719912207.82422400, (07:56:47.824223996 2021:11:16)]
starting LabVIEW Execution System 2 Thread 10 , capacity: 24 at [3719912207.82422400, (07:56:47.824223996 2021:11:16)]
starting LabVIEW Execution System 2 Thread 11 , capacity: 24 at [3719912207.82422400, (07:56:47.824223996 2021:11:16)]

<DEBUG_OUTPUT>
11/16/2021 7:56:53.906 AM
Crash 0x00000000: Crash caught by NIER
File Unknown(0) : Crash 0x00000000: Crash caught by NIER
[ExecSys:none]minidump id: 4615cdc0-eafc-4322-972a-53b385c18cb7

ExceptionCode: 0xC0000005
</DEBUG_OUTPUT>

0x7391161F - nierInterface <unknown> + 0
0x739164E4 - nierInterface <unknown> + 0
0x73915863 - nierInterface <unknown> + 0
0x7C37FDB4 - MSVCR71 <unknown> + 0
0x770D4D07 - ntdll <unknown> + 0
0x770975C4 - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0

[billko]

No.  Whatever you are running bombed in a way that Windows had to step in and terminate the program to preserve memory integrity.  Not sure of the specifics.  Hopefully someone here can decode the specifics of what happened here.

[Aero_Eng]

Cool. Thank you very much. That knocks out at least one path 😁

[rolfk · Accepted solution]

It's a bit confusing. First you talk about LabWindows/CVI, then it's suddenly a LabVIEW license problem and your crash log clearly says LabVIEW too.

Whatever it is it can't be directly a LabVIEW license problem. Built executables do not require an active LabVIEW license to run (but might need other licenses such as for the Image Acquistion Software if your application uses that).

However, Thunderbolt can be a can of worms that might very well be at the base of this problem. The idea behind Thunderbolt was nice, the execution a little less and some of the players in the market are outright bunglers and botchers, selling products that simply don't work reliable. And in the case of Thunderbold even the cable itself can be the cause of very nasty problems if not done right, but bad device drivers are also quite normal. A Thunderbolt cable from BestBuy doesn't really spell reliability to me.

The crash report does not really give much information: The crash seems to occur in the ntdll.dll, which is basically the core of Windows. As such the real cause can be pretty much anywhere, including device drivers.

[Aero_Eng]

Yeah, my apologies for the confusion. We wrote the program using Labwindows, but you're right, that does not seem to be related at all to the problem, more just useless background information now that I think about it.

ok, yes. That was another thought. We have had issues before with different cables. It really is the only thing that changed between the time the program was working to now. Guess I should have assumed the cable first.

thank you very much for your response!

[Aero_Eng · Accepted solution]

Just wanted to say thanks! I guess it was the cable. Changed out for a new cable and everything is working.