Showing results for 
Search instead for 
Did you mean: 

LabVIEW crashes with access violation


My LabVIEW suddenly started poping up the crash window with Access Violation.

Even uninstall-reinstall activity didn't work to remove such crash.

Capture_LabVIEW crash.JPG 

Seeing lvlog.txt, it seems that there should be an error in NI report generationtool kit (

I wonder anyone can help me to resolve this crash.


#Date: Tue, Apr 30, 2019 4:05:48 PM
#OSName: Windows 7 Enterprise Service Pack 1
#OSVers: 6.1
#OSBuild: 7601
#AppName: LabVIEW
#Version: 17.0f2 32-bit
#AppKind: FDS
#AppModDate: 8/16/2017 02:33 GMT
#LabVIEW Base Address: 0x00250000

InitExecSystem() call to GetCurrProcessNumProcessors() reports: 4 processors
InitExecSystem() call to GetNumProcessors()            reports: 4 processors
InitExecSystem()                                      will use: 4 processors
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3639452788.24136305, (16:06:28.241363049 2019:04:30)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3639452788.24136305, (16:06:28.241363049 2019:04:30)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3639452788.24136305, (16:06:28.241363049 2019:04:30)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3639452788.24136305, (16:06:28.241363049 2019:04:30)]

4/30/2019 4:07:31.549 PM
Crash 0x00000000: Crash caught by NIER
File Unknown(0) : Crash 0x00000000: Crash caught by NIER
minidump id: b286807b-d9d2-43cd-8aca-fe2cfd79799a
ExceptionCode: 0xC0000005

0x6D73161F - nierInterface <unknown> + 0
0x6D7363C5 - nierInterface <unknown> + 0
0x6D735773 - nierInterface <unknown> + 0
0x753C03CF - kernel32 <unknown> + 0
0x778350E7 - ntdll <unknown> + 0
0x777F97D5 - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0
*** Dumping Bread Crumb Stack ***
*** LabVIEW Base Address: 0x00250000 ***
#** prop types: "C:\Program Files (x86)\National Instruments\LabVIEW 2017\vi.lib\addons\_office\_exclsub.llb\"
GoDoit: VI "" (C:\Program Files (x86)\National Instruments\LabVIEW 2017\vi.lib\addons\_office\_exclsub.llb\, HeapClass "FPHP", Act 50,
GoDoit: VI "" (C:\Program Files (x86)\National Instruments\LabVIEW 2017\vi.lib\addons\_office\_exclsub.llb\, HeapClass "FPHP", Act 50,
*** End Dump ***



0 Kudos
Message 1 of 11

Difficult to say what's the problem. I'm attaching the (apparently) offending vi file. Maybe restoring it may help.

Also, try resetting (rename or delete) the LabVIEW ini file.


LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 2 of 11

Hi pincpanter,

Thank you for the file. But the crash window still pops up even though vi file is restored and LabVIEW.ini file was deleted.

Other excel related vi files can be open, but when I tried to open, the crash window appears. Are there any potential conflicts between LabVIEW and office? (I'm using office 365 proplus...)

0 Kudos
Message 3 of 11

Hi Gino,


Have you tried to run it on another PC?

You may try to refer to these two links to overcome this problem;

0 Kudos
Message 4 of 11

I have followed the first case (uninstall & re-install) several times, but it has the same problem. Since PC is a company owned laptop, I can't even run as a admistrator. (I didn't have such problem before withouth authority though...)


And I am not familiar how to change the path in the second link: 


To mitigate this behavior, you might need to change the file path to the DLL or ActiveX object you are calling.

 For example, if you're calling User32.dll, the file path will normally be:


This must be manually changed to:


Using %windir% directory constant allows the DLLs and ActiveX objects to be accessed when running the application as an executable, as well as when running within the LabVIEW Development Environment.




0 Kudos
Message 5 of 11

I am experiencing this exact crash behavior.  Same offending vi:


C:\Program Files\National Instruments\LabVIEW 2018\vi.lib\addons\_office\_exclsub.llb\


I discovered this when opening a VI developed on my previous PC.  It still opens just fine there.  Windows 7 with Microsoft Office Professional Plus 2016.


My new PC has Windows 10, Microsoft Office Professional Plus 2019.  I'm using LabVIEW 2018 64-bit and it crashes when it tries to open the VI mentioned above on my new machine but not on the previous.


Anyone find any solutions to this issue?

0 Kudos
Message 6 of 11

After just posting, it appears that I may have solved my issue by updating my installation of MS office.  No more crashing.

0 Kudos
Message 7 of 11

I'm getting the exact same crash as Gino has reported, when opening a VI using the Excel add-in. The VI last opened OK for me 2019-06-27, I assume an office update has been rolled out since.


The crash happens whenever I open a VI using some of the Excel report generation add ins or when I try to open "" directly.


My operating system and LabVIEW versions are different to Gino's and jjbloomfield's. I'm using:

#OSName: Windows 10 Enterprise
#OSVers: 10.0
#OSBuild: 16299
#AppName: LabVIEW
#Version: 17.0.1f3 32-bit



Microsoft(r) Excel(r) for Office 365 MSO (16.011328.20362) 32-bit


I'm completely stuck on how to continue supporting the development of several legacy manufacturing test program that heavily uses the Excel add in (but doesn't actually directly call "".), we have a corporate policy on the Excel version used and can't ourselves update Office.


One of my colleagues have a laptop with same LabVIEW version but Win7 64-bit which means his Excel version is behind:

Excel Version 1808 (Build 10730.20344)

"" opens fine on that machine, but copying his vi to my machine makes no difference.


In addition to above "Excel Format" also causes a crash when I close my project.



Found another colleague with same version of OS, LabVIEW and Excel.

Win 10 Enterprise

LabVIEW 17.0.1f3 32-bit

Microsoft(r) Excel(r) for Office 365 MSO (16.011328.20362) 32-bit


"" opens fine on that machine, have opened a service request to try to get some more support.



0 Kudos
Message 8 of 11

Microsoft have changed the .net/dll calls to the office programs between versions. On some computers i've had to open these VI's to update/correct the function calls, i assume this could cause such issues. As you mention, updating Office can also solve it, which further strengthen this idea.


G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
0 Kudos
Message 9 of 11

Thanks Yamaeda,

I have also had to relink dll calls several times with different office versions, however that's of course only possible if I can open the VI first.


I continued with the normal troubleshooting, e.g. uninstall/reinstall Report generation tool kit and LabVIEW, copying files from colleagues installations that worked etc. with no luck.


As mentioned we don't have IS permissions to update our Office installations, however I discovered I had permissions to do a "Quick Repair" of my "Microsoft Office 365 ProPlus" install (Apps & Features -> Modify -> Quick repair).


After repair was completed I can now open "", and the test program using the Excel report generation add-in can successfully create report spreadsheet.

Message 10 of 11