(Apologies if this is the wrong board for this issue).
We have several Windows XP systems in our production environment, most of which have NI-VISA 5.4.1 installed on them. (We can't use 5.14 as it isn't compatible with some PXI modules that we use). Recently, the systems have been locking up, with the service "NI System Web Server" taking 100% of the available CPU. Disabling the service doesn't seem to have any adverse effects, but I was wondering if this is a known issue (possibly with a solution?), and if disabling the service permanently will cause any problems.
I'm sorry to hear that you're experiencing this issue, it does appear to be something a few customers have seen before usually when compiling on FPGAs
Can I ask a few further questions to try and work out the correct solution for you?
*Which version of LabVIEW are you using?
*Has there been any updates/upgrades that have caused this to start happening? Or has anything changed at all with your system?
*When is the error occuring - are you using an FPGA PXI module?
Have you tried restarting the Web Server after you have disabled it? Does the error still occur?
As to whether disabling the service permanently will cause problems it could potentially. Diabling the web server will make certain targets unreachable from MAX outside of safemode. However they should be find outside of MAX.
I hope that helps,
Charlotte, thanks for your message.
To answer your questions:
1. LabView itself isn't installed on any of the problem systems. The LabView runtime engine, version 8.5, is installed (and has been for some years).
2. The problem was first reported after upgrading to NI-VISA version 5.4.1, but other systems have this version installed without the problem occurring. I'll check if any of the problem systems have a different version of VISA.
3. PXI modules with FPGAs are installed in the systems - the problem occurs when the machine first boots up, before any applications are started. (It's not possible to start any applications until the service is disabled).
I'll see what happens if I restart the service on one of the problem systems, and get back to you.
I have a few questions for you:
- Is it just one of your systems doing this or all?
- Are the systems left running day and night?
- Have you tried restarting the systems?
1. The problem exists on three systems out of about 50. The failed systems all have the same software, but different hardware configurations.
2, Yes, normally.
3. Yes, the problem comes up as soon as the machine is booted, even if the PXI rack is switched off.
This is Shazil from National Instruments. As Jinfone is not currently in the office, I will try to assist you further on this. I have looked through our database and was unable to find any known/reported bugs to this issue. Perhaps, the different hardware configurations may have an effect on this ( or may not).
If you are not going to be using the Web Server to communicate to the target, you can turn this off as you mentioned at the begining. This should not have any consequences. But you will have to turn it back on, should you need to use it again in the future. Do let me know if you need assistance in turning it off or you are aware of the procedure.
Also, If you could attach a MAX technical support report from a system that is working correctly, and from 1 that is giving this issue. You can use ''Method 1'' from the following Knowledge Base to create a "Technical Support Report"
Shazil, hi. Sorry for the delay in this reply.
When I enable the service manually, it seems to work OK - the service appears on the process list, but at 0% CPU.
Attached are the report files, as requested. Note that the "bad" report was generated with the PXI rack disabled (so no PXI modules will be shown in MAX) - I can get one with the rack enabled if it would help.