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

[Chadwickky]

Thank you for the help! Found the difference. It works as long as there is no code after the SetSystemAttribute. 

RunUserInterface();

SetSystemAttribute(ATTR_TASKBAR_BUTTON_VISIBLE, 0); 

Instead of:

RunUserInterface();

SetSystemAttribute(ATTR_TASKBAR_BUTTON_VISIBLE, 0);

...

Probably standard, but there were some grandfathered things we after RunUserInterface like CloseCVIRTE and memory management stuff. Removing these resolved the issue and provided expected results.

Thanks again for your input and aid!

[RobertoBozzolo]

---

Chadwickky ha scritto:

Thank you for the help! Found the difference. It works as long as there is no code after the SetSystemAttribute. 

RunUserInterface();

SetSystemAttribute(ATTR_TASKBAR_BUTTON_VISIBLE, 0); 

Instead of:

RunUserInterface();

SetSystemAttribute(ATTR_TASKBAR_BUTTON_VISIBLE, 0);

...

Probably standard, but there were some grandfathered things we after RunUserInterface like CloseCVIRTE and memory management stuff. Removing these resolved the issue and provided expected results.

Thanks again for your input and aid!

---

That's a problem! I have lots of calls after RunUserInterface terminates, the same as you have, mainly disposing of dynamically allocated memory and closing system resources (serial port, DAQ devices, spawned threads termination and so on). All this stuff will need to be moved in a function called immediately after or before QuitUserInterface (which I may have in several places in the program, while RunUserInterface is unique).

Till now I have deferred OS update for Anniversary Update release but this is only a temporary solution since new systems will likely have it already installed so solving this problem is crucial: keep us informed of any update.

[carlox]

@Chadwickky: I have a lot of code after the RunUserInterface() call, just like Roberto, and the trick still works perfectly.
So you should investigate what is the specific library function that vanifies the SetSystemAttribute().
This morning I did some test and I have proved on my code that the SetSystemAttribute can be the last statement before the closing bracket of main() function (or the return 0, eventually).

@Roberto: no reason to delay the Anniversary Update, I have all my systems updated to the latest patches and all works ok. The aggressive Microsoft policy for Windows 10 updates dictates you can be "almost" sure that client systems are fully patched, if PCs are connected to internet.

[swilcox303]

After installing the Windows 10 update for December 2016, this behavior no longer occurs on my computer.

[swilcox303]

Yeesh -- one day later and it's back to crashing. Sorry for the false alarm. Who knows...

[Not_johndoe77]

Ha! Good thing I came back the next day and checked your progress... because I updated my Win10... and right off the bat, it didn't work.

However, using the previous hints in this chain, I was able to solve the issue.  After deleting the font folders in:

   c:\Windows\SysWOW64\cvirte\fonts

   c:\Windows\System32\cvirte\fonts

...with no success AND updating Win10 (Dec 13,2016) with no success, I wondered if there were other font files somewhere.   I perused C:\Program Files(x86)... and sure enough, there were two such folders:

   C:\Program Files (x86)\National Instruments\Shared\cvirte\13.0.2.278\fonts
   C:\Program Files (x86)\National Instruments\Shared\cvirte\15.0.1.239\fonts

I moved both of these font folders to the desktop (in case this didn't work and I hosed up CVI Run Time).... violá... she worked!  No error messages when the program exits.  I have tested about 10% of the program's functionality and all appears to work as expected.  Can I get an "Amen!", my brothers and sisters?!

A couple of final notes (in case the above does not help others):

1. Our code contains lots of additional code after the RunUserInterface() call... but we do not use the SetSystemAttribute() anywhere.  This "extra code" mentioned previously may/may not still be an issue for someone.
2. We are using LabWindows 2013, Service Pack 2 (version 13.0.2 (278).
   We had a consultant who was using LW 2015, hence the folder titled "15.0.1.239" in the above mentioned folders.

[WireWeaver]

This issue has been fixed in the LabWindows™/CVI™ 2015 SP1 f1 Runtime Patch.

-Trent

[RobertoBozzolo]

That's good news! 

I just installed it and it works in the first attempts I made. To get rid of this error you only need to patch the run-time engine, both on the development and the target machines. The IDE patch appears not related to this error.

[swilcox303]

I've been lurking here hoping that someone would ask the question how to fix older versions of CVI. I'm running 2013 and didn't see any fix offered beyond this 2015 Service Pack, so in my ignorance, I thought I was out of luck. Among the documentation about the 2015 SP1, there was a vague reference that the fix is backwardly compatible with older programs. So in short, I downloaded the 2015 SP1 and it installed without complaint. AND it fixed the problem for my executables developed with 2013. So that's the answer, at least for CVI 2013: this update works.

I gather from other documentation that it actually installs a new run time engine on my development computer, which I hope will be included in any future run time packages I create and distribute.

[RobertoBozzolo]

It was probably not clear enough, but the 2 patches recently released, one for the RTE and the other for the IDE, are not related.

The RTE patch solves this "Access violation" error, while the IDE patch addresses those that need to distribute CVI2015 applications on WinXP machines.

That is, if you only have to deal with the error described in this discussion, you only need to patch the RTE and be sure to include the newest RTE installer when you create a distribution for a deployment machine.

Installing 2015 patched IDE version is not required for you that develop in 2013. It has fixed your problem just because it installs the newest RTE, but you have overcharged your system installing a product you are not likely to use.