LabVIEW 6i application and Data Execution Prevention

[MrX]

Dear all,

we have an application which is running on several windows platforms. The application is built on LV 6i. Since Microsoft introduced SP1 for Windows Server 2003 we several support requests because the application won't run after installation because of the data execution prevention feature. I guess that it is a runtime problem, because we are distributing several applications and the problem relates to all executables. Could anybody confirm this? Is this issue solved in version 8?

Thanks for helping
MrX

[stefan.henke]

Hi MrX,

LV 6i is released a long time before windows 2003 server was, so there could be problems.LabVIEW is not officially compatible nor is it supported on Windows 2003 Server or Windows 2000 Server Edition. We have not tested LabVIEW on either of these operating systems. We have heard from some customers that LabVIEW will work, for the most part, on these systems. However, they are not supported even if they look like they are working. Supported operating systems can be found in the release notes for LabVIEW or here: http://digital.ni.com/manuals.nsf/websearch/0FB36A66EDEA837A86256E40007051FF?OpenDocument&node=13210...

I am sorry that I cant help out more on that.

Regards,

Stefan Henke
NIG

[rolfk]

---

@MrX wrote:
Dear all,

we have an application which is running on several windows platforms. The application is built on LV 6i. Since Microsoft introduced SP1 for Windows Server 2003 we several support requests because the application won't run after installation because of the data execution prevention feature. I guess that it is a runtime problem, because we are distributing several applications and the problem relates to all executables. Could anybody confirm this? Is this issue solved in version 8?

Thanks for helping
MrX

---

DEP protects the system from code execution in memory segments not explicitedly marked as executable. This is to prevent most common stack overflow attacks, self modifying code as used in viruses and troyans and similar things. As such I do not think LabVIEw is doing anything like this at all. However LabVIEW 6.0 was created with Visual C 6.0 or so and there is a chance that the LabVIEW executable or some sub part of it does have an executable image with segments containing executable code that are not properly marked as executable code segments by the linker. As such it could be actually a Microsoft problem with the Visual C toolchain not being fully DEP compatible.

Another option might be that the LabVIEW compiler itself does do something not entirely DEP compatible when creating binary code.

Also something to possibly investigate although it may cost you more time than it is worth is the possibility that the problem is actually located in some part of the device driver software such as NI-DAQ (quite possible) or NI-488 (less likely) or some third party driver or your own driver software. 

Whatever it is, except for the last possibility, there is absolutely no chance to get anyone to release a fix for this after something like 7 years of the release date of that software and your only options are then to either drop support for those OSes, have the customer configure a DEP exception for your programs, or upgrade to a more recent version of LabVIEW that does not have this problem.

Rolf Kalbermatter

Message Edited by rolfk on 12-18-2006 05:57 PM

[MrX]

Dear Rolf,

Thanks for your reply. I just wanted to make sure that it is not an programming issue (e.g. skipping VI server functionality) which is now confirmed! Guess it's time to upgrade ..

Thx
MrX