Canon EOS utility causes high “System” CPU, network meltdown

December 9, 2014

This is one of those slightly odd ones. I had high CPU on my PC even when not running anything, 20-25% (one whole core in essence) taken up by “System”. Mouse responsiveness was sluggish, sound would stutter, the works.

I tracked it down to ndis, and my Ethernet driver, using Sysinternals Process Explorer. Other folk have had similar experiences, so I updated the Ethernet driver. Things got worse. Rolled back and disabled all power savings functions on Ethernet. That helped a little, but only a little.

After a few weeks of off-and-on trying to fix this (and business travel in between), it occurred to me that my driver might be behaving just fine, that it was just genuinely busy – that there might be some form of traffic flood on the wire that caused my symptoms.

Sure enough. SSDP (UPnP discovery) packets to an obscene degree, originating from another machine in the network, with the string “Canon” in the discovery.

This was the Canon EOS Utility 2, or rather the UPnP discovery part of it. I saw no way of disabling UPnP discovery in settings, and the user was opposed to uninstalling the utility, so I just renamed the UPnP discovery exe so it couldn’t be started on boot, then rebooted the machine to check that worked. Problem solved. By killing the UPnP discovery process on another PC, my PC is responsive again.

That UPnP discovery process misbehaves. Until Canon fixes the issue – if they will – renaming it is the only workaround I can see.

If your System process CPU is high and it’s your network driver that’s doing it, run wireshark. It might not be your system at fault.

Installing VMWare Tools on JunOS SPACE

June 27, 2014

JunOS SPACE, Juniper’s management platform for JunOS devices (switches, routers, firewalls) does not come with gcc or kernel-headers. Installing VMWare Tools from a mounted ISO via is not all that successful. Happily, VMWare still provides RPM versions of those tools. SPACE 13.3 is built on CentOS 6, which in turn is a RHEL 6 clone.

This post will be around when SPACE 13.3 is history. The easiest One way to figure out what version of CentOS it might, somewhat loosely, be based on, is to run uname -a and take a look at the kernel version:

uname -a

Linux space-0050568776bc 2.6.32-100.24.1.el5 #1 SMP Tue Aug 20 12:17:49 CST 2013 x86_64 x86_64 x86_64 GNU/Linux

Cross-reference to the Wiki entry for CentOS and you can see that 2.6.32-xx is some version of CentOS 6.

Note: Check the comments below, not all versions of SPACE are created equal. Yours might be based on RHEL 5/CentOS 5. There’s a faster way to check for version, suggested by commenter Riley: “rpm -qa | grep el”. Be sure to use the VMWare Tools package that matches the version of CentOS your SPACE is running.

1) Start by downloading the RPMs for VMWare Tools on RHEL 6. You’ll want the following (or their current equivalent):


That list might change with newer versions of the tools and of RHEL, of course. When in doubt, grab just the vmware-tools-esx-nox package, try to install it, and take a note of all the dependent packages it wants, then download those too.


2) scp the lot to SPACE, say to /var/tmp. While WinSCP is unhappy with the shell the admin user runs on, command-line scp does not care and will work. Choose any version you like: The one that comes with Putty, the one that comes with Cygwin, or any other. And if you’re running OSX or Linux, you can feel extra-smug because you have scp as part of your base OS.


3) Install those RPMs. Now, you could install the GPG key they are signed with, but if you trust that you got them from VMWare, in an unaltered form, then just:

yum install --nogpgcheck vmware-tools*rpm

You’ll notice some errors about initctl missing, and that means the service didn’t get installed. We’ll fix that next.


4) Copy the vmware-tools-services script over to init.d, and rename it while you’re at it

cp /etc/vmware-tools/init/vmware-tools-services /etc/init.d/vmware-tools


5) Edit /etc/init.d/vmware-tools with vi and add two lines, so chkconfig knows what to do with it:

# chkconfig: 345 20 80
# description: VMWare Tools

6) And add it to startup:

chkconfig --add vmware-tools

If you like, you can use

chkconfig --list

to make sure that worked.


7) Last, start the tools

service vmware-tools start

And satisfy yourself that this worked, too:

ps -ef | grep vmtoolsd


vSphere should now be reporting that SPACE is running “VMtools 3rd party/independent”. And that’s all there is to it.

The kmod portion of the tools won’t install, by the way – but then it’s not needed.


Resolving JunOS Pulse install issue on Windows

June 3, 2014

On my own Windows 7 machine, I had an odd error when attempting to install JunOS Pulse 5. The installer would start with “copying new files”, then “rolling back action” and would finally tell me that “the wizard was interrupted before JunOS Pulse could be completely installed.”

Usually, when something odd like this happens, the remedy is to uninstall everything Juniper. Which I did. Network Connect, Host Checker, Setup Client, Installer Service, Pulse Collaboration, I got rid of them all. Which didn’t resolve my issue.

