Ftpupd.exe 100% CPU issue

It doesn’t happen often (sometimes weeks between episodes), but my Core-I5 system will hang up at 100% CPU and there are 4 instances of ftpupd.exe, each taking 25% overall (100 % on each of the 4 CPUs in the Core-I5).

I just caught one rogue today, and took a full dump of the process, and killed the process.

Brian, would the full dump be useful in debugging it? (it’s 25MB zipped)
Or, is there any other diagnostic you’d like to see instead.

I’m running the WD 10.37R-(b252) on Win7-Pro, 4GB system.
ftpupd.exe is from 3/19/2015 2.25MB in size…no internal version numbers found.

Best regards,

the back up code I could find of that program was not all that recent
i.e I am not able to update that program
but what I have been doing is separating out processes that it was doing into separate small cron programs
so that eventually all that the ftpupd.exe program does is just FTP uploads to your web site…and then I can create a new version of it

does startwatch have a facility to restart or kill it if high cpu use?

good to see you are using a recent version of WD Ken (albeit not the most recent) :slight_smile:

startwatch can only watch things it starts, not sub-processes started as separate instances by a process it starts.

As a stopgap, I can use scheduler, a bit of perl and a couple of the MS sysadmin commands to auto-kill a process that exceeds 24% CPU :slight_smile:

If you could release a ftpupd.exe from recent code, I’d be glad to replace the older one.

I’ve become a bit more conservative on weather software updates, and tend to stay a bit behind the pack.

Best regards,

you should be good to go with the latest WD update :wink:

Tried the full install of 268 – ran into issues… the main WD would ‘freeze’ and wouldn’t launch ftpupd.exe at all… I’ve reverted to 252 which was running fine.

I did note that the ftpupd.exe was not updated (at the same version as with 252).

I did find a nice cmd to dump the processor data for ftpupd:

wmic path Win32_PerfFormattedData_PerfProc_Process WHERE Name="ftpupd" GET Name,IDProcess,PercentProcessorTime,PercentPrivilegedTime,PercentUserTime

I am not sure why you would have this freeze up problem
maybe if you could .zip and email me your settings files I could test here

I had one instance of ftpupd.exe churning away overnight, so I cobbled a perl script to handle the auto-kill (and have set it on a 15minute task scheduler run).

# use the pstools to find the current cpu for ftpupd.exe (WD), and optionally
# use pskill to zap it to release the held memory
# K. True - 28-May-2015
# Run via Windows Scheduler or Linux cron .. all output is to the log file(s)
# ---- configurable settings ----
$maxCPU = 95;  # amount in KB that we'll tolerate
$lookFor = 'ftpupd';

$logsDir = "./ftpupd-logs/"; # place to store the YYYYMMDD.txt

# ---- end of configurable settings --
$|=1; # no buffering of output

 $cur_time = time();
 @months = ("Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec");

 $log_filename = ISO_datestamp($cur_time) . ".txt";
 $nice_date = nice_datestamp($cur_time);

 open (OUT,">>${logsDir}${log_filename}");

