NI Home > Community > NI Discussion Forums

BreakPoint

Showing results for 
Search instead for 
Do you mean 
Reply
Proven Zealot
Jeff·Þ·Bohrer
Posts: 7,715

Re: LabVIEW Minutiae (that may bite you someday)

So, a co-weirier and I were looking at the NI-Scope SFP and discussing the code style and completeness of documentation encluding the short-cuts listed in the control discriptions.  Pause (Shift+P) doesn't work :smileysad: so he tried Ctrl+P that did something but didn't Pause..... (the stack of Printouts was amazing  :smileyembarrassed:)

8-Ball Consulting advertising banner

Certified LabVIEW Consultant. The partner you can bank on when you're behind the 8-ball.
Trusted Enthusiast
aeastet
Posts: 2,199

Re: LabVIEW Minutiae (that may bite you someday)


yenknip wrote:

Talking to user32.dll can do cool things to integrate with Windows, like simulate keyboard and mouse commands. When you build an exe, it includes a local copy of user32.dll in the data support directory. The runtime engine checks this directory first, and so calls the wrong version of the dll causing all sorts of errors. 

 

I include the errors I encountered for anyone trying to search for info:

Access violation 0xC0000005

Procedure entry point wcscat_s could not be located in the dynamic link library ntdll.dll

 

To fix, remove the dll from the support directory before running the application. 

I may have missed an option to exclude items in a build, but I made a post-build action to remove the dll from the build directory. 


You can also change the location of the file inside the dll interface. If you hard code it to the system32 folder than it will not add the files to the system folder to start with.

Tim
Johnson Controls
Holland Michigan
Active Participant
Thoric
Posts: 1,477

Re: LabVIEW Minutiae (that may bite you someday)

[ Edited ]

yenknip wrote:

Talking to user32.dll can do cool things to integrate with Windows, like simulate keyboard and mouse commands. When you build an exe, it includes a local copy of user32.dll in the data support directory. The runtime engine checks this directory first, and so calls the wrong version of the dll causing all sorts of errors. 

 

I include the errors I encountered for anyone trying to search for info:

Access violation 0xC0000005

Procedure entry point wcscat_s could not be located in the dynamic link library ntdll.dll

 

To fix, remove the dll from the support directory before running the application. 

I may have missed an option to exclude items in a build, but I made a post-build action to remove the dll from the build directory. 


Similarly, I once had a terrible issue that bemused me for days. I had incorporated "FileVersionInfo.vi" to gather executable version information from the LabVIEW executable (by pointing it to itself) and showing the version details on the splash screen (very useful). This had been working fine for months, then suddenly, following a typical Windows update, my application would pop randomly during execution. No warnings. No errors. Just gone.

 

I spent ages tracking down the problem, and it turned out the application builder was detecting the use of kernel32.dll in the aforementioned VI and including a copy in the "Data" support folder! A big No No! Consequently, although FileVersionInfo.vi still ran without fail, something was not comfortable with the use of two kernel32.dlls and would force my application out of memory at random times.

 

Lesson: When using "FileVersionInfo.vi" always check to see if Application Builder is going to put a copy of a kernel32.dll into your support folder! If it does, manually delete it afterwards.

Thoric (CLA, CLED and LabVIEW Champion)
Active Participant
RobCole
Posts: 573

Re: LabVIEW Minutiae (that may bite you someday)

I just got bit by one. I'm also reporting it as a bug. But it took a few minutes to figure it out, so I'll put it here too.

 

I set up a build using a custom INI file:

Build Screen.jpg

 

Now this is fine (usually), but when I went to build the executable, this is what I got:

Build Error.jpg

 

Yep, no information about why the build did not work.

 

Simple fix once I found it, though. Close the editor (notepad) that had the .ini file open for editing. Then the build worked perfectly.

 

As a bug report - it really should tell us why it failed to build.

 

     Rob

Active Participant
LabBEAN
Posts: 377

Re: LabVIEW Minutiae (that may bite you someday)

"The build was unsuccessful" with Possible Reasons = "" appears to be related to file permissions.  In this thread, folks also solved it by:

 

- Temporarily disabled virus protection (right clicked Norton Internet Security systray icon and selected Disable Antivirus Auto-Protect).

- Pausing Dropbox syncing when building applications solved the issue.

