LV 2012 compatibility bugs with Windows XP

[MinerHokieRamp]

We're using LV 2012 SP1 Full Development System on a PC with XP Pro 2002 SP3.

Often, after I'm finished using LV and close all the VI's, the LV application tab in the Windows taskbar can't be expanded and it can't be removed. So, I use the task bar manager to quit LV.

Also, LV occasionally locks up while running my VI's.

Are these known issues with LV2012/XP ?    If so, have fixes been released?

Thanks,

Jeff

[rolfk]

Not really!

But a possible indicator that your LabVIEW code uses VIs with Call Library Nodes that have trouble. This can be a wrong configuration of the Call Library Node, a bug in the underlaying DLL which causes memory to be overwritten which it shouldn't or the most likely cause if it is related to Call Library Nodes a call to a function that wants to write some information in a buffer passed to the function as parameter but your LabVIEW VI fails to allocate a (large enough) buffer for the function to write its information into.

This while destroying memory it should not, often doesn't need to cause immediate problems. But it has damaged the integrity of the LabVIEW process memory and at some point LabVIEW will run into a problem when trying to access the information that was destroyed. That can be a crash at exit of LabVIEW due to illegal pointers it tries to properly clean up, or a hang if your corruption happens to be related to a synchronization object used to wait for a system kernel driver to report back success of for instance the driver cleanup call.

[Sam_Sharp]

Even on Win 7 64-bit with LabVIEW 2013, I very occasionally get issues where I have closed all of my VIs/projects but the getting started window doesn't reappear and it's stuck in the taskbar.

[rolfk]

---

@Sam_Sharp wrote:

Even on Win 7 64-bit with LabVIEW 2013, I very occasionally get issues where I have closed all of my VIs/projects but the getting started window doesn't reappear and it's stuck in the taskbar.

---

I do get that on my development PC occasionally with some LabVIEW versions but not others but that is with all LabVIEW versions since 5.1 installed and a pretty chaotic mix of various device drivers. On a clean computer install with only one or two LabVIEW version (always from older to newer and never try to install older Toolkits after having installed a never version of it) and one device driver set, even when cleanly updated to newer device driver versions, I never have seen this issue.

[MinerHokieRamp]

---

@rolfk wrote:

Not really!

But a possible indicator that your LabVIEW code uses VIs with Call Library Nodes that have trouble. This can be a wrong configuration of the Call Library Node, a bug in the underlaying DLL which causes memory to be overwritten which it shouldn't or the most likely cause if it is related to Call Library Nodes a call to a function that wants to write some information in a buffer passed to the function as parameter but your LabVIEW VI fails to allocate a (large enough) buffer for the function to write its information into.

This while destroying memory it should not, often doesn't need to cause immediate problems. But it has damaged the integrity of the LabVIEW process memory and at some point LabVIEW will run into a problem when trying to access the information that was destroyed. That can be a crash at exit of LabVIEW due to illegal pointers it tries to properly clean up, or a hang if your corruption happens to be related to a synchronization object used to wait for a system kernel driver to report back success of for instance the driver cleanup call.

---

No CLFNs in this code. I know what you mean: In another project, I had to change 'call type' for some CLFNs because of the 2009 -> 2010 boundary.

Thanks,

[Bob_Schor]

According to this chart, LabVIEW 2012 SP1 (but not LabVIEW 2012) is compatible with the latest (SP3) release of Windows XP.

Bob Schor

[aflojo]

I found a reported issue on our LabVIEW 2012 and 2012 SP1 Known Issues page that sounds similar to what you’re experiencing. You can find it at the link below under number 358049:

https://www.ni.com/en/support/documentation/bugs/12/archived--labview-2012-and-2012-sp1-known-issues...

There’s a work around listed and they said it is resolved in LabVIEW 2013.

Hope this helps.

[MinerHokieRamp]

---

@aflojo wrote:

I found a reported issue on our LabVIEW 2012 and 2012 SP1 Known Issues page that sounds similar to what you’re experiencing. You can find it at the link below under number 358049:

https://www.ni.com/en/support/documentation/bugs/12/archived--labview-2012-and-2012-sp1-known-issues...

There’s a work around listed and they said it is resolved in LabVIEW 2013.

Hope this helps.

---

Sorry I haven't replied until now. This definitely sounds promising. I sent your link, and the link to this thread, to a co-worker who is having the same issue. We haven't had time to review all our VIs for those VI Properties settings.

I'll check all my VIs Monday morning, change them as required, and if the problem doesn't occur after a full day of work, I'll consider it the solution. Either way, I'll update this thread with the results.

Thanks,

[MinerHokieRamp]

---

@MinerHokieRamp wrote:

---

@aflojo wrote:

I found a reported issue on our LabVIEW 2012 and 2012 SP1 Known Issues page that sounds similar to what you’re experiencing. You can find it at the link below under number 358049:

https://www.ni.com/en/support/documentation/bugs/12/archived--labview-2012-and-2012-sp1-known-issues...

There’s a work around listed and they said it is resolved in LabVIEW 2013.

Hope this helps.

---

Sorry I haven't replied until now. This definitely sounds promising. I sent your link, and the link to this thread, to a co-worker who is having the same issue. We haven't had time to review all our VIs for those VI Properties settings.

I'll check all my VIs Monday morning, change them as required, and if the problem doesn't occur after a full day of work, I'll consider it the solution. Either way, I'll update this thread with the results.

Thanks,

---

I looked at VI Properties settings for all the VIs today. None of them were set to "Open front panel on load" and one was set to "Run when opened". I deselected "Run when opened" in that VI and ran through a few test cases. When I closed all the VIs, LabVIEW remained in the taskbar. I searched at the link (you provided) for other mentions of "remains in the taskbar" and found nothing. I'll continue to search on ni.com.

Thanks,

[Kyle97330]

Do you ever call any of your subVIs using the "Start Asynchronous Call" function?

I've had issues stopping LV when running those VIs and they don't stop properly.