I'm running DisplayFusion v3.4.1 Pro and have noticed as of late that the DisplayFusion process is experiencing abnormally high CPU usage as well as what might be a memory leak. The actual symptoms of this that I've noticed are the multi-monitor taskbars become progressively more unresponsive (ie. after several days uptime icons may take entire seconds to appear, same for any interaction with the taskbar such as minimising/maximising via clicking) as well as similar lag when using the DisplayFusion tray icon.

The process consistently uses approx. 10-30% of CPU usage at all times and at present has 319,896KB in Private Byes (about a 100MB more than yesterday). In addition, it also seems to be constantly creating and destroying threads (this may be normal, I don't know, but it seemed a little unusual).

The system I'm writing this on is fairly heavy-weight with 6 x 1080p displays, however, I've seen the same behaviour on my laptop with no external display attached, just a plain 1920x1080 LED screen.

I've attached for your reference the troubleshooting log at time of writing.

By the way, thanks for all your effort with DisplayFusion. It's hands down the best multi-monitor power-tool out there; please keep up the good work!

Sure, but it might take a day or two to get conclusive results. I'll install it now and let you know.

Hi Keith,

Unfortunately the problem does appear to still exist. Since upgrading and restarting DisplayFusion (immediately after the last post) it has been running continuously and now there is a small but perceptible lag when interacting with the DisplayFusion taskbars (the primary Windows taskbar is unaffected). At the moment, it's about a .5 second, perhaps a little less, delay when interacting with them (e.g. clicking an icon).

Memory usage is currently at 122,172KB Private Bytes with CPU usage averaging about 6%. I've been using the system constantly since my last post, though, I'm unsure if actual system usage has any impact on the rate of performance degradation.

Is there any more information I can provide to help?

The difference appears to be fairly minimal and I'm not sure it exists at all (might be wishful thinking?). Leak is also still present and so after about 20hrs of runtime we're at 175MB of private memory approx. and an average of 10-30% CPU usage. The same severe lag on taskbars is also now present.

Can definitely give it a try later tonight and let you know the results with-in a day (to give time to reproduce). Just for your record it's not purely high CPU usage but also high memory usage (and ever increasing seeming to indicate a memory leak). The high CPU usage seems to correlate with the leak; ie. the bigger the leak (time since DP started) the higher the average CPU usage of the process.

You are correct, I do have Bins installed; is this likely to cause problems with DP?

I wanted to jump in because I was looking to see if it was just me having the issue with the DF taskbar lagging after a day or two of use. Apparently it's not just me. The main reason I chimed in is that I am experiencing the same behavior and I am using Bins. The problem goes away immediately if I shut down DF and restart. I had originally thought it might be Bins causing the issue since that's a newer install of mine. The problem seems to persist when I shut down Bins and leave DF running. Of course that doesn't mean it's necessarily a DF problem, but I am running both. Hopefully this helps.

I'm running version DF Pro, version 3.4.1.

Jeff

Would it help if I contacted the Bins developers as well?

BTW, didn't say this earlier, but DF rocks!

Hi Keith,

Just confirming I'm still seeing the same behaviour on Beta 5.

Cheers.

No worries; at least we seem to be pretty certain we know what the issue is (compatibility with Bins & DF). Just a matter of getting a fix in place!

DF 3.5.0b5 on XP Pro SP3
DF spiking to ~10% CPU every second with no window activity
Not running Bins (never heard of it!)

I am running Bins and I am having the high cpu and memory loss issues reported above. Please let me know when you have a fix.

Seems to start straight away.

I have the same problem.
Is displayfusion .net based? If so then I think it all started with a windows update for .net framework.

This issue just started today for me, w/ 3.4.1 Pro, it spiked to 25-30% for about 15 minutes, I didn't see it's memory usage but currently it has calmed down again and is 0-1% usage and ~7-8MB of RAM. I am not using "Bins", I don't even know what that is. If more info is required, I will be happy to supply it, just let me know what you would like to know.

**CORRECTION**
It has spiked to 30% again and jumped to 9MB of memory usage. just after posting this.

The image jumped from ~8mb where it was yesterday to where you see it now, and that was just from opening the Settings window. Attached also is the Troubleshooting tab as requested.

It's been a little over 24 hours now and I've noticed no ill effects. DisplayFusion is sitting quite happily at 0% CPU time, changing my wallpapers as directed and using <4MB of RAM.

I have found that the amount of CPU usage and memory allocation is determined by the size and number of files in the directory you point DF at. With only 50 to 100 file in a directory the CPU usage is minimal and the memory is around 10,000K. If you point it at a directory with 200,000 files CPU goes to almost 100% and memory goes to a few 100,000k

Are you sure? I have DisplayFusion pointed to E:\Users\Chris\Pictures\Wallpapers which houses 1,274 high-res images spread across 34 folders and DisplayFusion is only using <10MB of RAM... (9,032K to be specific)

I was about to uninstall the program but decided to read your discussion group first and thought it just might be the number of files the program was pointed at. I had it looking at 200,000 files in 1000 directories and the program goes to it's knees. I have it looking at about 100 file right now and it works as it should.

I should have mentioned that almost all the files are 1920 x 1200 or much larger.

Just saw Beta 6 has been released; unsure if this is expected to have any impact on this issue but have installed for testing.

This is a big improvement. Thanks a million

Just confirming the problem is on-going with Beta 6. I can try Beta 7 next if you think it worthwhile.

I'd just like to chime in here that I'm suddenly noticing DF (3.4.1 Pro) slowing down my PC and taking up to 80% of CPU for some reason. I don't have Bins. Not sure what the problem could be; I haven't changed anything recently.

Hi Keith,

Just wondering if we're getting closer to a fix? I miss the power of DisplayFusion

Beta 8 still seems to be constantly allocating memory, and occasionally releasing it, even when nothing else is happening on the box. CPU consumption seems to be down to a spike of a percent or two every few seconds but I'm curious as to what it's so busy doing all the time.

It doesn't seem to make any difference whether it's managing wallpaper or not, nor whether application hooks are enabled or not.

(DisplayFusion Pro 3.5.0 beta 8 on Windows 7 Enterprise SP1 64-bit on 2.93 GHz Dual-Core Pentium).

Hi all,

I just wanted to jump into this discussion. Running Beta 8 now and Bins and still having memory problems (not as bad as used to be with 3.4.1 but still noticable and annoying).
Will install future Beta's for testing in you need anymore input.

Greetings,
Christian

I've now tried v3.2.0, v3.4.0, v3.4.1, and some of the recent v3.5 betas, including beta 8. All of them increase their memory footprint over time, and all of them eventually use far too much CPU time. The rate of increase doesn't seem to be as steep with 3.2.0 as it is in the later versions.

I installed beta 8 yesterday, sometime around noon. The memory footprint was around 50M initially, and it was using less than 1% of CPU time. Last time I used the computer (around 8 pm), it was at about 120M and 18% CPU time. This morning (around 10 am), after the machine was relatively idle over night, memory was over 200M, and CPU time was at 48%. Uninstalled.

I'm a systems software developer. I know that these problems can be hard to fix. I also have far more software installed and routinely running than most people do, and a fairly high end machine. 48% of four 3+ GHz cores is a lot of CPU time.

Looking forward to seeing this problem solved so I can go back to using DF again. I'll keep trying the betas.

Yes, I'm another of those who use both DF and Bins.

Trying DF without Bins running would be more work, since my UI is organized around Bins.

I'll try running both on a medium power laptop. I haven't run either on that machine yet (only bought one license for each), so it will take a few days to get results.

My usual desktop and the laptop are both running Win7 SP1, but the laptop has a lot less other software installed on it.

If Bins is part of the problem, I can understand some of the memory creep. It should still stabilize after a while, though, and it doesn't seem to. Regardless, it's hard to see how a Bins related problem would legitimately cause DF to use such a huge amount of CPU time.

Just started DF on the laptop, with Bins not installed. DF is using about 60MByte of memory, and around 0.1% to 0.2% of CPU time. I'll try to remember to check it again tomorrow.

Voted up and commented, thanks for the heads up...

Dumped 3 Votes there! Here is to hoping things get worked out. I love both utilities and use them extensively in my line of work. Although BINS just cleans things up for me I do enjoy the feature set. DF on the other hand I almost can not work without. Everytime I see someone with 2+ monitors and no second taskbar I point them straight here...

Thanks so much for reaching out to the BINS folks! Just another star to be added to the support you guys provide for DF.

Yes; it looks like it's a DF + Bins problem.

Bins has been running without DF for about 3 days on my multimonitor desktop, with a complex Bin-ed Taskbar configuration. Bins is using 162,524K of private RAM, and around 0.25% of CPU time. Those numbers seem to be fairly stable.

I ran DF only on my laptop. When it started, DF was using 62,520K and less than 0.2% CPU. Last night (36 hours after starting it) it was at 55,948K and still less than 0.2% CPU.

I then installed and ran Bins. It started at 92,716 K RAM and less than 0.1 CPU. No immediate change to DF's numbers.

This morning, approximately 14 hours later, Bins is at 87,232K and still less than 0.1% CPU. DF is now at 91,920K and 7% CPU.

So: Neither one alone is a problem. DF + Bins causes DF to misbehave. DF still isn't using enough resources on the laptop to be a problem, but if it's resource usage continues to increase at this rate, it will become a problem soon.

During the 14 hour DF + Bins run, the laptop was completely unused. Only background process were running. It only has it's own single, built-in monitor, so it isn't asking DF to handle multi-monitor Taskbars. Although Bins is running, I didn't change the configuration of the Taskbar when I started it. Each icon probably counts as a bin, but there are no icons that refer to more than one shortcut. I literally didn't touch the laptop again after starting Bins; no keys typed, no mouse movements. DF and Bins should both have been as idle as they are able to be.

I don't work much with the Windows API, so I don't really understand how the presence of Bins could be causing DF to misbehave. They do interact indirectly through the Taskbar, though, so it's possible.

I'm tempted to attach a Windows API tracer to both to try to figure out what's going on, but since neither is open source I couldn't fix the problem even if I did find it.

I'm posting this on both the DF and Bins support forums.

Glad to see this issue is being worked out.. I will begin trying out the betas as well.. I am also a DF + Bins user since bins first arrived.. and find myself having to restart DF sometimes once a day as it will lag or crash.

I am installing betas now. Will give more comments in the future.

The BINS guys put out a beta at the link posted above. I have it installed and it seems to be working very nice again!

DF Beta 8 and the Beta of BINS posted.

Thank you for reaching out to those guys!

Trying on my multi-monitor desktop now. At startup, DF is using around 60M RAM and 1.3% CPU, and Bins is using around 130M RAM and 0.25% CPU. I'll try to remember to post an update tomorrow.

I just wanted to chime in & let you know that I have this same/similar issue, yet do not run Bins. (I've never even heard of it)

I'm on Win 7 x64, 8GB RAM, and DP (pro v3.4.1) gradually keeps eating up memory over time & gets laggy, sometimes even to the point where I eventually get windows warnings that I'm out of memory, after a few days.

Let me know what info you'd like, if any, and I'll supply it. Thanks for your active support!

Almost 24 hours later, DF is at about 70M RAM, up slightly from 60M. DF CPU time is unchanged, at about 1.3%. Bins RAM use is also up slightly, at 148M, and its CPU use is also unchanged at around 0.25%. The small RAM increases are not surprising, and are not a problem.

As a development desktop, this machine is something of a stress test. A lot of software installed, and many things running in the background. Four core CPU. 64 bit Win 7. Four monitors, each with a DF taskbar. The primary monitor's taskbar has many icons, all heavily Bin'ed.

Have to watch for a few more days to be sure that the problem isn't just happening more slowly, but looking good so far.

Just reporting in that I'm currently using DP v3.5.0b8 w/ Bins v1.0.0.224 and results are promising. System has been up for about 20hrs with CPU and RAM usage both holding steady.

Keith: Can you shed any light on the cause of the issue? I'm more than a little curious after this journey!

Bins and DF are using about the same resources they were when the new version of Bins was installed around 3 days ago. DF RAM is up a bit, from 70M to 82M. CPU time is also up slightly, from 1.3% to 1.5%. The amount of each used is not a problem, although the increase might eventually become a problem if it continues.

Bins RAM use is up, from 148M to 240M. CPU time is steady at no more than 0.25%.

Unfortunately, DisplayFusionAppHook is now up to around 20% of CPU. It seems to be increasing slowly and steadily, and is becoming a problem.

I just wanted to jump in and say that this issue is still occurring for me. I installed DF Pro v3.5.0 (Beta 7) a week or so ago after finding this thread. It seemed to work great up until yesterday. Then I started noticing the sluggishness on the multi-monitor taskbar and that my CPU usage was in the 80-100% range. My system has been up for 17h 21m and DF is using around 30-45% of my CPU. I also have Bins installed and it's using < .1%. Memory-wise, DF is using ~190,000 K, Bins 113,000 K, both in private bytes. This is all according to Process Explorer.

I also wanted to say thanks to you guys for the absolute best multiple monitor tool out there.

For me, the updated version of Bins has fixed the issue. After several days of use, I've seen no issues with either. Right now, Bins is at 44,000K of memory 0% CPU and DF is at 9000K memory, 0% CPU. Used it all day Monday and Tuesday with no issue (after being idle all weekend). I rebooted last night after patch Tuesday and both have been running all night (idle), but neither one is an issue right now. I'd say it's resolved.

Jeff

Thanks for the info, Jeff. I checked and I'm the version of Bins I'm running is 1.0.0.221. Is that the version you're running? I made sure I had beta updates on also. I'm in the process of looking through Bins' support topics now and will be getting in touch with somebody there.

Update: I found the link to the .224 Beta on the Bins site and I'm installing it now. I'll let it run for a day and then come back and let you know how it worked.

Update2: I've had the latest Bins beta (224) installed and had my machine up for a little over 6 hours and things seem to be working fine now. No sluggishness or CPU pegging.

Sorry I fell out of this discussion, real-life got in the way. I finally moved to Beta 8 and I've noticed the lag again, this time it's occurring right before a wallpaper change, normal operation so far as DisplayFusion at 0% cpu usage when idle and <10M of ram. But I've noticed it will spike to >80% cpu and >180MB of ram (both approximate) when it's trying to change the wallpaper. This is actually rather annoying and at times crippling because it brings a 16GB machine w/ four 3GHz cores to it's knees for approximately 45 seconds.

@Kieth, 1,317 files in 35 folders of varying resolution. Some are very high res images, many are medium or low quality. I had to kill DF when I posted my last message, I just tried to fire it up again and it brought my machine to it's knees very quickly (in mere seconds, I was pinned at 100%x4. If memory serves, I did not have that option selected, though I am unable to verify it at this time

It's set to 0. What next? I'm about to go back to beta5 just so it will start rotating my monitors again.

Well, it does need to set it multiple times, once for each monitor (and there are two), so will your fix interfere with that expected operation?

I have been running Beta 9 now for about 10 hours and these are my observations. I have two monitors and DF is pointed at a directory with about 100,000 high-rez images. When you first run DF, I assume it tries to create a database of the images to use. This causes DF to utilize 100% of all 4 CPUs for at least 1/2 hour. Once that is over things settle down and CPU utilization is normally 1 or 2% with spikes to 25% when changing the images. Memory usage starts out at around 60k and after 10 hours it creeps up to around 100k.

The next interesting thing is if you let the monitors go to sleep and then revive them, CPU utilization goes to 100% for about 2 to 3 minutes and then settles back down to 0%.

Hope this helps. I really love the program.

It has now been about 15 minutes since I awoke the monitors and after having the CPU utilization sitting at 0% the CPU use shot back up to 100% for about a minute or two and now has gone down to 50% and is just sitting there.

@Kieth, nay, I still have a copy of b5 in my download folder. Switched back to that after my last post, waiting for b10 though.

I've been running B10 now for 8 hours and it would appear you have fixed it. Unless DF is changing a picture, CPU usage is 0% and memory usage is very low. Great job.

@Kieth, haven't upgraded yet, later today (maybe) or this weekend, will let you know after it's had time to run.

@Michael, when it is changing a wallpaper, what does your CPU/RAM usage go up to?

The ram usage goes from a low of 3,000K to a max of 125,000K

I should have added that Ram usage goes from 0% to 25% for about a second.

I meant CPU usage

Just wanted to check-in to say that I've now been running DisplayFusion v3.5.0b8 w/ Bins v1.0.0.224 for over a week and the high CPU usage/memory leakage seems to be completely gone. Thanks Keith for all the work you've put into resolving this!

Ran b10 all weekend (upgraded Friday evening) and it ran without a hitch, I didn't even notice a spike when it changed wallpapers, but I didn't explisitly pay attention to it. If need be, I can eyeball it this evening and report my findings.

Hello,

I am still experiencing high CPU usage and a lagged taskbar sporadically even with DF v4.0.0 Beta 11. I am not sure how to reproduce the issue as it just happens out of the blue once in a while. I have to close out DF and start it again for the issue to disappear.

4.0.0b11 was using 50% of my two CPUs after leaving it running overnight. Both of my taskbars were functional but the one on the secondary monitor was not redrawing (I think it was showing the remains of the Marine Aquarium 3 screen saver). XP Pro SP3 on Core 2 Duo E8500.

You guys should try to uninstall graphic drivers and reinstall them (different version). It fixed problem on my Dell E6400 with high cpu usage before. I was using both Intel / Nvidia drivers and after installing "stable" older versions the problems went away. Something worth looking at when checking the problem with high cpu / memory with DF

I've had zero issues since upgrading to B11. All is well on this front.

I agree. I have been running Ver 11 and have had no issues either. I'm running Win 7 ultimate 64bit.

DF 4.0.0b11 is still using 50% of two CPUs after some random time, even with Application Hooks disabled. And it's still failing to redraw the taskbar on the secondary monitor. Windows XP.

Sorry I haven't been active, I was just waiting for the issue to reappear and it hasn't yet - this is with the hooks enabled. I've attached a copy of my troubleshooting log but I'm not sure if it has useful information because I see that the it has been on "Logging: Disabled".

Beta 11 seems to be more stable than the previous 10 betas as I have only experienced this issue once so far. I would experience it much more constantly in previous betas. However, DF version 3.4.1 (non-beta) was rock solid and never had an issue.

Please let me know if you need another copy of the log with the Logging option set to something else.

Thanks.

I have just noticed the issue happen again and managed to copy the log with All Lines enabled. As you can see in my screenshot, DF shoots up to around 50% when I click on taskbar buttons to minimize and restore (which lags). And when left idling, DF will consume around 25%.

Sure, I'll try to do some more testing and get back to you with more info.

After a week of solid uptime



DisplayFusion decided to take a crap on me (it's still running, but it's about to get killed if it doesn't unfrak itself by the time this message is done.) For several minutes now, it has been reporting 20-25% CPU usage and <10MB RAM usage.

Normally, my system's 4 CPU's sit at <15% when idle unless SETI@Home is running (which is only after a 20min timeout of inactivity). Even under normal use, I am at <25% CPU usage. But when DisplayFusion decided to go apeshit, in reality, DF pegged 4 CPU's at 100% for nearly 15 minutes. It has since returned to normal, 0% CPU usage and 6500K (even) in RAM usage.

So, this weird/strange/bazaar CPU-cycle eating monster is still lurking about.

Pitchfork Brigade anyone?

** EDIT **
Scratch that, DF just did it again within minutes of stopping itself the first time. This time, it did get killed.