Log in

No account? Create an account

Previous Web | Next Web

NOTE: There is a further post following up on this issue here.


This entry details a situation where, after various software updates, an "ApplicationWebServer.exe" process associated with National Instruments "MultiSim Blue, Mouser Edition" is using excessive CPU time.

If you are trying to figure out how to sort this, I've included a Step-By-Step-Guide. I think it should make sense without reading the rest of the post if you don't want; you can read it by following this link... hopefully it will help.

So, as a consequence of a combination of a spiralling Windows 7 install and the NUC/Windows Server 2012 R2 debacle, I'm in the process of figuring out a new Windows 8.1 installation for my main laptop.

I've *also* been putting together an electronics buy, trying to get bits for various projects for the lowest price while also getting free shipping on the orders... which is a pain of a process, since it means trawling through ebay, Amazon, RS and Mouser (the latter of whom have possibly the least useful website for looking around for bits you've ever met....! Although having just gone on it, they seem to have changed things a bit, so that comment may (or may not...) be a bit outdated!)....

Anyway, sometime in the last week or two, I got a banner ad for 'Free MultiSIM BLUE electronic design software from Mouser'... I've got a few free electronical tools on my Windows box... Cadence OrCAD Lite, Eagle Light, Fritzing, PCB Library Expert Lite, TinyCad, and RS's DesignSpark (which presumably provided the impetus for Mouser to offer MultiSim), as well as a couple of stripboard layout tools (DIY Layout Creator and VeeCAD Free Edition), so this piqued my curiosity because, well, I'm still looking for something that covers everything I want to be able to do... generally my usage can be summarised thus:

  • I don't want to be spending money I don't have on software that is mostly for occasional hobbyist use
  • For small projects on stripboard, I tend to use TinyCAD for schematic side of things, and I use DIYLC and VeeCAD as a pair; the Free version of VeeCAD supports NetLists, so can be used to verify that the layout and the schematic match up, but its board view is black-on-white and very, erm, *dense* when there are links, components and stripbreaks in close proximity (for 'dense,' read "bloody horrible to read/use") so I use DIYLC for doing the majority of the actual layout, as it uses colour, and also because it lets you make stripbreaks between holes, rather than on them, which can be useful for getting the board size down, even if its a bit of a pain (literally; I get sore fingers from scraping away the copper every time I do this!) to implement...!
  • For the tiny bit of PCB design I've done over the last few years, I rather like DesignSpark, mostly because you can do 3D views of PCBs and it is really useful to be able to visualise component heights and shapes if you're trying to work out how to squeeze something into as small a space as possible while maintaining clearances for airflow, etc (which I was... that project had to be hide-away-able in a small void I'd found within my car's dash assembly)
  • I really should get my head around simulation at some point.... especially if I'm going to realise a couple of my rather more ambitious projects...
  • If I can't do it all in one tool, I would like to be able to atleast exchange data between tools without too many headaches(!)
  • I need to be able to "talk Windows" when it comes to passing some schematics, etc to other people... this is more a requirement on the non-hobbyist side of my occasional electronical dabblings.... emailing PDFs just isn't good enough... I need to be able to say "install ThisTool", to make a form of collaborative editing possible without OS issues clouding the picture....

Anyways, I downloaded MultiSim Blue and installed it to have a quick look around.... it looks like its probably really useful (once you get over the learning curve.... :-/ ), but I'm not actually trying to use it at the moment; I'm all about 'installation sequencing' and testing at the mo, so we'll see.... but since this is National Instruments commercial grade software wrapped in a bit of Mouser branding, its definitely got potential.....!

Anyway, I updated Windows earlier today and, after the inevitable reboot, I found I had a laptop that had its fan on constantly. This is NOT normal behaviour... this machine usually runs (essentially) fanless, atleast until Firefox decides to run away with a load of excess CPU use...!

Looking into Task Manager shows ApplicationWebServer.exe, which is clocking 13% CPU use... since this is (effectively) an 8-core CPU systen, that's a whole CPU core's worth of processor usage...! Right-clicking this process and choosing 'Open File Location' dropped me into C:\Program Files (x86)\National Instruments\Shared\NI WebServer, so this is definitely part of MultiSim's installation, as I don't have any other NI software.

While looking in Task Manager, I also noticed a number of NI*****.exe processes, so I'm beginning to get very suspicious about MultiSim's installation...

Anyway, I kill the rogue process and the fan stops; nice....! ^.^

But what about all those NI*****.exe processes?

