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

[Ian.W]

I'm trying to figure out the take-away from this thread, as it relates to development and target machines.

I can delete those fonts on my development PC, but under what scenarios might a target PC run into this issue, and how can I avoid it?

[xj97]

Hi Ian-

It seems like we have several options:

 1. Ship with a copy of the runtimes in our application directory (minus the fonts). This could work but is inelegant, and would mean any common runtime upgrades at that point would not apply to this installation.

 2. Ship with something that can scrub the fonts from the windows directory. This is unacceptable, for us anyway, as it is assuming the user has no other CVI applications that use those fonts, and if they did we'd be breaking another app.

I don't like either option. And option 1 doesn't fix our applications already out in the wild.

I am crossing my fingers for a run-time update soon, as every application we've shipped in the last decade or so will now be crashing on exit.

-Baker

[Ian.W]

Under what circumstances do those problematic fonts get placed into c:\Windows\SysWOW64\cvirte\fonts and c:\Windows\System32\cvirte\fonts ?

• Target machine installation of RTE only?
• Distribution kit installs RTE in default location?
• Distribution kit installs RTE in application directory?
• other scenarios(?)
• Does it depend which version of CVI / RTE is used?

Defining these details is necessary for developers to anticipate and to manage the problem.

[carlox]

On my development machine this bug occurs only when I have NOT running CVI IDE, and it happens for debug and release executables.

Removing only ni7seg.ttf font from SysWOW64\cvirte\fonts cured the problem. 

nisystem.ttf appears to be unrelated to this bug.

Windows 10 Pro / 1607 / build 14393.187 / x64
LabWindows/CVI 2015SP1 15.0.1 (239)

[drwint]

This problem just started for me after Windows 10 updated itself today, and removing the fonts does seem to fix it. Thanks for the suggestion.

[carlox]

I correct myself. On another attempt I had to remove BOTH fonts to avoid the problem. I don't know why it worked with only one font removed. 

[gimpax]

The solution of removing both fonts works fine, but as a different workaround without removing any files just add the following line code soon after the RunUserInterface(), that means as soon as the application is going to be quit:

RunUserInterface();

SetSystemAttribute(ATTR_TASKBAR_BUTTON_VISIBLE, 0); 

...

Cheers

[Chadwickky]

---

@gimpax wrote:

The solution of removing both fonts works fine, but as a different workaround without removing any files just add the following line code soon after the RunUserInterface(), that means as soon as the application is going to be quit:

RunUserInterface();

SetSystemAttribute(ATTR_TASKBAR_BUTTON_VISIBLE, 0); 

...

Cheers

---

This does not appear to solve the issue for us, can anyone else provide feedback on this method? Removing the fonts does solve the issue for us. However, we do not believe removing said fonts/files on so many deployed installations is practical or wise. Hoping for yet another alternative.

[carlox]

Chaddwickky, adding

SetSystemAttribute(ATTR_TASKBAR_BUTTON_VISIBLE, 0); 

after RunUserInterface(), so it's executed when the program terminates, solves the problem for all my programs.  

I think it will fixed in next service pack: after all, it's only a cosmetic issue.
It's ugly and confusing for the user, but it does not ruins the functionality of the program.

[Chadwickky]

Thank you Carlo!

We did try that. I'm rather surprised it didn't work. We will revisit it again given we have confirmation that others have replicated the fix with success. I was looking for any indication that the SetSystemAttribute method was a selectively applicable fix. Will post with any updates as discovered. Thank you for the time.