LabVIEW
Extreme increase in memory and not booting
Solved!
Hello
I have been working with Labview for years and I have never encountered this problem.
I installed Labview(2011 32bit) on a Lenovo(G50) laptop. (with Windows OS 7 and also 10 with 10GB RAM).
The installation was done without any problems. But Labview does not boot and it shows in the task manager that more than 3 GB of memory is occupied by Labview!
Finally, after a few minutes, Labview will exit the task list without any message.
I even reinstalled Windows and verified that .NET 3.5 was installed correctly.
Thank you for your guidance.
LabVIEW 2011 is not officially supported on windows 10, but 7 should work. Do you run any unusual av/security software?
There are many G50 versions. Which CPU do you have?
Thanks for your reply
The configuration of the PC is in the picture below.
No security software is installed on the system.
The problem started here when I first installed the Labview program that I had set up on this computer and it did not load (with Windows 7).
In this project, I used Data Connectivity and Imaq Vision, which were previously installed on many other computers and had no problems. To make sure the program is correct, I tried to install Labview; I noticed that it does not boot either.
Then I installed Windows 10, and without adding any other programs, I just installed Labview; The problem repeated itself exactly as before.
I am sure the problem is related to this computer. Is it possible that the processor (base64 bit) does not match with Labview 32bit?
LabVIEW 32-bit doesn't have an incompatibility with 64-bit CPUs generally but this seems a somewhat special AMD CPU. Although not a high number of cores and neither a member of the Zen family it seems, there is indeed a distinct possibility that some part in LabVIEW tying to detect the type of CPU the system is running on might stumble over a specialty or bug in it that it is not prepared to deal with.
The fact that the CPU itself is from 2014 of course makes it totally impossible that LabVIEW 2011 could even know about any specialty it may have. There is a good chance that later versions of LabVIEW might have learned to deal with this CPU too, but I would not try with 2014 or 2015. It takes some time to discover such incompatibilities and more time to debug it and finally implement a fix.
@rolfk wrote:
LabVIEW 32-bit doesn't have an incompatibility with 64-bit CPUs generally but this seems a somewhat special AMD CPU. Although not a high number of cores and neither a member of the Zen family it seems, there is indeed a distinct possibility that some part in LabVIEW tying to detect the type of CPU the system is running on might stumble over a specialty or bug in it that it is not prepared to deal with.
The fact that the CPU itself is from 2014 of course makes it totally impossible that LabVIEW 2011 could even know about any specialty it may have. There is a good chance that later versions of LabVIEW might have learned to deal with this CPU too, but I would not try with 2014 or 2015. It takes some time to discover such incompatibilities and more time to debug it and finally implement a fix.
This appears to be a very low-end APU. It will run Windows 10. Barely. An AMD Athlon 64 X2 outperforms it, and the Athlon 64 debuted in 2005! It doesn't look promising.
An APU is just a CPU with integrated graphics, so i don't see why it wouldn't work. LV itself doesn't require very much. It certainly shouldn't go up to 4 GB at start ...
@Yamaeda wrote:
An APU is just a CPU with integrated graphics, so i don't see why it wouldn't work. LV itself doesn't require very much. It certainly shouldn't go up to 4 GB at start ...
In theory you are right. And in practice the problem could be not just the APU but possibly the chipset, or a bad driver or whatever. Hard to say. But LabVIEW has some code to try to detect what CPU it is running on and what the number of cores and hyperthreaded cores is. This is needed for things like deciding how much threads to allocate, and how to configure certain threading settings. So it's not entirely impossible that this CPU has something special that LabVIEW isn't prepared to deal with. If it is likely I'm not sure. I tend to consider it possible but not highly likely. More likely is a bad driver, either video or some chipset driver that just doesn't quite like to behave in the way some low level part in LabVIEW or a driver interface is wanting to work.
I also once had a similar issue where LabVIEW would keep spinning on startup without ever showing a window. Had to kill it in task manager. Eventually I happened to try to run NI-Max and that would crash hard during startup. Rebuild the NI-Max hardware database and suddenly LabVIEW started up too. Somehow during startup LabVIEW tried to initialize its installed drivers and one of them did not want to ever proceed due to some corrupted NI-Max hardware database information.
