I developed a Silverlight application with various animations.. While I running my application, it runs better for first 30-45 secs without any problem... After that, It becomes hanging... I am using XP, 32 bit and VS2010 (SL4).. When i reduce my MaxFrameRate value to 10, there is no use.. Still i have the same issue... this is in local as well as in IIS.. So anybody have better idea to overcome this problem... Waiting for your kind help..
Sounds like a memory leak, you need to provide more info. Have you tried using hardware acceleration? http://msdn.microsoft.com/en-us/library/ee309563%28v=vs.95%29.aspx
Related
Observed behaviour (everything here is on Windows 10):
I run Visual Studio (tried 13 and 15, both behave the same) logged into user A
After starting up, VS takes virtually no CPU time (<1%)
I log into user B, without signing out of A
VS imediately starts using A LOT of CPU time (~25% on my 4 cores with hyper threading)
I can go back and forth between A and B, and it goes back and forth between low and high CPU usage
This is all without any projects or files opened, though it also happens in that case.
I noticed this because I was originally investigating similar behaviour of a WPF application (after a user reported this issue).
While trying to isolate the problem, I found that even a completely new WPF project, with just a single empty window, behaves exactly the same (whether or not run through Visual Studio).
Through profiling and debugging I found that the app seems to spend a huge amount of time handling windows messages.
Specifically I found that it seems to be almost exclusively WM_PAINT messages (we are talking easily hundreds or thousands of messages per second - as many as the CPU can handle it seems).
No other programs I have running (chrome, skype, sublime text, ..) behaves this way.
Has anybody else seen this kind of behaviour?
And/or any ideas what could cause this, or how I could investigate this further?
Naturally, I cannot fix Visual Studio (unless the problem is with my setup somehow) but I hope there is something I can do about my WPF application.
As per Hans Passant's suggestion in the comments, I reported this problem to Microsoft here:
http://connect.microsoft.com/VisualStudio/feedback/details/2390593/wpf-apps-use-a-lot-of-cpu-time-when-logged-into-different-user
As it turns out this indeed seems to have been a bug in WPF, which is fixed in the current version of Windows 10 (probably specifically since the Anniversary Update (version 1607)).
Hence the solution: Make sure to update your OS.
I'm experiencing a pretty serious memory leak when running WPF 4.5/PRISM 5.0 projects in Visual Studio 2013 on my Windows 7 (64-bit) machine. This has been going on for months and I've tried to narrow it down. The only common denominator is the parameters I've already noted.
It's not any particular WPF/PRISM project that causes the issue. I first noticed the problem when trying out code from various WPF demos on PluralSight and elsewhere. Initially, I had only 8GB RAM on my machine and Windows notified me that I had to shut something down or I'd run out of RAM. I've since upgraded to 16GM RAM and I can run projects for a few extra days without rebooting my machine. Logging off doesn't help. Simply shutting down every running application and waiting (even over night) does not help.
When reviewing the Processes (including the ones for All Users), no process sticks out as taking up the extra memory and what's listed doesn't come close to adding up to what's being taken up in memory. The memory seems to slowly creep up after multiple runs of any WPF/PRISM projects in VS2013. Eventually, I'll find there are gigs(!) of orphaned memory being used up that I can't recover.
I've searched online for any known issues and can find none. I don't know how to nail down the exact culprit either.
Anyone else experiencing this? Any ideas on how I can find out exactly what's causing it and/or how to fix it? I'd rather not have to uninstall/reinstall VS2013, but as a last resort, I suppose I can try it. My luck it will be futile though.
We have a higher-end Win7-64 Dell precision workstation notebook with an i7, 8 gigs of ram, tons of hd space and running dedicated AMD graphics. The machine is about a month old. It was one of the highest-end we could get at the time.
What we're experiencing is when we run our WPF/SQL Server (local) app, it tends to hang and stall, sometimes completely crashing, but mostly just hanging until we force it to close. However, the exact same installer running in a VMware virtual machine running on that same machine runs flawlessly. Actually, the VM install runs better than a lot of native installs on other machines. It's very snappy with no hangs or hesitations at all. But again, same app, same installer running direct in the OS, and we're back to the issues above.
We've ran all Windows updates.... we've tried completely reinstalling everything... .NET frameworks, SQL Server, video drivers, even updated the BIOS and checked for rogue services but it still happens.
At first we thought it was Symantec AV's real-time protection because when we first shut that off, things started getting snappy again (and slowed down and froze when it auto-re-enabled itself furthering this hypothesis) but then it just started slowing down again, and more surprising, that same AV is running in the VM without issue! Checked the exceptions but there weren't any.
We even tried forcing WPF to run in software-render mode but again, nothing.
Now the odd thing is this only seems to be happening on this and a few other machines, but we can't seem to find anything in common except they're all running Win7 64-bit. As such, we have absolutely no idea where to start. And since most are hangs, not crashes, we can't even look at the crash reports.
So can anyone give us any idea what else we can look at? This is holding up us shipping a three-years-in-the-making major release of our software so to say this is a show-stopper would be an understatement. We've been stumped for about a month now and getting nowhere fast.
Found it!! Turns out there's a bug in .NET 4.0 regarding UI Automation and the changes MS introduced. Here's the info, and the fix! (Note: Even if you call MS, they will send you a link, but it's always a broken link. I managed to track this down manually.)
Note: Their article talks about a specific case that causes this behavior, but if you google around, you'll see tons of issues around hangs related to those DLLs. The latest is they're promising a fix in the .NET 4.5 runtime (from a MS post on this issue.)
Here's the KB article...
http://support.microsoft.com/kb/2484841/en-us
...and here is the actual hotfix.
http://archive.msdn.microsoft.com/KB2484841/Release/ProjectReleases.aspx?ReleaseId=5583
Apparently the VM didn't suffer from this. We weren't sure if the VM had the hotfix applied or not or if this only happens on non-virtualized machines. Still, this solved all of the issues and the app is now snappy again. (Man, was this fun to track down! Ugh!!)
I am writing code using VS.Net 10 and SlimDX to render 3D content on a D3DImage. It works perfectly under 32 Bit Windows XP. However, after migrating to 64 bit Windows 7 (quad core and 4 GB Ram), the same code does not work any more. The symptom is that after rendering about 10 or 20 times, the D3DImage's IsFrontBufferAvailableChanged event is raised and the property of IsFrontBufferAvailable has a value of false.
I have checked everything I can think of, e.g. RenderCapability.Tier, calling SetBackBuffer, checking the device (in fact it is DeviceEx type) after the front buffer is lost, updating video card driver (nvidia 9500 GT 1G RAM), etc. None of them worked.
One thing that may contribute to the problem is that the image control which uses D3DImage as the source is not created on the GUI thread. I am doing to reduce the work load of the GUI thread to make the application more responsive. Of course, I have been using Dispatcher.Invoke to avoid threading problems. Again, it works perfectly in XP.
Any help is much appreciated. Thank you in advance.
I think there is a x64 version of the slimdx.dll.. if you are using the x32 version, that could be the problem.
I know that running applications in DEBUG (build configuration) thru the visual studio adds a level of overhead but I have a WPF application that I am testing out that is painfully slow in its execution and other functions such as drag/drop of items. When I run the application in Release mode it performs like one would expect, very quickly and without hesitation. I've set up no special debugging parameters or any other watches, settings or breakpoints that would interrupt the application.
Has anyone else run across an issue like this or is there possibly just some setting that can be adjusted? It's not really an issue more of a why is this happening...
thanks.
The garbage collector is much less aggressive in debug mode.
Try watching the memory usage in task manager, the VM Size column is often the most useful.
See if during the slow operations a lot of memory gets released - this will indicate that the collector hasn't bothered doing much work for a while and then has had to kick in a do a larger clean up.
You might check your Output and Immediate windows. You're might be getting a lot of messages thrown in there, especially if you're getting binding errors.