LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Build application still fails with error 1 in LV12

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

 

Message 1 of 19
(11,523 Views)

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

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 2 of 19
(11,515 Views)

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.  Smiley Wink

Message 3 of 19
(11,435 Views)

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.

Code of EndUpdateResourceA.vi

 

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.

Message 4 of 19
(11,351 Views)

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:

EndUpdateResourceA_modified_BD.png

 

Greetings,

shb

Message 5 of 19
(11,346 Views)

Nice job, shb!

0 Kudos
Message 6 of 19
(11,329 Views)

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.

0 Kudos
Message 7 of 19
(11,275 Views)

@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.

Code of EndUpdateResourceA.vi

 

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.  😉

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 19
(11,265 Views)

@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:

EndUpdateResourceA_modified_BD.png

 

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.

0 Kudos
Message 9 of 19
(11,124 Views)

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(). 

0 Kudos
Message 10 of 19
(11,087 Views)