open(PS,"wmic path Win32_PerfFormattedData_PerfProc_Process WHERE Name=\"$lookFor\" GET Name,IDProcess,PercentProcessorTime,PercentPrivilegedTime,PercentUserTime
 |") || die "..unable to run wmic $!\n";
$foundIt = 0;
while (<PS>)
  #print $_;
  $rec = $_;
#IDProcess  Name    PercentPrivilegedTime  PercentProcessorTime  PercentUserTime
#13200      ftpupd  0                      98                    98

  ($PID,$name,$privCPU,$CPU,$userCPU) = split(/\s+/);
  next unless $userCPU =~ m/\d+/;
  next unless $name = $lookFor;
  #print STDOUT "$name\t$PID\t$CPU\n";
  print OUT "$nice_date\t$rec";
  print STDOUT "$nice_date\t$rec";
  if($CPU >= $maxCPU) {
    print OUT "$nice_date\t$name PID=$PID pskill for $CPU > $maxCPU percent\n";
    print STDOUT "$nice_date\t$name PID=$PID pskill for $CPU > $maxCPU percent KB\n";
	open(PK,"pskill $PID |") || die "..unable to run pskill $!\n";
	while (<PK>) {
	   print OUT "$nice_date\t$_";
	   print STDOUT "$nice_date\t$_";
    print OUT "$nice_date\t-------------------------------------------\n";
    print STDOUT "$nice_date\t-------------------------------------------\n";

if (!$foundIt) {
    print OUT "$nice_date\t$lookFor task not running\n";
    print STDOUT "$nice_date\t$lookFor task not running\n";
# ------  end of main program -----

sub nice_datestamp {
    my $d = shift;
    my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($d);
    my $nicedate = sprintf(
        "%02d\-%s\-%04d %02d\:%02d\:%02d",


sub ISO_datestamp {
    my $d = shift;
    my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime($d);
    my $nicedate = sprintf("%04d%02d%02d",$year+1900,$mon+1,$mday);


which produced the log of

28-May-2015 08:04:30	13200      ftpupd  0                      100                   100              
28-May-2015 08:04:30	ftpupd PID=13200 pskill for 100 > 95 percent
28-May-2015 08:04:30	-------------------------------------------

So… I’m ‘protected’ from having it take over the CPUs. Other than that, the system is quite stable and running well.

I’ll send the settings files via email – thanks for offering Brian :slight_smile:

Best regards,

re the other issue with the latest version
I suspect that is actually related to the testtags.txt processing
try build 269 update
where i have split out the processing of those more

Tried the b269 .zip. The weatherdisplay.exe still ‘hangs’ in non-responsive mode periodically… reverted to b252

See attached screenshots

Best regards,

when you say periodicly…how often…at a certain time always, or?

About every minute at the :00 seconds, then about 20 secs later, it refreshes the main display. You can see on the first non-response image that the time display is a white-bar, then when it starts refreshing the window, the time display shows normally. Very odd-- seems to be off waiting for something. The CPU load for WD is just a whisper while this is happening.

Oh, let it run for about 15 minutes like this before reverting to 252.

I am not seeing that behaviour here
the clock pauses for only 2 seconds on the minute
running here with your settings

one thing you can try turning on in the latest version is under setup, advanced/misc…program…at the very bottom…tick…process applicationmessages

Did an unzip of 262. Turned on the process applicationmessages screen, saved/exited, restarted. No difference.

It starts non-response about 5 seconds after the minute rolls over, stays that way until about :50 secs, frees up, then repeats.

I’m back to 252 for now.

Thanks for your debugging efforts, Brian – I know how hard it is to try diagnosis when the issue can’t be replicated locally.

Best regards,

does it do that on every minute or just the 5 minute times (when you have set to do internet updates via the upload times)

It was every minute, not just the 5-minute upload period.

I captured the stack (using ProcessExplorer ) when it was non-responding if that’s any help


if we could continue via email…might be easier…
and if you could continue to work with me to try and narrow this down…
i.e I will get you to try and turn things off…etc…to try and track down the problem

the first thing to try…is it could be something about your data files
rename the data files folder (when WD is not running)
then start up WD…i.e so it stats up with no data…just as a test…

Hi Brian,

I’ve cloned the WD setup to my testing system – got 252 working fine, then updated to b269, started it and it ran fine (so I can see that you couldn’t reproduce the issue either). I guess it’s an issue with my prod Win7-Pro system.

I’m somewhat loathe to mess-about with the running WD as it provides primary data to my website. I’ll see what other alternatives I can come up with before resuming debugging on my production system. Thanks for your help!

Best regards,

if the problem is occuring in the first minutes after starting then it should mean testing would make your web site data not available for very long
eg testing like trying to isolate things

re the clone…is that even using the same datafiles and logfiles?

I made the clone by doing a Symantec System Backup restore of the c:\wdisplay directory (and subdirectories) from last night’s backup to my NAS.
It does full file copies, so everything in the was the same in the cloned directory.
I did a Registry Entries backup on the production WD, and loaded the .reg entries into the test system. Edited the wdisplay.ini on the test system to
change the com port to an open one on my test system (provided by VirtualVP chained to the prod system VirtualVP).
Started 252 and it picked up the missing archive data from the snapshot of last night’s backup.
Turned off the Main Internet switch (and APRS, Wunderground, WOW).
Let it run for a while, then shut down, unzipped the 269.zip over the directory and restarted weatherdisplay.exe

It ran for several minutes and didn’t exhibit the issue with the ‘no response’ at any time.

Looks like we’re going out to dinner in a bit, so no more debug until later :slight_smile:

on the problem setup
do you have WD set to run as administrator?