Turns out that MultiSim Setup has installed 12 (yes, that's twelve) "NI something-or-other" Services, and 10 (ten!) of these are set to start automatically, including two of the three web servers its installed....!

The process I killed is the 32-bit version of "NI Application Web Server", the other webservers being (bizarrely on a 64-bit system), an inactive "NI Application Web Server (64-bit)" and an "NI System Web Server".... given a few minutes poking around, I can find no obvious feature within MultiSim that uses a webserver; originally I did think that maybe the help system was using it so NI could be platform agnostic, but the help is just a normal Windows Help file....... :-/

In addition there's:

  • an NImDNSResponder... which its own description says is a "zeroconf advertisement and discovery" service... which, in turn, is exactly what Apple's Bonjour service is (that process is mDNSResponder.exe, btw), and I've already got that running because it installs with iTunes, and I can't be bothered to figure out if it breaks iTunes if I disable it!... surely if you're writing an installer, you can check if a local mDNSResponder exists and can be queried before you install and enable another one...?!?!?!
  • a time sync service.... just a tiny point here, but Windows has an Time Service... and I believe it comes with an Internet Time Service configured out-of-the-box.... has done since XP was new, if memory serves...... so that's more functionality being pointlessly duplicated and enabled out-of-the-box....!
  • and an 'NI Network Discovery" service, which apparently is necessary for zeroconf discovery of devices and services.... you know, exactly what an mDNSResponder is supposed to be for....................................... (I'm not sure there are enough 'period' characters in the world to show how much this one confuses/annoys me...!)
  • finally, I will admit, there are a couple of more 'sensible' services included, such as a license management service and an authorisation service....

Buuuuuttt... and here's the real kicker.... I stopped ALL the NI Services (properly, using services.msc this time, atleast for the ones that would stop when told to... I still had to kill a couple) and MultiSim still works! So does (atleast as far as I tried it, the bundled NI UltiBoard software. Admittedly, I didn't do anything more than place a couple of components in a schematic in MultiSim (and I only started the UltiBoard software), but still, I wouldn't expect to be able to even fully load the software without the licensing and/or authorisation Services, let alone make use of it, even in a small way..........

As a consequence of this (very arbitrary) experiment, it looks as though it may be possible to run "MutliSim BLUE Mouser Edition" without running any of the NI Services that were set up out-of-the-box to 'Automatic' startup... but mileage may vary with this... if you (like me) have looked at those 10 running services and thought "erm, attack surface!!", its probably best to have those ex-Auto Services set to Manual start, and then only start them for the duration of a MultiSim working session (by batchfile 'sc' commands maybe? or some PowerShell....) and to also isolate them from the network as much as possible using your application firewall... Windows Firewall (atleast on Windows 7) looks like it should be able to do this, but I'm running Comodo Firewall, and I can't be bothered to test either right now!

NOTE (To Self): Out-of-the-box, the only NI* process that set to Manual was the 'NI License Server,' while 'NI Application Web Server (64-bit)' was set to Disabled.

Which begs the question; why are Mouser (and therefore NI) distributing a piece of software that bundles so much unnecessary stuff that install with NO NOTIFICATION TO THE USER??? Anyone would think that this was an Apple product (iTunes, I'm looking at you here......)

And as for the chances of a non/semi-technical user (ie, a nominal prototypical 'hobbyist' electronics enthusiast) being able to work out (a) why they have two webservers running (away with the CPU! ;-) ) (and b) how to prevent the runaway one from happening after every reboot, I'd say they are..... looooowwwwwwwwwwwww.......!

Note: To reiterate, if you are trying to figure out how to sort this, I've put a Step-By-Step-Guide at the bottom.

Now, back to my runaway ApplicationWebServer.exe process for a moment.... I've been poking at it a bit more, and (because I've just been killing it), I hadn't noticed that starting it also causes two instances of NIWebServiceContainer.exe to start, as well as SystemWebServer.exe (that is, "NI System Web Server"), which (in turn) starts the "NI Authentication Service" and "NI Service Locator" Services.... I still have no idea what the Application Web Server's purpose is, but its dependencies atleast explain what a few of the Services that are running are doing running!

One final thing to note is that I installed MultiSim a few days ago, and I have definitely rebooted in the interim.... however, NI's auto-updater installed an update yesterday... and the first reboot since that update was the one I performed today after installation of a couple of Windows Updates... which is when the runaway process first became manifest. (I've been using Linux a fair bit recently; enough to have slipped out of the habbit of "always reboot after any update, no matter how small"!!!! :-( ). It therefore seems likely that whatever has caused that process to simply runaway immediately upon starting, it came from either NI's own update or (less likely I think) a Windows Update....

I am (99.99%) certain it isn't because this Windows 7 install is getting flaky; it is still generally stable enough to stay up without a reboot for a few weeks (ie, Patch Tuesday to Patch Tuesday usually), with it being in Sleep overnight, and doing atleast an 8 hour day most days... the 'flaky' still only manifests in very specific ways at this point...