- I use source control and had checked in the compiled .exe making it Write Protected.  Same problem if it is in use.  Close the .exe if it is running.  Remove Write protection.

Active Participant
RobCole
Posts: 573

Re: LabVIEW Minutiae (that may bite you someday)


LabBEAN wrote:

"The build was unsuccessful" with Possible Reasons = "" appears to be related to file permissions.  In this thread, folks also solved it by:

 

- Temporarily disabled virus protection (right clicked Norton Internet Security systray icon and selected Disable Antivirus Auto-Protect).

- Pausing Dropbox syncing when building applications solved the issue.

- I use source control and had checked in the compiled .exe making it Write Protected.  Same problem if it is in use.  Close the .exe if it is running.  Remove Write protection.


I must have to learn how to search better. I typed in "Build Unsuccessful" and got 0 hits.

 

Anyway, there is no anti-virus running right now. No Drop-box and I have everything checked out.

 

If I had the executable running, I got a Possible Reason = access violation. That is what I would expect from this type of problem. It was only when I had the included file open that I got Possible Reasons = "".

 

Well, I got it done and ready to go to the customer.

 

       Rob

Knight of NI
altenbach
Posts: 27,019

Re: LabVIEW Minutiae (that may bite you someday)

[ Edited ]

OK, so I spent all day Friday trying to track down a bug and it turned out that the compiler took some unanticipated liberties. Of course this code is part of a big project, and of course I suspected little bugs anywhere else in the code.

 

As a quick refresher, floating point calculations have certain limitations and the result might depend on the order of execution. Here is an illustrative example.

 

 

As you can see, the results sometimes differ depending on the order in which the compound node is wired, even though from a mathematical standpoint the results should be identical. So far, so good. We know that!

 

In my particular case, the result was part of a key used in an associative memory implementation, and I got lookup failures even though the entry should have existed. Interesting was the fact that I generated the data in two different subVIs with identical code (see image below, one generated the cache entry and the other tried to retrieve it), yet I still got lookup failures. The failure frequency was much lower than in the example above but 100% reproducible. I go failures for very few Ns, e.g. N=20, 24, 30, 32 and not much in-between. I never had that problem in nearly identical code in the past, so expanding the program elsewhere must have triggered this reordering as part of the compiler optimization. (LabVIEW 2011SP1). Maybe it was a change in debugging or inlining settings. Just guessing here. I did way too many modifications to really tell when it started and most of the time I typically tested up to 16 where the problem does not show up.

 

 

 

 

Well, the solution was to eliminate the duplicate code and place the array generation in a shared subVI. Immediately, all problems disappeared. :smileyvery-happy: (Note that for performance, the array is stored in a feedback node because N rarely changes and the cached value can be used most of the time).

 

The take home message is that even if the ordering of operations is the same on the diagram, there is still no guarantee that the results will be binary indentical due to potential reordering in the compiled code.

 

Good to know!


LabVIEW Champion . Do more with less code and in less time .

Proven Zealot
Jeff·Þ·Bohrer
Posts: 7,715

Re: LabVIEW Minutiae (that may bite you someday)

Another case where the mantra "Code it once!"  solves the problem! Thanks for sharing!

8-Ball Consulting advertising banner

Certified LabVIEW Consultant. The partner you can bank on when you're behind the 8-ball.
Active Participant
RobCole
Posts: 573

Re: LabVIEW Minutiae (that may bite you someday)

We have an instrument that uses numbers for its commands. I created a type def text ring with non-sequential numbers to allow the user to select the command they wish to send.

 

Non-Sequential Text Ring.png

 

Simple enough. Except that I made it a type def.  Used as a type def, the returned values are sequential (0, 1, 2, ...).

Making it a Strict Type Def solves the problem and returns the correct values.

 

Rob

Proven Zealot
Jeff·Þ·Bohrer
Posts: 7,715
0 Kudos

Re: LabVIEW Minutiae (that may bite you someday)

[ Edited ]

Thank You Rob!

 

those dratted diferences betweeen "Type-def" and "Strict type-def" deserve a nugget!

 

I often get confused myself!

 

Thanks again.

8-Ball Consulting advertising banner

Certified LabVIEW Consultant. The partner you can bank on when you're behind the 8-ball.