Calling VI doesn't show correct value of Boolean returned from subVI

[Bob_Schor]

Thanks for the education.  I think, in the future, if I want "Pixie Dust", I'll clean the filters at the back of my PXI chassis and sprinkle that on my code (seems safer, to me), after contacting NI and saying "Help!!".

BS

[Gregory]

I believe JKI released an add-on around 4/1/2015 called the Magic Delay Fairy, which also runs on pixie dust.

[Freelion8]

I have LV 2013 32-bit and LV 2015 32 and 64 bits installed on my machine I saved your code as LV 2013 32 bit version and run it there, it all worked fine, both probes in the subvi and main vi showed true. It looks like something to do with this new 2015 64 bit release. FYI, My operating system is Win7 64 bit.

[Dr_M]

I have now tried Jack Dunaway's solution of modifying the last CLN parameter to get the subVI call working properly.  Why this should ne needed is a complete mystery.

In reply to Rolf's comment "Another remark though: The idea to check if IsWow64Process() is actually present is a nice idea but as done here absolutely useless." I would like to say that the function has worked for me for years under Win XP, 7, 8, and 8.1 32-bit and 64-bit.  The reason I use it is because of the behaviour of the Windows Registry under a 64-bit OS, and the different sets of Program Files and Program Files (x86) folders.  The IsWoW64? check has never been broken, so I'm not quite sure what you're talking about.  It works for me and I use it all the time!  It's part of my easyGIO Tools for NI LabVIEW toolkit that I use in all my projects.

I'll be interested to see what NI deduce is the actual cause of this problem.  I have used many MSDN functions in CLNs and none has ever caused a problem like this, so I suspect it is something introduced in LV2014.  This was the main reason I did not start using LV2014 until earlier this year, and the fact the installer kept crashing.

Thanks for all your help,

Mike

CLD, Alliance Member, UK

[rolfk]

---

@Dr_M wrote:

In reply to Rolf's comment "Another remark though: The idea to check if IsWow64Process() is actually present is a nice idea but as done here absolutely useless." I would like to say that the function has worked for me for years under Win XP, 7, 8, and 8.1 32-bit and 64-bit.  The reason I use it is because of the behaviour of the Windows Registry under a 64-bit OS, and the different sets of Program Files and Program Files (x86) folders.  The IsWoW64? check has never been broken, so I'm not quite sure what you're talking about.  It works for me and I use it all the time!  It's part of my easyGIO Tools for NI LabVIEW toolkit that I use in all my projects.

---

What I mean is that the whole check with LoadLibrary() and GetProcAddress() can be completely removed! If the last CLN which calls the IsWOW64Process() function doesn't cause a broken run arrow in the VI, these two earlier CLNs can under no condition ever return a value that would indicate that this function is NOT available.

In addition, according to MSDN you would have to run this on a VERY, VERY old and LONG AGO unsupported Windows XP SP1 installation that it could possibly be not available. But then the VI will be broken and not runnable.

[Hooovahh]

---

@altenbach wrote:

---

@Bob_Schor wrote:

And I'd never seen, nor heard of, the "Always Copy" function.  

---

You might want to look at this old discussion and the links in the various posts  (e.g. to here).

---

Yeah I came in late, but here the link, where I've previously found reasons for the always copy, and as others have said it is to fix something with the compiler, which usually gets assigned a CAR and fixed in the next release.

https://forums.ni.com/t5/LabVIEW/TDMS-Write-cannot-accept-datatype-what-s-going-on-here-then/m-p/293...

For this reason some have suggest the always copy be replaced with an icon that is a band-aid.

[Bob_Schor]

---

@Hooovahh wrote:

For this reason some have suggest the always copy be replaced with an icon that is a band-aid.

---

I'll vote for that ...

BS

[AristosQueue (NI) · Accepted solution]

This bug is user error. Your settings in the Call Library Node do not match the call signature of the Windows function for "IsWow64Process".

You told LabVIEW this was a "Boolean" terminal. LabVIEW Booleans are a single byte. But the function signature of Windows is Windows-type BOOL, which is 32-bit value. So LabVIEW is allocating a single byte but the DLL node is stomping on 4 bytes, and that is overwriting other information. This misconfiguration could lead to any number of problems with LabVIEW's operation... you're lucky it didn't crash. You need to configure your Call Library Node to use an int32 for that terminal and then compare that int32 using "not equal 0?" function. Make sure you use that specific comparison as the function does not promise to return "1" for True... any non-zero value may be True. 

Both the return value of the DLL node and the input parameter need to be fixed.

So, as I said at the outset, it is a user bug with the Call Library Node.

The CAR will be closed as "not a bug" for LabVIEW.

[Dr_M]

Interesting that it the CLN accepted the parameter as a U8 in  LabVIEW 2013 but not in 2014 and 2015.  I have now changed it to I32 in all versions and appears to work OK.  Thanks.

[JackDunaway]

---

@AristosQueue (NI) wrote:

Your settings in the Call Library Node do not match the call signature of the Windows function for "IsWow64Process".

---

Excellent catch! d'oh

---

@AristosQueue (NI) wrote:

So, as I said at the outset, it is a user bug with the Call Library Node.

The CAR will be closed as "not a bug" for LabVIEW.

---

Hmmmm.... is it possible here that a user bug flushed out a LabVIEW bug? See below...

---

@AristosQueue (NI) wrote:

This bug is user error. Your settings in the Call Library Node do not match the call signature of the Windows function for "IsWow64Process".

You told LabVIEW this was a "Boolean" terminal. LabVIEW Booleans are a single byte. But the function signature of Windows is Windows-type BOOL, which is 32-bit value. So LabVIEW is allocating a single byte but the DLL node is stomping on 4 bytes, and that is overwriting other information. This misconfiguration could lead to any number of problems with LabVIEW's operation... you're lucky it didn't crash. You need to configure your Call Library Node to use an int32 for that terminal and then compare that int32 using "not equal 0?" function. Make sure you use that specific comparison as the function does not promise to return "1" for True... any non-zero value may be True. 

Both the return value of the DLL node and the input parameter need to be fixed.

---

The return value certainly needs to be fixed. If LabVIEW is truly allocating only one byte, making no assumptions about how the LabVIEW Memory Manager aligns additional blocks, I would agree it's surprising that undefined behavior has not yet popped up. Definitely an application bug here.

But here's the more interesting half... the pointer to the Boolean should be OK, yes? Since, LabVIEW would be passing a proper 4-byte pointer location, which LabVIEW would then dereference to copy the first byte at that address into the one byte it has allocated for the parameter. Which, on little-endian Windows, would be 0x01 -- a TRUE in LabVIEW.

And behold -- it is this wire in which we see TRUE while the VI is running, yet is stomped as FALSE once that VI finishes execution.

It's still arguably an application bug here, yet arguably not also. Since, sometimes it's only necessary to inspect/copy a portion of a known block -- it's not explicitly wrong or bad to copy only part of the block. (I would say this specific case is definitely still a semantic bug, but the more general case is not necessarily a bug at all.)

So, was a LabVIEW bug still unintentionally uncovered?? (or is my thinking wrong??)