I'm hoping that this issue does affect a reasonable number of people, and that a subsequent software update will fix the errant process... but I'm not daft enough to hold my breathe 'til it happens!!

Follow-up: There is a further post following up on this issue here.

Just in case someone is looking for info on how to resolve this issue and has fallen across this journal posting, hopefully this will help:

DISCLAIMER: Normal 'disclaimery' things all apply; this information is provided "as is;" if something breaks as a consequence of using the information provided, then THAT'S NOTHING TO DO WITH ME... so make sure that you understand what you are doing (I have tried to explain the bits I think aren't self-apparent, but still...). As a simple rule of thumb, you should NEVER blindly copy any procedure from an Internet source (no matter how reputable).


Note: This procedure modifies the operating state of a system Service related to the NI MultiSim product that is demonstrating excessive CPU use when the MultiSim product is not in use.

While some basic testing has been undertaken to see that MultiSim will still load and perform basic operations, using MultiSim long-term with the Service in this condition has not been tested, however a reasonable working process is described at the end of the procedure that will ensure that all Services related to MultiSim are operating when MultiSim is in use.


Note: You will need Administrative powers to do this... if you don't have them for the computer in question, you need to find someone who does!

  1. Open Windows Task Manager by right-clicking the taskbar and choosing 'Task Manager'/'Start Task Manager' from the menu'. On Windows 8 and above, you (may be) required to go through a UAC Prompt to start Task Manager
  2. On Windows 8 and above, you may have to click 'More Details' in Task Manager to see the 'tabbed' Task Manager interface and see all your system's processes.
    On Windows 7 or earlier, you must click the 'Show processes from all users' button so that you can see every process on your system. On Windows 7 or Vista, this (may) require you to go through a UAC Prompt
  3. On Windows 8 and above, go to the 'Details' tab
    On Windows 7 and earlier, go to the 'Processes' tab.
  4. Click the 'CPU' column until it appears with a 'pointing down' triangle in it; this sorts the list with the most active processes at the top of the list
  5. Identify the miscreant process... it should be at/near the top of the list now.
    As mentioned earlier, many of the MultiSim processes are named NI*something*.exe, but there are a few others (like my misbehaving ApplicationWebServer.exe process, SystemWebServer.exe and various LKsomething.exe processes) that don't.
    Note: Just because a process happens to have a name that matches these crude metrics, DO NOT just assume it is related to MultiSim; doing so could completely wreck your Windows installation.
  6. Right-click the suspect process and choose 'Properties'; the program's name, installation location and a description are given on the 'General' tab of the Properties dialog.
    Many of the MultiSim processes install under C:\Program Files\National Instruments or C:\Program Files (x86)\National Instruments, but a few do install under C:\Windows (either in system32 or SysWow64, depending on if you're running 32- or 64-bit Windows)... be careful with the ones in C:\Windows... but if you switch to the 'Details' and/or 'Digital Signatures' tabs of the Properties dialog; for MultiSim-related processes, you should be able to else "National Instruments" in the tab content
  7. Make a point of checking the 'Description' column of Task Manager for your errant process; this may be very useful later
  8. Now we know what the naughty process (and are pretty sure that it is, indeed, related to MultiSim), we can stop it and prevent it from auto-starting; press Win+R on the keyboard (ie, hold the 'Windows'/'flag' key down, tap the 'R' key, then release the key you're holding down) and type into the Run dialog that has appeared:


    then click the OK button
    If the 'Run' dialog doesn't appear for you, it may be disabled on your computer; but (for Vista and later) you should be able to type services.msc into the Start menu/screen search field and start the Services window that way... On XP, there should be a Services item in Control Panel > Administrative Tools.
    On Vista and newer, you (may) have to go through a UAC Prompt to start Services.
  9. In the Services window that opens, scroll down the list, looking at the Name column... because we know that we are only interested in MultiSim-related Services, you can jump to the one's whose name begin with "NI".
    If your runaway process is (like mine) ApplicationWebServer.exe, you are looking for "NI Application Web Server"...
    If its something else, you may be able to make an educated guess (the process name and 'Description' details we looked at previously may help with this) but if you do, you need to verify your guess.... and some of the processes (such as the "NI Time Synchronization" service, have names and Descriptions like "lktsrv.exe"), that are almost unguessable...!
    To check a Service, right-click its entry in the Services list and go into 'Properties...'. On the 'General' tab, the entry of interest is labelled "Path to executable"...
    Note: Even though this just looks like a line of text, its actually a sneaky 'stealthed' textfield, so if it seems to be chopped short you can use a mouse drag just as if you were trying to select the text in a normal textfield... and when you drag beyond the visible text, the field will scroll to the right, selecting (it looks like its highlighted) its content as it goes... this can be a little tricky to get right (it can scroll very quickly), so *hint* if you are struggling to see some of the line, but it is highlighted, you can right-click the highlighted (selected) text and choose 'Copy' and then you can paste the text into, say, Notepad for an easier look!
    Unfortunately, all the C:\Program Files.... paths are too long to see the whatever.exe part without using this select-to-scroll trick, sorry... :-(
    Anyway, if your first attempt to locate the relevant Service was unsuccessful, you just have to close the Properties dialog and keep looking through the "NI" Services until you find the right one.... its annoying, I know, but there are only twelve to check... and it doesn't really take very long once you get going, promise!
  10. So, once you've located the Service that is stealing all your CPU cycles, what do you do...?
    Well, two things:
    • The first thing is to prevent the Service from auto-starting...
      On the 'General' tab of your errant Service's Properties page, there is a 'Startup type' field; we want to change this from 'Automatic' to 'Manual' and then click the 'Apply' button. Do NOT be tempted to set this to 'Disabled' (I'll explain why at the end)
    • The second thing is to stop the process that is currently running; again we're on the 'General' tab of the errant Service's Properties page; click the 'Stop' button. Windows will say it is "attempting to stop" the Service.
      Unfortunately, for a runaway Service process, this will, in all likelihood, eventually tell you that it failed to do so with a message such as "Windows could not stop the service on Local Computer." it will probably also mention something about the Service not responding in a timely fashion.
      So what do we do to get rid of that pesky process?
      Well, we don't want to reboot; while that would be effective, it really would be overkill (but if all else fails, it is the last resort)....
      So instead, we go back to Task Manager... and (now that we've taken steps to prevent a re-occurrence), we can select the errant process from the list on the 'Process' tab and click the 'End Process' button.
      Task Manager will query to make sure you really want to end a process, to which we can now confirm that we do.... so click the 'End Process' button on the query dialog box, and after a moment (or three), the process should disappear from the list.

And there we are; the errant process has been tamed!

But I did say I'd explain why you shouldn't choose to set the Service's startup type to 'Disabled'... so I'd best cover that too....

It boils down to this; we are forcing one of the Services MultiSim may be expecting to use to not be available to it, and this could break MultiSim in unforeseen and subtle (or not so subtle) ways.

We therefore need a way to ensure MultiSim can find all the Services it expects to be available to it...and the least difficult, least intrusive way to achieve this is to simply manually start the errant process before we start MultiSim, and to manually stop it when we are no longer using MultiSim... and it isn't possible to start a 'Disabled' Service.

This "safe" working process for MultiSim is a little cumbersome, but it will work... and if you are using MultiSim occasionally, it will avoid a lot of wear-and-tear on your computer's cooling system, etc.

All we are going to do is a few of the steps we did previously;

  1. Open the Services window by entering services.msc in the Run dialog or Start menu/screen search field (or on Windows XP, by starting Services from Administrative Tools).
  2. Locate the naughty process in the Service list and start it manually (right-click it and choose 'Start')
  3. Start any other "NI" service whose 'Startup type' is 'Automatic' but whose Status is not 'Started'; these are most likely dependent on the naughty Service, so can't start themselves when Windows asks them to.
    If you are not concerned that someone may have access to your computer when your back is turned (or you nip to the loo...), you can save a few keystrokes and clicks and leave the Services window open... or you can close it, until you need it again
  4. Use MultiSim
  5. Once you're done in MultiSim, go back into Services and stop the naughty process (confirming you wish to proceed if you are prompted about stopping additional Services; those are the dependencies).
  6. Remember from before that stopping the runaway Service this way will quite probably fail; if it does, use Task Manager to "End Process," as detailed in the main procedure.

And thats it!

Hopefully if this issue does affect a reasonable number of people, a subsequent software update will fix the errant process... so if you are using this 'safe' procedure then hopefully one day soon, you'll be running MultiSim and you'll notice that your fan isn't running as much and/or the CPU isn't being overused by the naughty process...

Note: One last thing occurs to me; it is possible that an NI update may undo the change you made to the Service startup type while leaving the 'runaway' issue unfixed; if you notice the process has started misbehaving again, this is most likely why... if this does happen, all you need to do is change the Service's startup type back to 'Manual'.

NOTE: There is a further post following up on this issue here.

Edited: Added the summary and 'jump' link prequel section

Edited: 18th July, 2015 at 8:25 PM: Added links to the follow-up post

Featured Posts from This Journal

  • Update on MultiSim issue

    This is a follow on to this post. OK, so, having faffed about why the runaway ApplicationWebServer.exe process and decided what I was going to do…