CVI executables causes Access Violation 0xC0000005 on Windows 10 Anniversary Update.

[jogal]

Created executables always causes Access Violation (exception 0xc0000005) at close time on Windows 10 RS1 (Anniversary Update).

The issue occurs in both LabWindows CVI 2015 and 2015 SP1.

How to reproduce: create simple program and compile with default Release (x86) profile.

e.g:

#include "test.h"
#include <userint.h>
#include <cvirte.h>

int ph;

int __stdcall WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
					   LPSTR lpszCmdLine, int nCmdShow)
{
	if (InitCVIRTE (hInstance, 0, 0) == 0)
		return -1;    /* out of memory */
	
	ph = LoadPanel (0, "test.uir", PANEL);
	DisplayPanel(ph);
	RunUserInterface();
	
	return 0;
}


int CVICALLBACK CallExit (int panel, int control, int event,
						  void *callbackData, int eventData1, int eventData2)
{
	switch (event)
	{
		case EVENT_COMMIT:
			QuitUserInterface(0);
		break;
	}
	return 0;
}

The problem is visible on Control Panel > Reliability History > Error Reporting:

Also return code of executable (exit code) is always 0xc0000005 instead of zero.

To check easy exit code can be called the executable through .bat file:

@echo off
Test.exe
echo ExitCode = %errorlevel%
pause

I have observed that if multiple instances of the same program are running, only crashes when the last instance is closed. It seems that the problem occurs at the time that CVI runtime is released from ram. (The latter is only an assumption)

[Mikel72]

Same Problem here, even on a fresh installed PC (only Windows 10 160715 and CVI2015SP1-Runtime) every executable crashes at the end (in debugger after the last closing bracket of main(), see attached screen shot).

Also tried compiling with an extrenal compiler (Visual Studio), same result.

We need a fast fix for this issue, because our customers PCs will update to anniversery update in a few days.

[Mikel72]

CVI2015 SP1 (August 2016 Release) does not fix the problem. Testet on a fresh installed Windows 10 1607 (on 32 bit and 64 bit version the same problem). Only clean windows and CVI Runtime NILWCVIRTE2015SP1 installed.

[Ian.W]

Interestingly I'm seeing a similar problem even from old apps built in the CVI 2009 / 2010 timeframe - specifically that the apps cause a fault upon exiting after the 1607 update. Those were a different CVI compiler too! I'd guess this must be a long-standing CVI RTE characteristic that has run afoul of the changes brought about by Windows 10.

NI staff: once you have sorted this out it would be great if you could share what you see going on with Windows 10. It seems that Microsoft is on track to continually break things incrementally. Build 1511 had issuses with file associations and now this with 1607. How is NI handling the new uncertainty, and do you have advice for us?

[xj97]

Seeing the same issue at our studio.

If I build with Visual Studio and view disassembly, I see this stack on crash:

01253348() Unknown
[Frames below may be incorrect and/or missing]
[External Code]
cvirte.dll!6855809b() Unknown
cvirte.dll!6855831f() Unknown
> cvirte.dll!687e8fe7() Unknown
[External Code]
XXXX_Debug.exe!exitApplication(int exitCode) Line 10420 C
XXXX_Debug.exe!PanelResponse(int panel, int event, void * callbackData, int eventData1, int eventData2) Line 7176 C

The module load address for cvirte.dll is 0x68420000. The module offset for the first CVI call is (0x687e8fe7 - 0x0x68420000 = 0x3c8fe7). Loading DependencyWalker with cvirte.dll shows:

Function             Entry Point
-------------------  ------------
SetWindowsErrorMode  0x003bdfb0
MinimizeAllWindows   0x003c3590 <---- looks to crash here
WriteLine            0x003d1220

We had a crash that looked just like this under certain circumstances ~4 years ago, on an older version of LabWindows. We just worked around that one by disabling a feature. Not sure how to avoid this one.

-Baker

[Constantin--P · Accepted solution]

Hello,

We did some investigation and saw that the failure is related to some font files located in

c:\Windows\SysWOW64\cvirte\fonts

c:\Windows\System32\cvirte\fonts

Could you try remove these files and see if the crahs still occurs. If not, this would be a workaround if you don't use these fonts.

We keep investigating to see the exact cause

[xj97]

Hello Constantin,

Yes, removing the files stopped the crashing on exit. Restoring the files resumed crashing on exit.

As another data point, yesterday at some point the applications stopped crashing on exit. When I realized this I rebooted the machine to see if the crashing would resume, which it did.

Thanks

Baker

[jogal]

Although it is not a full fix works for me since I do not use these NI fonts.

Thanks!

[Mikel72]

This is not the solution for the problem, it is just a dirty workaround.

I need to build installations with side-by-side runtime, no chance to delete the fonts there.

[jogal]

Knowing that the failure is related to the NI fonts should not be very difficult to locate and fix the issue by NI developers.

Another workaround:

Include a local copy of cvirte directory (without fonts) and cvirte.dll on application install folder. In this case executable will use local runtime instead of C:\Windows\system32 runtime.