Build application still " " with error 1 in LV12

[zou]

Success on the 4th try.

[zou]

Run into the problem today.  No executable created.

LabVIEW 2013 SP1 (13.0.1f2) 32 bit, on Win7 64 bit.

Success on the 4th try.

[shb]

How a fix to this problem could look is explained above: add a for loop in vi.lib/Platform/icon.llb/Write Icons to Application.vi:

Please NI, give it a try.

Workaround until then: Every user running into this problem can modify the VI himself.

And NI, do not forget to to fix the error handling in EndUpdateResourceA.vi. (Wrong merge order, marked in image with red arrow. Details are somewhere above in the thread.)

[rolfk]

---

@shb wrote:

I have modified EndUpdateResourceA.vi to call getLastError when the dll call returns zero. (This is recommended in the help of microsoft for EndUpdateResouce. This is the function called by the dll call.) The returned error code is 110, which means that the system can not open the file. (The file is referenced by hUpdate.) (Message found by calling FormatMessageA in kernel32.dll.) This is similar to LabVIEW Error code 8.

My recommendated changes to EndUpdateResource.vi:

• Swap the error inputs of merge error. Like it is now an error which occurred before could be hidden.
• For getting the windows error call getLastError when the dll call returns 0. (In case windows error is 0 raise an error as fallback.)
• When the windows error number is unknown, call FormatMessageA for getting the error message for showing to the user (VI appended)
• When the windows error number is 110 then
• the error could be replaced with LabVIEW error 8 (not done in snippet)
• maybe trying to write the resource could be repeated several times (not clear from MSDN documentation)
• when repeating works, the resource should probably be discarded in an error event (fDiscard=1, not done in the snippet)
• when repeating does not work here, repeating could be done in the calling VI (Write Icons to Application.vi)

The BD of the VI would look similar to this:

Greetings,

shb

---

As I explained elsewhere use of GetLastError() is not very accurate here. Windows maintains a LastError status per thread. But LabVIEW being multithreading can throw a wrench in there since the previous API call and the GetLastError() call can and often will be executed in different threads. All execution systems in LabVIEW get normally assigned at least 8 threads and more if you have a multicore monster of a CPU.

Changing the Call Library Nodes to execute in the UI thread makes sure they will execute in the same thread, BUT LabVIEW executes all kind of things in that thread including updating the UI of its panels as well as the main application message loop that every Windows application needs and needs to run always in the same thread and those calls call into many Windows API functions which will change the LastError status too. So there is a good chance that LabVIEW will execute UI and other Windows API calls which modify the LastError status between your API call and the GetLastError() call, destroying your meaningful LastError value.

Putting both API calls in a VI with subroutine priority is the only way to solve this in a way that makes the GetLastError() call meaningful. Set the CLN to execute in any thread and the VI settings to execute in the caller thread and you should be fine. Another solution is to write an external shared library that combines these two functions (and possibly more) in a function and call that new function from a Call Library Node.

As to what the error causes: Your well beloved Virus scanner is most likely finding it übersuspicious that suddenly there is an exe file appearing on the harddisk. And unlike with Visual Studio it has no knowledge about LabVIEW being a legitimate application builder environment.

[tleisner]

I am using LV14 32bit and recently ran into the "Error 1 EndUpdateResourceA.vi" when building executables. As rolfk suggested, I was able to solve this issue by adding "labview.exe" to the list of exemptions in my McAfee Endpoint Security program. I don´t know why this issue popped up only recently, maybe my employer has changed some virus scanning policies. Maybe this report can help some of you too.

best, Tom

[jamiva]

---

@tleisner wrote:

I am using LV14 32bit and recently ran into the "Error 1 EndUpdateResourceA.vi" when building executables. As rolfk suggested, I was able to solve this issue by adding "labview.exe" to the list of exemptions in my McAfee Endpoint Security program. I don´t know why this issue popped up only recently, maybe my employer has changed some virus scanning policies. Maybe this report can help some of you too.

best, Tom

---

My problem is slightly different. I'm not getting the same error messages as you all, but... building ANY executable was hit or miss. Sometimes, it would create an executable on the first try. Most times it would take two or more attempts.

This has been an ongoing issue with me for years (from at least LabVIEW 2014 to 2017sp1 on Windows 7). My previous searches came up with this [BUG] Application Builder fails if the target window is open. Closing the folder really didn't help other than it was a 100% fail rate with the folder open.

My workstation has McAfee and I added "labview.exe" to the exemptions list. I tried compiling several executables (>10) so far WITHOUT any errors on the first try!! That solved my problem. Wish I could give you all multiple Kudos for that suggestion.

[Steve_Block]

What delays if any need to be added to Write Icons to Application.vi to make it work?

[rolfk]

I would guess that if your virus scanner is the issue, just about any reasonable delay could possibly be still not enough. It's definitely trying to solve the problem at the wrong end and with the wrong method. Adding random delays to any software to fix runtime errors is at best a terrible hack but usually a disaster waiting to happen somewhere in the future.

[Steve_Block]

I should have phrased the question to ask what the code needs to wait for and how to poll when it is ready to proceed.