Build application still fails with error 1 in LV12

[shb]

Error messages with almost no useful information.

So please still vote for Better error descriptions for Application Builder

(At the 2nd try the build has worked at least. No modifications were done. No idea what is responsible for the invalid input to EndUpdateResouceA.vi, but it is for sure not me.)

Error message

Possible reasons:

An error has occurred. Expand the Details section for more information.

Details:

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:

Error 1 occurred at EndUpdateResourceA.vi

Possible reason(s):

LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller-In-Charge.

Complete call chain:
EndUpdateResourceA.vi
Write Icons to Application.vi
AB_Engine_EXE_Call_Write_Icons.vi
AB_EXE.lvclass:Build.vi
AB_Engine_Build.vi
AB_Build_Invoke.vi
AB_Build_Invoke.vi.ProxyCaller

[Norbert_B]

Hi,

while i do concur that error messages from the application builder could be better, there are many sources for fails.

I just list some of the most promiment, maybe you can figure out that one of those happened in your system:

- Tried to build the application in protected folders

- Tried to copy support files which where already in the correct folder and locked by the OS (e.g. DLL in use)

- Source files are incomplete

- Memory issues (the build process requires quite some memory)

- VIs being in a wrong LV version

- VIs are not executable because of missing dependencies

Those are the foremost coming into mind in about a minute....

Norbert

[Mr._Jim]

Ugh. This just happened to me again with the exact same message shb posted.  Good ol' EndUpdateResourceA.vi strikes again.

After about five times it finally compiled, but not until various combinations of:

1. Mass compiling the entire application directory
2. Closing LabVIEW and reopening it

If anyone else runs into this, try these steps.  It happens to me about once a month on various projects.  After repeating these actions a few times, it usually clears up the mysterious build issues, but I wish I knew why.

Because this is a 1000+ vi application with lots of bells and whistles, it takes a good 3-5 minutes to compile, and the error always shows up all the way at the end of the build.

shb, that Idea Exchange post certainly has my vote. 

[shb]

The error re-occurs from time to time.

It occurred to me at least on 2013-01-29 and yesterday more than three times. (Most time only once, but sometimes several times until a passed build.)

The VI that raises the error is in <vi.lib>\Platform\icon.llb\EndUpdateResourceA.vi

I have tested if really this VI raises the error. Because the error raised in this VI is merged before error in (see in snipped below), an error could have happened before which is hidden by error 1.

I have set up some hooks to see if the error happens before or after the VI. (The VI was opened by the pre-build hook.) Error in is no error. 

More details will follow soon.

[shb]

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

[Mr._Jim]

Nice job, shb!

[shb]

Yesterday I got windows error 5, meaning access denied. It looks similar to LabVIEW error 8, File permission error.

This should probably be handled similar as windows error 110.

[billko]

---

@shb wrote:

The error re-occurs from time to time.

It occurred to me at least on 2013-01-29 and yesterday more than three times. (Most time only once, but sometimes several times until a passed build.)

The VI that raises the error is in <vi.lib>\Platform\icon.llb\EndUpdateResourceA.vi

I have tested if really this VI raises the error. Because the error raised in this VI is merged before error in (see in snipped below), an error could have happened before which is hidden by error 1.

I have set up some hooks to see if the error happens before or after the VI. (The VI was opened by the pre-build hook.) Error in is no error. 

More details will follow soon.

---

And here I thought *I* was the only one who fell for the "error merge order" trap.  Seems like it can even bite the LV developers.  😉

[Hooovahh]

---

@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

---

So I can't be sure but I think you fixed my issue with this.  I tried building and once every 10 times or so it would work but the other 9 I got the error you described.  I then tried building with your modified VI and I was able to build two times in a row.

[shb]

For me it looks like the loop must be done in the calling VI (Write Icons to Application.vi). When doing the loop as shown in the snipped I got windows error 6 at the 2nd try. This error means that the handle was invalid. It looks like the handle is closed even on a failing call of EndUpdateResourceA().