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.
Related
I upgraded from 10.3 (Rio) to 10.4 (Sydney) (with side-by-side installs), now having IDE docking exception, e.g.
Loading the desktop from "C:\Users\gary.walker\AppData\Roaming\Embarcadero\BDS\21.0\Default Layout.dst" for doc host windows "DockSite3" failed with message:
"EAccessViolation: Access violation at address 50165CBF in module 'rtl270.bpl'. Read of address 33DEEBFF"
Deleting all .dst files has resolved the issue in at least one case (a coworker).
Also, when attempting to debug a program, I was having a hard failure during debug startup that prevented debugger use, before application began execution. I resolved this problem by copying my Default desktop to my debug desktop.
Another friend had pretty much the same issue and was able to fix it, unfortunately he does not know how he fixed it.
Question is does anyone know how to fix this?
I am still waiting for an answer from Embarcadero and this is causing us real problems at the moment.
I received an answer from Embarcadero support.
It fixed the problem for me until I adjusted my desktops to the way I wanted them and them - still better than nothing. I suspect there is no solid work-around at this point in time. But, this may work well as long as you are not frequently changing your desktop layouts.
There were display layout changes introduced in 10.4.1 that cause the errors that you are seeing.
Shut the IDE down
In Windows Explorer navigate to: %AppData%\Embarcadero\BDS\21.0
Delete the *.dst files at that location (you can back them up first if desired)
In Windows Explorer navigate to the product's \bin directory. The default location is: 4. C:\Program Files (x86)\Embarcadero\Studio\21.0\bin
Copy the three default *.dst files from this location to the location in step 2
Start the IDE as normal
So I have spent the better part of two days troubleshooting a very weird issue. At no point running my application on the development workstation or a physical workstation did I ever encounter any issues running the application.
The app has reached a point in the development lifecycle were it was time to start doing more targeted regression testing. This included running the application within virtual machines as I wanted to support the application running in virtualized environments.
Well upon testing in virtualized environments I noticed a very weird issue randomly any command I had binded that opened a child window would sometimes not work. The child window will not render and the button would be greyed out due to the canexcute of the command giving false since it thought the command was still running. This issue cannot be reproduced on a physical machine and have tried greatly.
After research I saw a lot about virtual machines and wpf rendering and people stating to force software rendering instead of allowing hardware rendering. This did not work either.
Further research/testing found this didn't have to be a task that rendered a simple child window and it could be any task that would lead to this random issue.
After beating my head I have found these articles
https://www.gresearch.co.uk/2019/12/20/deep-dives-in-debugging-when-it-really-isnt-your-fault/
https://github.com/dotnet/coreclr/issues/26990
https://github.com/dotnet/coreclr/pull/10065
Long story short is that this is an issue with .net 4.8 and if I run in a virtual machine running 4.7.2 these issues are not reproducible. I am going to leave this open though as I did notice something odd after discovering this information and testing further.
I have discovered that if I run application on a virtual machine with .net 4.7.2 with TWO or more vCPUs that these random issues are not reproducible. But if I run on a virtual machine with .net 4.7.2 and ONE vCPU the issue still arises. Furthermore if I run application on .net 4.8 with TWO or more vCPUs the issue arises. Lastly if I run on .net 4.8 with ONE vCPU the issue is not reproducible.
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.
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 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