Now, this machine has had various versions of Juniper-something installed on it over the years. Even the OAC client at one point. So it was likely that something was lingering that was causing this issue.

I had seen something similar at a customer of mine. They resolved it by re-imagining the machine. I didn’t want to be quite so thorough.

The solution turned out to be to open a command line “as Administrator”, run “pnputil -e > pnplist.txt”, find everything in there that has the name “Juniper” in it, then run “pnputil -d oemXX.inf” for each entry, where “XX” is the actual number of the entry.

This got rid of a lingering driver in the Windows driver store, which was keeping the Pulse driver from being installed. After this little bit of surgery, Pulse installed without complications.

Before reaching for pnputil, be sure that the previous step, uninstalling everything that has to do with Juniper MAG/SA client software, has already been taken. These drivers are components of the client software. Pulling them out from under that client software is not desirable.

I’ve found a forum mention that pnputil helped with a Network Connect install issue where a Juniper driver had gotten orphaned. This remedy is not specific to Pulse alone.


Restoring a bitlocker system volume with Acronis 2014

March 22, 2014

I had reason to restore my Windows 8 system volume, which is encrypted using Bitlocker. Getting access to my data drive back after that wasn’t quite as straightforward as I had hoped. For reference, and in case others get into this situation, here is what I encountered.

My setup

One system drive, SSD, encrypted using Bitlocker, running Windows 8.1.

One data drive, HDD, encrypted using Bitlocker, set to auto-unlock.

One backup drive, HDD, unencrypted. TrueImage 2014 is set to encrypt the backups themselves. This is crucial: Without an unencrypted backup drive, I couldn’t “get at” my backups when restoring the system drive.

I do not have a TPM module and use a USB stick instead for Bitlocker keys. I do not have Secure Boot enabled, mainly because I upgraded this system from Windows 7, don’t have a Secure Boot compatible GPU, and really don’t feel like re-installing Windows 8 to get the additional boot sector protection of Secure Boot. It’s a neat feature, but convenience wins out.

I keep a copy of my startup key and my recovery keys on a separate USB stick in the safe, and this proved to have been a necessary precaution.

Restore system drive

Restoring the system drive itself was reasonably straightforward. It cannot be done from Acronis within Windows, I had to use a Rescue CD instead. On machines without an optical disk drive, use a Rescue USB stick.

As expected, the system drive was unencrypted after the restore. This is a result of the way Acronis takes sector backups: It is “fed” the unencrypted data by Bitlocker, and so that is what get’s backed up and restored.

Get access to data drive back

I encountered two errors.

First, upon attempting to unlock my data drive, I received an error “Application not found”. The context menu entry to unlock the drive read “unlock-bde”, which points to an issue. This can be resolved by editing the registry, see Microsoft’s KB entry. The automatic fixit didn’t work for me, since my temp directory is on the data drive. Rather than change the location of temp, I just made the necessary two changes in regedit. To unlock the drive, I had to get my recovery key USB stick from the safe. You do have one of those, I’d hope. If not, you might be screwed.

Secondly, upon attempting to set the data drive to auto-unlock, I received an error “data error cyclic redundancy check”. No need to panic, the data is fine: This is a problem with the stored Bitlocker keys. Mark Berry documented the fix back in 2010. I used his updated (2/17/2011) methodology, which is henceforth no longer untested. In a nutshell, enable Bitlocker on the system drive, reboot. While the system drive is encrypting, use manage-bde to get rid of old auto-unlock keys and delete external keys from data volumes, then re-enable auto-unlock. This worked like a charm. Note he uses S: as a sample drive letter of the data volume; replace with whatever drive letter your data volume has.

Lastly, do not forget to copy your startup key and backup your new recovery key for the system volume onto your “oh crap” USB stick, and put it back in the safe where it belongs.

Recover Juniper SRX from failed boot

November 13, 2013

I have a Juniper SRX240H in the lab. I decided to load a beta version of JunOS, which brought the unit into a state where it did not successfully boot, and where I could not use the loader> prompt to recover from TFTP.

The symptoms were:

  • During boot, the SRX would experience a fault and enter the db> prompt. I believe this to be a debugger, possible gdb. “c” will cause it to reboot again
  • If I enter the loader> , I cannot execute setenv – I get a “stack underflow” error. This means I cannot install JunOS from TFTP

I may have been able to recover this system using a USB key, but I am remote to my lab: All I have is serial console.

I resolved the issue by entering u-boot instead of the loader. u-boot prompts right after boot, and the loader prompt is shown shortly thereafter. The u-boot prompt is “Press SPACE to abort autoboot in 1 seconds”, and the loader prompt is “Hit [Enter] to boot immediately, or space bar for command prompt.”

In u-boot, I issued this command:

=> getenv

This showed me that boot.current=primary

I changed this to the alternate slice, which still held a working copy of JunOS:

=> setenv boot.current alternate
=> boot

The system came up successfully and warned me that I had booted from the alternate slice, and it rebuilt the primary slice:

**                                                                   **
**                                                                   **
**  It is possible that the primary copy of JUNOS failed to boot up  **
**  properly, and so this device has booted from the backup copy.    **
**                                                                   **
**  The primary copy will be recovered by auto-snapshot feature now. **
**                                                                   **

The auto-snapshot feature that was used here needs to be configured (set system auto-snapshot) and supported by the version of JunOS you’re running.

Lastly, I confirmed that the snapshot had been repaired, then rebooted:

root@SRX-Lab-2> show system snapshot media internal
Information for snapshot on       internal (/dev/da0s1a) (primary)
Creation date: Nov 13 12:53:04 2013
JUNOS version on snapshot:
  junos  : 12.1X44-D20.3-domestic
Information for snapshot on       internal (/dev/da0s2a) (backup)
Creation date: Oct 4 17:13:17 2013
JUNOS version on snapshot:
  junos  : 12.1X44-D20.3-domestic
root@SRX-Lab-2> request system reboot

Final IPv4 allocations; IPv6 readiness test; IPv6 world day

February 3, 2011

Final IPv4 allocations have been made today. Will this galvanize businesses to start moving to IPv6? We’ll see :)


If you’ve been following my “IPv6 at home” series, here’s a neat link to test your IPv6 readiness:


Finally, “World IPv6 day” will be on June 8th 2011. Google, Facebook, Yahoo, Akamai and Limelight will turn on IPv6 for 24 hours. Results should be interesting to see. If you’d like to prepare for World IPv6 day today, go on over to their official site.


Compiling 64-bit mpir using VC++ 2008 Express

December 23, 2010

MPIR is a Windows-friendly fork of GMP. It can be used as a direct replacement of GMP. I wanted to have my pycrypto build use _fastmath, and that meant having GMP support.

Building a 64-bit version of MPIR is fully supported in Visual C++ 2010 Express. Not so, alas, for Visual C++ 2008 Express. The MPIR build.vc9 readme flatly states “the Express Edition cannot build 64bit binaries”.

Game over? No Python-compatible MPIR lib?

Luckily, the MPIR devs worked hard and provided command-line tools in build.vc9. Using those, even an Express edition of VC++ 2008 can build 64-bit MPIR binaries.

Preparing to compile:

  • You now also need the Windows SDK so you have the amd64 compiler, which isn’t included in the Express version. This needs to be the Win7 + Net 3.5 SDK, not the Win7 + Net 4.0 SDK. You can find it here: , and again download  the ISO (the one for amd64 support though!) if nervous it may disappear. Install and make sure you install the “Visual C++ Compilers”.
  • The vcvarsall.bat in VC++ 2008 Express looks for the amd64 vcvars64.bat in all the wrong places. The easiest way to work around that is to navigate to the VC\bin directory of your VC++ 2008 installation (in my case C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin). Copy vcvars64.bat, and paste into the VC\bin\amd64 subdirectory. Next, rename VC\bin\amd64\vcvars64.bat to VC\bin\amd64\vcvarsamd64.bat.
  • You need yasm.exe to compile the assembly code in MPIR. Download the 64-bit version of yasm, rename the executable to yasm.exe, and copy it to the VC\bin directory of your VC++ 2008 installation.
  • You need the yasm.rules file. Download the MPIR source tarball, and copy yasm.rules from the build.vc9 directory. It goes into your VCProjectDefaults directory (in my case C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\VCProjectDefaults).
  • If you want to be able to automate the MPIR tests (that’s a really good idea), install Python. Chances are you are doing all this to use MPIR with Python and so it’s already installed. Just saying.


  • From within the directory, run configure. You can specify –cpu-x86_64 if you’d like to build a generic 64-bit library, rather than one specific to your CPU type. You may opt to specify –enable-shared if you want to build a DLL rather than a static library.
  • Run make

Check that the compiled library works correctly:

  • Run make check

Your libraries and include files will be in build.vc9\lib or build.vc9\dll, depending. You can now copy those to your VC\lib (.lib and .pdb files) and VC\include (.h files) directories, respectively. If you are looking to use the library with pycrypto, you’ll also want to copy mpir.lib to your Python installations \libs directory, since that is where will look for it. Well actually looks for gmp.lib – I’ll leave that as an exercise to the reader.

Additional speed.exe and try.exe utilities:

  • Run make speed
  • Run make try

These will be in build.vc9\x64\Release and build.vc9\try\x64\Release respectively and allow you to measure the speed of the MPIR library and test MPIR functions.


Get every new post delivered to your Inbox.